Redmine

A quick word regarding the rationale: in #25501#note-4 custom fields were changed to behave in the way implemented in the proposed patch, i.e. only limit the categories to the categories of the current project and its subprojects if we are in a project context.

I think we can merge this patch if tests are added.

The patch also resolves #8192, #17761 and #23198.

Thank you for reviewing, Felix.
I also did't notice the visibility caused by permission.
I confirmed that the new patch(26023_test_added.patch) works fine and passes the tests!

With this change, will there be a way of enabling the legacy behavior? My team uses Category as a hack to allow non-admin users to maintain their own list of people who initiate work with them, most of whom are not Redmine users. What makes categories special is that the admins don’t have to edit values that are possible, unlike custom fields.

So for us, it wouldn’t be good if every project showed categories for every project (subprojects might be okay). If the categories in other projects could be shown or hidden depending on a setting, or if the cagetories in the main project can be shown first with a separator before the others in a project context (sort of like how custom fields are grouped in the issue filter), the system would be more flexible.

There is no setting, no.

Currently the category filter on a project's issue list will show only the categories of the current project. On the global issue list there is currently no category filter.

With the patch, the global issue list will have a category filter with all categories from the projects the current user has access to. On a project's issue list it will show all the categories of the current project as well as categories from subprojects the current user has access to.

Thanks, Felix.

On a project's issue list it will show all the categories of the current project as well as categories from subprojects the current user has access to.

Thanks for clarifying. Is it possible to display the categories of the current project first, then a separator before any categories found within subprojects?

Jean-Philippe Lang wrote:

When reading at all the related issues, we can see that it's pretty common to have the same category in multiple projects (eg. Security), even if they are different records from a database point of view (since we can't share categories across projects).

With the proposed patch, we would have a category filter filled with multiple Security values. And if you filter on one of these values, you will only get the security issues of a single project. That's not what is expected. I think we should filter by category names, eg. being able to list all issues with the Security category. Also, when grouping by category, all Security issues should appear under the same group (#23198).

I have a patch that implements this solution, please let me know what you think.

I’m in favour of your proposed solution.

I have only one concern regarding the filter behavior which will be different than other filters like Target version and I’m asking if is not better to add this feature as a new filter named “Category name”. In this way, if we add in the future the posibility to share category between projects (feature requested by many users in #5358) it will not be necessary to revert the behavior of the current Category filter.

On the same topic, a user requested in #27192 to filter the target version by name and not by id (I mention this because is somehow related).

The current 'version' has functions that inherit in subprojects and make them available in all projects.

I think the same processing (inheritance) is good for versions and categories and projects.
I believe that the inheritance process of the current version is simple and user-friendly.

On Redmine 3.4.6, I put the same processing as version on category.
(I just made the category the same code as the version.)

http://www.redmine.org/issues/5358#note-97
http://www.redmine.org/issues/5358#note-98

The current user data can be used as it is.
If inheritance is set for the category definition, it can be used from subprojects as well.

The patch seems to be controversial. Is it better to put off implementing this feature until 4.1.0?

Jean-Philippe Lang wrote:

When reading at all the related issues, we can see that it's pretty common to have the same category in multiple projects (eg. Security), even if they are different records from a database point of view (since we can't share categories across projects).

With the proposed patch, we would have a category filter filled with multiple Security values. And if you filter on one of these values, you will only get the security issues of a single project. That's not what is expected. I think we should filter by category names, eg. being able to list all issues with the Security category. Also, when grouping by category, all Security issues should appear under the same group (#23198).

I have a patch that implements this solution, please let me know what you think.

I'm really not sure that having the "normal" Category filter be name- instead of ID-specific would be a good idea, as this would make the filter work differently from all other filters. If there's multiple users called "Jean Dupont", the search by author will yield only results for one user, not for all users with that name. This change would make the Category filter behave differently from the other filters.

Regarding the ability to search by Categories with the same name in different projects: This would already be possible by using the multi-match filter (expand the dropdown with the possible values to a list, select all categories with the name to search). I agree this wouldn't be as easy as matching on the name, but this would at least not make the filter work differently from all other filters.

Note that I am not opposed to be able to filter by the name of the Category instead of by the ID, but this would need to be a different filter or a new operator, to 1. still be able to search by ID if this is what the user needs, and 2. avoid differing behaviour for same-looking filters (subtly different results for things "looking" the same is always difficult to explain to new users and difficult for them to remember).

One thing that could be improved in my patch proposal in #26023#note-14 would be to group categories by project or to prepend the category name with the project name. It currently wouldn't be possible to distinguish between categories with the same name in different projects in the list. If this is something of interest I could prepare an updated patch.

Hi,

I agree with the fact to keep too filters for Categories, one by Id and the other by Name, to keep the coherence with other filters behavior. And in the filter by Id the project Prefix seems a good idea to me.

Felix Schäfer wrote:

One thing that could be improved in my patch proposal in #26023#note-14 would be to group categories by project or to prepend the category name with the project name. It currently wouldn't be possible to distinguish between categories with the same name in different projects in the list. If this is something of interest I could prepare an updated patch.

I have been rethinking about this a little bit and in the vein of keeping one entry matching only one category, as every other list filter currently works, I think there are 2 options:
- project name - category name, which would match the behaviour of the fixed versions filter, fixed versions are grouped by status though, which could be done by status for categories
- group categories by project, with the categories of the current project at the top and top-level, and below grouped by project other categories

I think I'd prefer the second option, but the first would be consistent with the fixed versions.

Please note that we have the basic version of this, i.e. the version where all rolled up issues are just shown as is, in use at Planio and no user has currently gotten in touch because they got mixed up. I think improving the current filter by adding shared categories would be a good first step, and we can think about improving filters and/or adding a name-based filter in another ticket?