Opened 13 years ago

Last modified 7 years ago

#8405 new task

Document permissions and some possible improvements — at Version 4

Reported by: Ryan J Ollos Owned by: Colin Guthrie
Priority: normal Component: WorkLogPlugin
Severity: normal Keywords:
Cc: Trac Release: 0.11

Description (last modified by Ryan J Ollos)

  • The WORK_VIEW, WORK_LOG, and WORK_ADMIN permissions should be documented on the project's wiki page.
  • If the WORK_LOG permissions does what I think it does, we might rename it to WORK_EDIT, to be more consistent with the permission naming scheme in Trac.
  • I've granted WORK_LOG permission to a user, but that user can't start work on a ticket and sees the message WORK_VIEW privileges are required to perform this operation. To be more consistent with Trac implementation of permissions, WORK_LOG (WORK_EDIT) should grant all permissions granted by WORK_VIEW. In the same way, WORK_ADMIN should grant all permissions granted by WORK_LOG (WORK_EDIT).

Change History (4)

comment:1 in reply to:  description Changed 13 years ago by Ryan J Ollos

Replying to rjollos:

  • The WORK_VIEW, WORK_LOG, and WORK_EDIT permissions should be documented on the project's wiki page.

It would be even better if we could document them in the source code and have that documentation displayed in the WebAdmin panel. See t:#9018.

comment:2 Changed 13 years ago by Colin Guthrie

I'm going on my hazy memory here but I think the WORK_EDIT was meant to allow subsequent fix ups of the work log (e.g. adjusting times etc.) which is quite different to actually logging hours (one company using this plugin was quite strict about not letting the "drones" do such things, requiring them to get someone higher up to do the edits should they have accidentally overlogged hours etc.

But perhaps I'm confusing it with something else. But I get the point generally so will see if the above is vaguely true and then try and do as you suggest :)

comment:3 Changed 13 years ago by Ryan J Ollos

I think the most important thing is to have a hierarchical permissions scheme with inheritance. From looking at the source code, it appears that this was the aim, but I may have discovered a bug in that a user with WORK_LOG permission cannot start work on a ticket without having WORK_VIEW.

I may have misspoke earlier in suggesting that WORK_EDIT is an existing permission (I head meant to say WORK_ADMIN, and will fix that typo in the description). It looks like the 3 permissions are WORK_VIEW, WORK_LOG, WORK_ADMIN. The main point of my suggestion was to perhaps rename the WORK_LOG permission to be more consistent with the nomenclature for ticket permissions, in which case it might be named WORK_EDIT or WORK_MODIFY (would have to give it some more though to determine what nomenclature would be most consistent).

But to your point, it seems good to reserve WORK_EDIT for a future permission that would allow a user to edit their own work log entries.

comment:4 Changed 13 years ago by Ryan J Ollos

Description: modified (diff)

Fixing typo in description WORK_EDIT -> WORK_ADMIN.

Note: See TracTickets for help on using tickets.