Feature #18004
closedDo NOT hide category and version fields on issue form when no category or version is configured
0%
Description
The category and version fields are very hard to discover for new Redmine users (at least this is our observation at Planio) as they are automatically hidden when no category or version is configured for a project.
As it is now possible to completely hide the version and category fields on the issue form by switching them off at the tracker level, we think that removing this "magic" behaviour would help in finding/using those fields, or switching them off if they are not needed.
Files
Related issues
Updated by Felix Schäfer about 10 years ago
- File 18004-no_more_magic_for_category_and_version_fields.patch 18004-no_more_magic_for_category_and_version_fields.patch added
The attached patch makes the proposed change.
Updated by Go MAEDA almost 10 years ago
Felix Schäfer wrote:
The category and version fields are very hard to discover for new Redmine users (at least this is our observation at Planio) as they are automatically hidden when no category or version is configured for a project.
I absolutely agree with you. And using target versions is good practice to make full use of Redmine, but hiding the field eliminates the opportunity to know the feature.
I tried the patch on current trunk and it worked fine.
Updated by Igor Panassiouk over 9 years ago
Worked fine on Redmine 2.6.6
Any advice how to add "% done" or some custom attributes to mail notifications?
Updated by Sebastian Paluch over 9 years ago
+1
Additionally for issues query: when there is no version defined and the Target version field is hidden there is no way to e.g. show issues from subprojects that has Target version 'none' or 'any'. This is useful to list issues overview at top level project for those that are not planned yet.
Updated by Jean-Philippe Lang about 9 years ago
- Related to Defect #2619: Categories field displays when no categories exist and user can't add new added
Updated by Go MAEDA about 9 years ago
- Related to Defect #20583: Setting Category/Version as a required field causes error in projects without categories/versions added
Updated by Sebastian Paluch about 9 years ago
Jean-Philippe Lang wrote:
So we discard #2619?
After thinking more about it I recall my +1. There is no point in showing fields that have no values and user has no permission to add those. In every project usually there are roles that do have such permissions so someone should find such feature and configure it of others.
I still vote for showing them in query filters if those were defined for subprojects.
Updated by Felix Schäfer about 9 years ago
Sebastian Paluch wrote:
There is no point in showing fields that have no values and user has no permission to add those. In every project usually there are roles that do have such permissions so someone should find such feature and configure it of others.
By that rationale the logic should be changed to "don't show the field on the issue edit form if no value is selectable by the current user and the user cannot add a new value". Currently even people who could add a value don't get the field shown (as far as I know) when there's no value selectable yet, which means you need to go to the settings to add one and go back to your issue afterwards to select that value to the issue.
My original point was that it's too much "magic" though. Whether or not you get a field shown in the issue edit form depends on whether it's an issue in a tree, whether the field is available to one of your roles and the status of the issue, whether the field is activated for the tracker or not, and I'm not even sure I covered everything.
For category and version there's one more thing that comes into play: whether or not there's a category or a version to select. And that is an implicit setting as I can't remember reading anywhere an explanation that "not having a category or version in this project will hide those fields". For versions it's even more implicit as someone could share a version with "your" project, even if they don't know your project is there, and change what is shown on your issue edit field through that.
So for a field you can change whether it's shown or not in the tracker settings, in the workflows settings depending on the status and role of the user, whether the issue is in an issue tree and depending on the settings regarding how the attributes should be calculated…
I can understand that having an empty drop-down list is confusing, I find it confusing to have the version and category shown in the issue description but not showing up whatsoever in the issue edit form.
Having written all that down I think I'd change my request: instead of hiding the option be explicit about the fact that the current user can't change it because there's nothing to change it to, make it a disable select box. That would be the same behaviour as the fields you can't change because of subissues (if it's configured to bubble up) and so on. If you don't want to use the field you can still completely disable it for that tracker.
Anyway, I don't want to spend too much of everyone's time on this, there's other issues that are probably more important :-) If the answer is "I'm not quite sure" or "meh" or "I don't care", just reject it. I laid out all my arguments, If they don't convince you I can live with it and I won't bring it up again.
Updated by Sebastian Paluch about 9 years ago
Felix Schäfer wrote:
By that rationale the logic should be changed to "don't show the field on the issue edit form if no value is selectable by the current user and the user cannot add a new value".
This sound reasonable, I was convinced that it is this way already.
My original point was that it's too much "magic" though. Whether or not you get a field shown in the issue edit form depends on whether it's an issue in a tree, whether the field is available to one of your roles and the status of the issue, whether the field is activated for the tracker or not, and I'm not even sure I covered everything.
That happens when a tool is meant to meet requirements of wide audience... it must be configurable... even within my company and one installation there are many groups that use different trackers, or same trackers in different way, once having categories, once not, making the decision at project level. This applies to all features and I think Redmine configurability (still not sufficient in some areas) is its strong advantage.
Updated by Jean-Philippe Lang about 9 years ago
As it is now possible to completely hide the version and category fields on the issue form by switching them off at the tracker level
The problem is that versions and categories are defined at projet level. Some projects that use the same tracker may use versions and categories while other don't use them. If we drop this behaviour, sure we'll make it more obvious for new users (who did not read the doc :-) that versions and categories exist but we may also confuse users who don't need these fields in their projects. I really don't know what is the best option.
Custom fields can already be disabled at project level. Why wouldn't we let people disable standard fields at project level just like they can be disabled on trackers? That looks like a solution to the problem.
I find it confusing to have the version and category shown in the issue description but not showing up whatsoever in the issue edit form.
Agreed, that should be fixed if we keep the current behaviour.
instead of hiding the option be explicit about the fact that the current user can't change it because there's nothing to change it to, make it a disable select box
Making the field disabled would make it obvious that the value can not be changed but it does not show that it's because there no value available.
Updated by budo kaiman about 9 years ago
The problem is that versions and categories are defined at projet level. Some projects that use the same tracker may use versions and categories while other don't use them. If we drop this behaviour, sure we'll make it more obvious for new users (who did not read the doc :-) that versions and categories exist but we may also confuse users who don't need these fields in their projects. I really don't know what is the best option.
I think I know what you are proposing, but would like to make sure. Do you suggest making versions/categories defined at the tracker level or globally? If the latter, then I don't think that making categories and versions globally defined is the best solution. If anything, I think it would be desired to separate projects further and instead separate trackers to be per-project. If trackers were defined at the same level as categories/versions then the ability to show/hide these fields makes more sense. See #1853 (and the many duplicates and +1s) that proposes separating global configurations to be per-project.
Custom fields can already be disabled at project level. Why wouldn't we let people disable standard fields at project level just like they can be disabled on trackers? That looks like a solution to the problem.
This seems like a short-term solution as settings currently are quite confusing. If we could define trackers per-project then we would not have to check our project settings and our tracker settings, but simply check the settings of the tracker for our project. If we could equally define our settings for each project as desired, we would not need to try to balance out settings that are all at different levels by enabling/disabling the same things in multiple areas.
Updated by Jean-Philippe Lang about 9 years ago
budo kaiman wrote:
I think I know what you are proposing, but would like to make sure. Do you suggest making versions/categories defined at the tracker level or globally?
I suggest none of these 2 options. I'm just saying that the ability to disable fields at tracker level is not a solution to the problem.
Updated by Etienne Massip about 9 years ago
Easiest solution would be to have a Use categories checkbox at project level?
Updated by Jean-Philippe Lang about 9 years ago
- Status changed from New to Closed
- Target version deleted (
3.2.0) - Resolution set to Wont fix
Etienne Massip wrote:
Easiest solution would be to have a Use categories checkbox at project level?
Sure but I wouldn't do it for this particular field only. That's why I proposed to let people disable standard fields (not just categories or versions) at project level just like they can be disabled on trackers.
Updated by Etienne Massip about 9 years ago
- leave the category field the way it works : you're supposed to define the categories before using the issue tracker
- add a Versioning system dropdown that let you choose between Default and None which would hide both roadmap and version field
Updated by Go MAEDA over 6 years ago
- Related to Feature #4569: Cannot add new version if all versions are closed (from issues page) added