Override "Issues of Released Versions are hidden" behaviour

GreenHopper is an insanely useful tool - to the point where I have used it for various management reporting and tracking tasks that are outside of its immedaite Agile remit.

The specific need I have is to have issues that belong to Released versions remain visible. I have currently worked around this by adding new "virtual" or "logical" versions (which are unreleased and ordered after all "real" versions) to the system and then use the standard JIRA Multi-Select field to add this special version to the issue in addition to other "real" versions and sprints.

This technically works quite well, and even had the added benefit of showing little green ticks when the issue is released in a "real" version. The list view still shows the "real" versions as in a multi-select scenario, GreenHopper shows the earliest version by version order.

However, we have found that this approach breaks in a number of scenarios that have ultimately made the workaround unusable for us. The problems are:
a) The in-line editing has no idea about the multi-selects, and changing a fixVersion removes ALL other selected versions - so we had to stop using this;
b) You can't tell the JIRA issue "Bulk Edit" feature not to touch certain version; reducing its functionality considerably; amd
c) The subtleties of the workaround is beyond our general user community and is causing confusion and information loss.

I can easily store the virtual "version" grouping information using many other techniques; however I am left with the problem of how to get the issues visible on the GreenHopper Planning (or Task) board.

My suggestion is to simply add a check-box to the "Manage/Edit Context" facility where you can select "Releeased issues remain visible"

This should default to OFF (the existing behaviour) and it is appropraite for the override to be available against specific Contexts that need it.

NOTE: GHS-945 covers off a much more significant rework of how fixVersions work in GreenHopper. It is possible that some of the solution being developed there (apparently scheduled for GreenHopper 6.0) could solve this problems - but it possibly still may not. I am therefore adding this as a separate issue so that:
a) It doesn't totally feature-creep GHS-945, and
b) It can possibly be implemented more simply and sooner as it has a much lower impact and development footprint.