Permissions for custom ticket fields

[Mitar]

I would like to request a feature to be able to specify permissions for custom ticket fields. So that for a defined custom field you would be able to define users which can edit it on ticket opening, edit it later and also see it (or not) altogether.

This is very hard to do properly with a plugin as it requires finding out in post_process_request phase where all field has been displayed and removing that (ticket view, RSS, alternative views, ticket notifications, ticket queries, searching tickets…). It would be much easier if Trac would simply remove it from a list of fields in the first place if user would not have access to it (in a given ticket state).

[Remy Blank]

Related to #8653 and actually a duplicate of #2464.

[Mitar]

No, it is not a duplicate. #2464 talks about limitations which fields can be set/modified by the user. I am talking about permissions which fields user can see (in timeline, ticket view, query, reports…, alternate formats, e-mail notifications). #2464 talks just about the form for creating/editing ticket, I am talking about having globally check for every field everywhere if the user has permission to see (and set and modify) it.

[Remy Blank]

I see. This falls under TracDev/Proposals/EvenFinerGrainedPermissions, then.

[Mitar]

An use case. We would like to add contact data for our users/customers which should be seen only for users with right permissions. All other things should be left public. So we would like to have a field which is only visible/editable to those users with a permission.

This is important for privacy issues.

In fact it is a generalization of what is done with e-mail addresses. We have a EMAIL_VIEW privilege. It would be generalization of this for custom privacy sensitive (or otherwise sensitive) fields.

[Dave Morgan <morgand@…>]

… so we would need 2 pemissions (or a total of three "states") for every field (including custom fields).

0 - No Read (invisible) 1 - Read only 2 - Read/write.

…which would need a matrix to allow it to be tagged to each role/permission.

Question? I assume it could be hacked using the same mechanism that generates the workflow options which is also based upon roles/permissions…..

[Dave Morgan <morgand@…>]

Should it also relate to "state" as well?

ie some field could/should be visible only when the ticket is in a given status?

[Mitar]

I think there should just be a way to plugin permission system in. What exactly is then allowed should be customizable through plugins. So some plugin can take state into the account and some not. So the idea is to make fine grained permission system. Implementation is then left to others.