Redmine

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.

Worked fine on Redmine 2.6.6

Any advice how to add "% done" or some custom attributes to mail notifications?

+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.

So we discard #2619?

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.

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.

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.

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.

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.

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.

Easiest solution would be to have a Use categories checkbox at project level?

• 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