Defect #6334
open
Unable to control the visibility of Versions in parent projects
Added by John Lewin over 14 years ago.
Updated over 14 years ago.
Description
We're happing using the unlimited project nesting feature to create a nice hierarchical layout of our projects. One unfortunate side effect is Versions bubble up through their parent projects. Sometimes this is beneficial but not always. In certain branches a lot of cruft appears in top-level projects where Versions deep down in the branch aren't entirely relevant.
In another example, we're currently working on a feature branch that we'd prefer not to draw unnecessary attention to but don't want to make it fully private either. In this project we'd like to use Versions to track iterations of work but have them only appear within or below the project. It seemed like this functionality was already in place as the "Sharing" attribute seemed well fit to control visibility but unfortunately it appears to only control the ability to assign Issues to the Version.
I'm uncertain if this item is best tracked as a defect or a feature but given its close proximity to the "Sharing" feature it initially seems like a defect.
Repro:
- Create a new project named Test1
- Create a version "In-Test1" with Sharing set to "Not Shared"
- Create a sub project Test1->Test2
- Switch to the Test2 project
- Create a version "In-Test2" with Sharing set to "Not Shared"
- Switch back to Test1 and open the Roadmap tab
Expected Behavior:
After setting Sharing to "Not Shared" I expected the Roadmap to only show the "In-Test1" Version
Actual Behavior:
The "In-Test2" Version appears in the parent and "Sharing" seems to have no impact on visibility
I'd say this is expected behavior as the roadmap page will show all versions from subprojects (when the checkbox in the right sidebar is clicked) only based on visibility (i.e. if you have the permission to see those) and only those. The sharing thing doesn't influence that currently.
Felix, I agree and based on the research I did after running into this behavior determined this is not how Redmine is currently implemented. I thought I might be diminishing the value of the bug by using the Expected/Actual behavior approach but it's hard to break old practices.
To clarify...
As a Redmine user I'd expect to be able to control the visibility of project Versions. Redmine uses the term "Sharing" to implement the filtering functionality of the "Target Versions" field, which happens to follow the same family conventions you'd want to use for visibility. If I was in a case study trying to figure out what "Sharing" did and only a few minutes exposure to Redmine I'd bet that it would let me control if this project is shared with its Parent or Children. It's probably a losing battle to continue pushing on this aspect but I wanted to explain the reasoning behind why it potentially seemed like expected behavior. Clearly it's not designed that way.
Going forward I wonder how complicated it would be to introduce a mechanism to control Version visibility along the same path that Sharing currently uses. In addition, without more exposure to Redmine I can't accurately answer this question but I wonder what the implications of using the "Sharing" state to determine project visibility would be. Or, if a checkbox was added which toggled this functionality on and off. i.e. "Also use Sharing to control project visibility". Something along those lines would let the project control its visibility in cases where sharing the version doesn't benefit the parent Roadmap or causes some customer specific problem
Also available in: Atom
PDF
Updated by 
Updated by