Skip to content

Rework of collaborative tags #4699

Description

@MorrisJobke

cc @jancborchardt @nickvergessen

Activity

  1. added this to the Nextcloud 13 milestone on May 4, 2017
  2. disaster123 commented on Sep 19, 2017

    @disaster123

    Would it be possible to get tag colors like the labels on github?

  3. gradinaruvasile commented on Oct 3, 2017

    @gradinaruvasile

    Hi,
    As referenced here:

    https://help.nextcloud.com/t/how-to-tag-multiple-files/21769

    I would like to add the request for an option to apply tags when multiple files are selected. That is a very useful feature if you have/add multiple files.

  4. disaster123 commented on Oct 3, 2017

    @disaster123

    +1

  5. gradinaruvasile commented on Oct 4, 2017

    @gradinaruvasile

    Something like this would be nice

    • tag option on the toolbar next to download link:
    • if clicked, expand the tag input form on horizontally (or maybe add it on a new line below as it is its current function in the details pane?)

    image

  6. disaster123 commented on Oct 4, 2017

    @disaster123
    • a listing of all tags for a file in the overview.
  7. jancborchardt commented on Oct 5, 2017

    @jancborchardt
    Member

    @gradinaruvasile we will only have a listing of the tags in the row, comparable to Gmail. Adding and removing tags in the row would be too much and too noisy. That’s done via the sidebar.

    @disaster123 that’s what we want to add, as said.

  8. disaster123 commented on Oct 5, 2017

    @disaster123

    @jancborchardt great - multiple colors or colors for tags would be great as well. If you have a lot of tags it gets very difficult to recognize them.

  9. jancborchardt commented on Oct 6, 2017

    @jancborchardt
    Member

    @disaster123 that's a different topic, you could open a separate issue for that. :)

  10. disaster123 commented on Oct 6, 2017

    @disaster123

    @jancborchardt thanks added: #6778

  11. 41 remaining items

  12. shu0406 commented on Feb 19, 2024

    @shu0406

    At school we have the problem that pupils can use and delete tags even if they do not have writing rights in that folder. So first step should be that the collaborative tags should respect given rights (write, delete) for every group.

  13. moved this to Enhancements in Files to vueon Aug 7, 2024
  14. SergioArbarviro commented on Dec 14, 2024

    @SergioArbarviro

    Hello to all,

    I agree with the summary above by @rickyelopez .

    Just discovered this feature and this thread, and I think the topics discussed above can be split into two general categories:

    1. Privacy/Security
       
       * Configure tag visibility for different users and groups
       * Configure tag modifiability for different users and groups
    

    In my views, the main functionality that tags are meant to perform is to give a fast and easy access to very diverse content. This fast and easy access happens because you can search by using:

    • a limited number of tags (ideally: one only);
    • tags belonging to different ways of looking at that diverse content (in our case: per topic, per geography, per readiness level...).

    Hence, the most important feature among those neatly summarised by @rickyelopez is, in my views, that an option should be given that the modification of tags be restricted to administrators (or to a small group). If not, you end up with a myriad of slightly misspelled tags, which results in a helpless fragmentation of the category of content that you intend to create. This becomes nightmarish to administer and ultimately kills the function of tags as I described above.

    Example: A taxonomy per geographic locations, with one tag per EU Member State, in a multilingual community. In the absence of this restriction to the edition of tags, you will rapidly end up having, for the concept of "Germany", and an initial official tag such as "DE - Germany", a flurry of alternatives such as DEU - Germany, DE. Germany, Deutschland, DE - Alemania, ...
    After a short while, it becomes impossible to search for content related to Germany because the list of tags to search for is (1) too large and (2) registered nowhere.

  15. godfuture commented on Dec 16, 2024

    @godfuture

    @SergioArbarviro
    Why should tags be owned by only admin or fixed group of users? I think there could be two types of tags. Private and public (collaborative). Public tags only live inside a group. This means tags should only exist in conjunction with their owner.

    Owner is a user or group:
    userXY:tagXY; groupXZ:tagXW; groupXV:tagXT

    The admin can add tags with empty owner and by this everyone on the server can see it (default tags).

    Modification should be driven by admin of either server or group. Those that manage the server are able to edit everything, and group admins can change group tags.

    As a consequence, tags with same name from different groups exist in parallel. But thats okay, if one group is deleted the tag with same name from other group will survive.

  16. SergioArbarviro commented on Dec 17, 2024

    @SergioArbarviro

    @godfuture
    I agree with you that the persons defining the tags could be a broader group than the administrators, and that one could imagine that the administrator of a group manages the tags relevant for that group.

    My concern relates to the pollution of these public tags (= editable by a restricted set of administrators only, for the server or for each group) by private tags. In the current version of NextCloud, anybody can start typing a tag and can create his/her own private tag that is "close" to the public tag (= with one or several typo errors, truncated), but not identical, just by typing "enter" (willingly or not) when the tag starts appearing on the tag search window. This new, private, "contaminated" tag is then proposed to other users that, without knowing it, use the "contaminated" version instead of the official one... and you end up with tens of slight variations of the same chain of characters to describe the same concept... making the tagging system useless.

    I understand that some use cases may want to leave complete freedom of the definition of tags by anyone. This is legitimate when the centres of interst are extremely diverse.

    In more professional use cases where the universe of issues to handle is finite and there is an interest in navigating fast to the content of interest, I believe that the option should be given that the ordinary users are not given the possibility to create their own "private" tags.

  17. godfuture commented on Dec 17, 2024

    @godfuture

    @SergioArbarviro
    I do not entirely agree. If users create a tag, by default it is shared with others. This is bad and needs to be prevented. I agree with you in this point.

    But I dont agree that users shall not be able to create their own and private tags which are not shared to others. If a user is polluting his tags with poo, then this poo is only in his user account. As drafted above, public and shared tags in a group would exist in parallel. Your own poo will not stink in other user accounts.

    So again, you are free to mess up your account, but you will not be able to mess with default tags on whole server or group tags, if you do not have permission.

    This way I dont understand your fear of tags going messed up. The messing up today is created because all tags are by default public.

  18. SergioArbarviro commented on Dec 18, 2024

    @SergioArbarviro

    @godfuture
    I thank you for your clarification and agree with your opinion. Indeed, if the tags produced by a user are "private" and hence visible to that user only, then indeed s/he can do whatever s/he wants, it has no consequence on the broader community.

  19. self-assigned this
    on Dec 19, 2024
  20. skjnldsv commented on Dec 19, 2024

    @skjnldsv
    Member

    Folks, please open a dedicated issue for the user tags (if there isn't one already)
    Tags are called Collaborative tags for a reason :)

    We do have some API for user tags already, this is how we store favorites for example.
    But it wasn't pushed further than that.

    Regarding that issue, most of the work is done now (31)
    Last part missing is #2143, which I quggest people follow that on the issue directly :)

  21. moved this from Enhancements to Done in Files to vueon Dec 19, 2024
  22. added
    4. to releaseReady to be released and/or waiting for tests to finish
    and removed
    1. to developAccepted and waiting to be taken care of
    on Dec 19, 2024
  23. added this to the Nextcloud 31 milestone on Dec 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions