Repository navigation
Rework of collaborative tags (NC 12.0)聽#1465
Description
Activity
I would like to be able to give tags a custom color so it is easier to distinguish between different tags.
@jancborchardt Might this be useful?@nickvergessen Could I ask you to split out the stuff that doesn't make it into 11 to a separate ticket for 12? Thanks ;)
@raimund-schluesser great! Need that too. Any chance to implement it?
- changed the title
[-]Make collaborative tags great again[/-][+]Rework of collaborative tags [/+]on Feb 1, 2017 Aren't the hidden-public-restricted access-types very limited and only scratching the surface of a deeper problem?
For instance we have a group User and a group Manager. When Users upload stuff the workflow module assigns a "to be checked" tag. After the Managers check the files the tag is removed. With things as they are Managers either need to be Admins or the tag needs to be public. Both options aren't very good. Currently we rely on the fact that tag-removal is logged and just have the tag public.
Couldn't each collaborative Tag be treated with the same access mechanism used for files? Where users can give "see Tag" (read), "set Tag" (write), "remove Tag" (delete), "Can reshare" privileges to other users and groups as they do with files? Inheriting all the "reshare only in the same group" etc. settings that are used for files?
I would assume a lot of the logic and ui components already used for files could be reused here. Having one concept of a "secureable object" and Files, Tags, Adressbooks, Calendars etc. just extending upon that concept seems a good idea for both usability and maintainability. It is also how most operating systems and security frameworks organize things.
At any rate giving tags some-sort-of-access-rights-but-not-really seems like re-inventing an inferior wheel when a battle proven one is already used elsewhere in the code.
@WowMuchName I have the impression that there is some misunderstanding...
If I am not wrong #2512 is about another aspect of tag management: you are talking about assigning and removing (i.e.: "un-assigning") tags to files; #2512 is about deleting tags from the list of tags, i.e.: removing tags from the system.
To say it with other words, if someone deletes the "to be checked" tag then the only way to assign it to a file is to recreate another tag with the same label.@Spartachetto You are correct, I jumped to conclusions there and should have actually read the issue before linking it. I was referring to the hidden-public-restricted access-types you can set for tags which I find to be very limited.
I updated my original comment accordingly
@nickvergessen I think the remaining items needs to be pushed to 13, right? Could you create a ticket for them? To know what was implemented in which version.
I moved the pending items to a dedicated 13 issue: #4699
- changed the title
[-]Rework of collaborative tags [/-][+]Rework of collaborative tags (NC 12.0)[/+]on May 4, 2017
Search/type-ahead should only bring up tags the user applied already (or has access to)moved to 13: Rework of collaborative tags聽#4699Tags that are not assigned should not be visible (implied by pervious task) (If no file is tagged with a specific tag, that tag should be removed聽#586)moved to 13: Rework of collaborative tags聽#4699Some information on the filter search page (Visualize useful synthetic information when user clicks 'Tags' 聽#2143)moved to 13: Rework of collaborative tags聽#4699More prominent displaying of tags when used (Display tags next to file names聽#2838)moved to 13: Rework of collaborative tags聽#4699cc @jancborchardt as discussed?