Project

General

Profile

Actions

Feature #8118

closed

Support more granular tag rights

Added by Evgeny Novikov about 7 years ago. Updated almost 7 years ago.

Status:
Closed
Priority:
Immediate
Category:
Bridge
Target version:
-
Start date:
04/21/2017
Due date:
04/24/2017
% Done:

100%

Estimated time:
Published in build:

Description

At the moment one has to be an expert to perform everything possible with tags. Actually this is too simple since other users also often need some means for dealing with tags. I suppose the following: producers or job/global experts should be able to create just new leaf tags and to edit/delete those leaf tags they created. Just managers should be able to edit root and intermediate tags exactly as it was before. Of course managers should be able to do everything with all leaf tags as well. This BTW implies that tag authors should be known and it would be nice to know them. I don't expect that a tag changes history should be remembered as for jobs and marks.

Actions #1

Updated by Evgeny Novikov about 7 years ago

  • Priority changed from High to Urgent

Since this belong to the common workflow this should be implemented first of all.

Actions #2

Updated by Evgeny Novikov about 7 years ago

  • Priority changed from Urgent to Immediate

The way is used now can be treated as a workaround or even as a bug, so I suggest to implement this feature ASAP.

Actions #3

Updated by Vladimir Gratinskiy about 7 years ago

  • Due date set to 04/24/2017
  • Status changed from New to Resolved
  • % Done changed from 0 to 100

Implemented in feature_8118. You need to migrate DB. It will set authors of all tags to last change author of first found job without parent in the system. Usually it is manager. But if manager was deleted then author is NULL. And all tags will be deleted.

Managers and experts can do everything with tags, other users - only with leaves but with one exception. Examples:
We have users: Manager M, Expert E, Other Users U1, U2, U3. Somewhere there is tag T1 without children that was created by M. Then U1 creates tag T2 with T1 as its parent. Then user U2 creates T3 with T1 as its parent (T1 is not a leaf on this step). Then M creates T4 with T1 as its parent. Users U1, U2, U3 can't create children of T1 anymore, but can create children of T4. So be careful with it, don't create leaves under the manager account.

Manager can "save" any tag without changes and the author of the tag will be changed to manager.

If any user is deleted then his tags also would be deleted (for example in jobs table the author become NULL in such cases).

Actions #4

Updated by Evgeny Novikov almost 7 years ago

  • Status changed from Resolved to Open

At the moment even users without any access can create tags. But actually tags are even more forbidden than, say, marks. In this feature request description it was specified that only experts should be able to create leaf tags. Let's even allow this only for global experts, i.e. if a user is an Expert. I shouldn't be enough to create tags for job experts.

Actions #5

Updated by Evgeny Novikov almost 7 years ago

Vladimir Gratinskiy wrote:

Managers and experts can do everything with tags, other users - only with leaves but with one exception. Examples:
We have users: Manager M, Expert E, Other Users U1, U2, U3. Somewhere there is tag T1 without children that was created by M. Then U1 creates tag T2 with T1 as its parent. Then user U2 creates T3 with T1 as its parent (T1 is not a leaf on this step). Then M creates T4 with T1 as its parent. Users U1, U2, U3 can't create children of T1 anymore, but can create children of T4. So be careful with it, don't create leaves under the manager account.

As I wrote before Experts shouldn't be able to do everything with any tags - just with leaf tags. Other users shouldn't be able to edit tags at all.

As for your case I guess that this shouldn't be the case. If a manager will need to introduce one more tag level then likely all existing tags on that level should be refactored (perhaps even without any real changes) and their author will be changed to that manager. So everything suits the suggested scheme well.

Actions #6

Updated by Evgeny Novikov almost 7 years ago

  • Status changed from Open to Closed

Works very well, so I merged the branch to master in 177e437.

Actions

Also available in: Atom PDF