Hide versions and components

[Ryan J Ollos]

Closed milestones are only visible on the ticket form for users that possess TICKET_ADMIN. However, all Versions and Components are visible for all users, and the only way to hide them is to delete them. These lists can grown very long, and it would be nice to narrow the list that is seen from the ticket form, while keeping the entries on the Query form.

[Ryan J Ollos]

#10342 was closed as a duplicate. I'm biased, but I felt the description in this ticket was more clear.

[Ryan J Ollos]

#10209 closed as a duplicate, requesting the ability to deprecate components.

[Dirk Stöcker]

Any progress with this ticket? Our trac instance has 141 components and it would really help when users at least would not see the dead historic components in the new ticket selections.

It shouldn't be so complicated to add a "hide" field to the database and only show these when not hidden.

Deleting old components is not really an option.

[Ryan J Ollos]

Another consideration, handling of many entries can be improved by switching from an HTML select to autocomplete, as the autocomplete will allow the ​list to be filtered. The hide/archive feature would still be useful with the addition of autocomplete.

[Ryan J Ollos]

I've been thinking the main need to be addressed in this ticket is to hide components and version from the ticket form. For example, on this site we might want to hide versions that are no longer actively supported (Trac < 0.11). Therefore this is mainly about revoking permission to assign tickets to hidden components and versions. To address concerns about the length of the select we can implement autocomplete (comment:6).

I've made some assumptions, which should be debated:

• The Query module will show all Components and Versions.
• The Ticket page will show all Components and Versions if the users has TICKET_ADMIN. This behavior is similar to Milestones: completed Milestones are shown if the user has TICKET_ADMIN
• I chose Hidden as the field label to try and be unambiguous. However, since the items aren't hidden everywhere, maybe a term like Archived would be more appropriate.

I'm considering:

• Adding dynamic functionality to toggle the hidden parameter from the admin listing page. This will make it easier to change the hidden state of many items.
• For users with TICKET_ADMIN, group hidden and non-hidden items (like what's done for Milestones in grouping open-with-due-date/open without-due-date/closed).

Work in progress: log:rjollos.git:t11637_hide_version_and_components.

[anonymous]

Replying to Ryan J Ollos:

Thanks Ryan

First question that comes to my mind is: how this change will interact with plugins/functionalities as Cloning Ticket , GridModifyPlugin , TracHoursPlugin , SimpleMultiProjectPlugin or SubticketsPlugin , just to mention some of them, which have 'direct' interactions with the fields: components, Versions, and Milestones?

[Ryan J Ollos]

You might want to checkout the branch and test plugin interactions. As described the proposed change is to hide versions and components from the ticket form. I don't see any possible impact on those plugins, but I could be overlooking so feel free to test.

[Logan Anderson <landerson@…>]

That seems fairly direct.

• Potentially in the future the ability for the query module to filter on hidden?
• Archived does seem more appropriate imho. I don't have other suggestions off hand but I will give it some thought
• I wish there were a better model for group support. A conversation for another day. I would like to be able, for example, to provide more granular control and potentially XOR some permissions.

• Definitely like the toggle for the parameter on the admin listing page.
• Grouping sounds good. Whenever possible I like the ability to flip a setting.

I need to take a look more at the autocomplete notes before I comment on that further.

How are we talking actually implementing the hidden value? Is this a field in the DB? Where is the hidden value actually stored? Just thinking.

[Ryan J Ollos]

Replying to Logan Anderson <landerson@…>:

How are we talking actually implementing the hidden value? Is this a field in the DB? Where is the hidden value actually stored? Just thinking.

Stored in database: [cd3e22ca/rjollos.git#file0]

[Ryan J Ollos]

Behavior discussed in ​gdiscussion:trac-users:deqkILWeNaQ.