Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: Multiple bugs concerning tags #51233

Open
6 of 9 tasks
Jerome-Herbinet opened this issue Mar 4, 2025 · 7 comments · May be fixed by #51288
Open
6 of 9 tasks

[Bug]: Multiple bugs concerning tags #51233

Jerome-Herbinet opened this issue Mar 4, 2025 · 7 comments · May be fixed by #51288

Comments

@Jerome-Herbinet
Copy link
Member

Jerome-Herbinet commented Mar 4, 2025

⚠️ This issue respects the following points: ⚠️

Bug description

  • restrict tag creation to admin not respected by frontend #51247
    • When tag creation is restricted to administrators (new feature), when a tag is entered in the search field, the creation suggestion should not appear. This creates confusion and, in any case, the error message is too generic (it just indicates that there is an error). End users might think this is a bug.
  • Bug 2: Any user who isn't an administrator can change the colour of tags (and this isn't logical or normal); at the very least, the colour should only change for the current user, otherwise it's a mess: in the current situation, any tag can change colour 10 times a year, depending on individual preferences (which will affect everyone on the platform). This also happens to tags created exclusively by administrators, which is all the more problematic. Apart from this problem, I think that colour changes should only be available for tags created by admins (in the admin settings, where the tags are created). The colour is then imposed by the admin for each tag, and this ensures that the colours don't change and that there's no possible confusion. As far as tags not created by admins are concerned, there are two solutions: the colour cannot be changed, or they can only be changed by admins and/or the creators of the tags in question.

Steps to reproduce

Check bug description above

Expected behavior

Check bug description above

Nextcloud Server version

31

Operating system

RHEL/CentOS

PHP engine version

PHP 8.2

Web server

Nginx

Database engine version

MariaDB

Is this bug present after an update or on a fresh install?

Updated from a MINOR version (ex. 32.0.1 to 32.0.2)

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

What user-backends are you using?

  • Default user-backend (database)
  • LDAP/ Active Directory
  • SSO - SAML
  • Other

Configuration report

{
    "passwordsalt": "***REMOVED SENSITIVE VALUE***",
    "secret": "***REMOVED SENSITIVE VALUE***",
    "trusted_domains": [
        "domain.fr"
    ],
    "datadirectory": "***REMOVED SENSITIVE VALUE***",
    "dbtype": "mysql",
    "version": "31.0.0.18",
    "overwrite.cli.url": "https:\/\/domain.fr",
    "dbname": "***REMOVED SENSITIVE VALUE***",
    "dbhost": "***REMOVED SENSITIVE VALUE***",
    "dbport": "",
    "dbtableprefix": "oc_",
    "mysql.utf8mb4": true,
    "dbuser": "***REMOVED SENSITIVE VALUE***",
    "dbpassword": "***REMOVED SENSITIVE VALUE***",
    "updater.release.channel": "beta",
    "installed": true,
    "instanceid": "***REMOVED SENSITIVE VALUE***",
    "log_type": "file",
    "logfile": "\/var\/log\/nextcloud\/domain.fr\/nextcloud.log",
    "redis": {
        "host": "***REMOVED SENSITIVE VALUE***",
        "password": "***REMOVED SENSITIVE VALUE***",
        "port": 6379,
        "dbindex": 3,
        "timeout": 0
    },
    "skeletondirectory": "",
    "logtimezone": "Europe\/Paris",
    "mail_smtpmode": "smtp",
    "mail_smtpsecure": "ssl",
    "mail_from_address": "***REMOVED SENSITIVE VALUE***",
    "mail_domain": "***REMOVED SENSITIVE VALUE***",
    "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
    "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
    "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
    "mail_smtpauthtype": "PLAIN",
    "default_language": "fr",
    "default_phone_region": "FR",
    "defaultapp": "files",
    "trashbin_retention_obligation": "20,40",
    "versions_retention_obligation": "auto,40",
    "check_for_working_wellknown_setup": false,
    "quota_include_external_storage": false,
    "cron_log": true,
    "has_internet_connection": true,
    "updatechecker": true,
    "appstoreenabled": true,
    "filelocking.enabled": true,
    "session_keepalive": true,
    "knowledgebaseenabled": true,
    "allow_user_to_change_display_name": true,
    "enable_previews": true,
    "enable_avatars": true,
    "auth.bruteforce.protection.enabled": true,
    "loglevel": 1,
    "log_rotate_size": 104857600,
    "mail_smtpauth": 1,
    "mail_smtpport": 465,
    "session_lifetime": 86400,
    "remember_login_cookie_lifetime": 1296000,
    "preview_max_filesize_image": 50,
    "activity_expire_days": 120,
    "maintenance_window_start": 1,
    "memcache.local": "\\OC\\Memcache\\APCu",
    "memcache.locking": "\\OC\\Memcache\\Redis",
    "memcache.distributed": "\\OC\\Memcache\\Redis",
    "app_install_overwrite": [
        "admin_audit",
        "user_ldap",
        "mailnotifier",
        "onlyoffice",
        "workspace"
    ],
    "ldapProviderFactory": "OCA\\User_LDAP\\LDAPProviderFactory",
    "maintenance": false
}

List of activated Apps

Enabled:
 - activity: 4.0.0
 - admin_audit: 1.21.0
 - app_api: 5.0.2
 - approval: 2.1.0
 - approve_links: 1.1.0
 - assistant: 2.4.0
 - bruteforcesettings: 4.0.0
 - calendar: 5.1.2
 - circles: 31.0.0-dev.0
 - collectives: 2.16.1
 - comments: 1.21.0
 - contacts: 7.0.1
 - contactsinteraction: 1.12.0
 - context_chat: 4.1.0
 - dashboard: 7.11.0
 - deck: 1.15.0
 - end_to_end_encryption: 1.17.0
 - federation: 1.21.0
 - files_downloadlimit: 4.0.0
 - files_lock: 31.0.1
 - files_pdfviewer: 4.0.0
 - files_reminders: 1.4.0
 - files_sharing: 1.23.1
 - files_trashbin: 1.21.0
 - files_versions: 1.24.0
 - firstrunwizard: 4.0.0
 - forms: 5.0.0
 - groupfolders: 19.0.3
 - impersonate: 2.0.0
 - integration_excalidraw: 2.4.0
 - integration_openai: 3.4.0
 - logreader: 4.0.0
 - mail: 4.2.2
 - mailnotifier: 0.0.3
 - nextcloud_announcements: 3.0.0
 - notes: 4.11.0
 - notifications: 4.0.0
 - openincryptpad: 0.3.7
 - ownershiptransfer: 1.1.0
 - password_policy: 3.0.0
 - photos: 4.0.0-dev.1
 - privacy: 3.0.0
 - recommendations: 4.0.0
 - related_resources: 2.0.0
 - richdocuments: 8.6.2
 - serverinfo: 3.0.0
 - sharebymail: 1.21.0
 - sharereview: 1.3.3
 - spreed: 21.0.0
 - support: 3.0.0
 - systemtags: 1.21.1
 - tables: 0.9.0
 - tasks: 0.16.1
 - text: 5.0.0
 - updatenotification: 1.21.0
 - user_ldap: 1.22.0
 - user_status: 1.11.0
 - users_picker: 1.2.0
 - weather_status: 1.11.0
 - webhook_listeners: 1.2.0
 - whiteboard: 1.0.5
 - workspace: 4.0.2-rc2
Disabled:
 - encryption: 2.19.0
 - files_external
 - onlyoffice: 9.7.0
 - survey_client: 3.0.0
 - suspicious_login
 - twofactor_nextcloud_notification
 - twofactor_totp

Nextcloud Signing status

No errors have been found.

Nextcloud Logs

Can be provided if necessary

Additional info

Can be provided if necessary

@Jerome-Herbinet Jerome-Herbinet added 0. Needs triage Pending check for reproducibility or if it fits our roadmap bug feature: tags 31-feedback feature: files labels Mar 4, 2025
@susnux
Copy link
Contributor

susnux commented Mar 4, 2025

point 2 sounds contra intuitive as the reason for collaborative tags is to be collaborative meaning multiple users can work with. So similar to github I expect the tags to be shares "use the red tag" should also be the red tag on that other users account.

@Jerome-Herbinet
Copy link
Member Author

Jerome-Herbinet commented Mar 4, 2025

point 2 sounds contra intuitive as the reason for collaborative tags is to be collaborative meaning multiple users can work with. So similar to github I expect the tags to be shares "use the red tag" should also be the red tag on that other users account.

I'm aware of this collaborative aspect if tags... but, in real life, with large to very large Nextcloud instances, I can actually bet that there will be issues because there will always be a part of users that we can't obviously trust to take the right decisions : they will change color even if it's forbidden (which will create confusion for users who took their habits with old colors), or create unrelevant / inconsistent tags ... In large organizations, it's not possible to trust everyone in this context. This leads me to suggest another thing ; 3 user levels :

  • admins can fully manage all tags
  • delegated admins can do the same but without all other admin settings
  • Regular users can't manage tags at all, or can only create and manage personal tags which can't bee seen and managed by others (including admins and delegated admins)

@susnux
Copy link
Contributor

susnux commented Mar 4, 2025

If tag creation is restricted to admin yes. Otherwise users should share the colors IMHO.

@Jerome-Herbinet
Copy link
Member Author

If tag creation is restricted to admin yes. Otherwise users should share the colors IMHO.

We have different opinions on this 🙂

I think that on large instances, if everyone starts messing with the colors, the labels will change color regularly like Christmas tree lights, and it will be the same mess with the names.

This is even more of a problem if the label was created by an administrator. There is no reason or logic for users to be able to change the color. In the case of labels managed by administrators, the colors should only be manageable by administrators.

We have to take into account that labels are part of processes, such as helping to organize and qualify files, and that all this is often documented within organizations. So, we cannot allow users to touch labels created by administrators.

If people do what they want, it must be understood that people who do not have the context, or are not rigorous, or do not have an overview to determine whether or not the creation or modification of a label is relevant, it will one day or another necessarily be a mess (e.g.: useless labels because redundant which will disturb other people who will confuse them; this could cause poorly labeled files to escape certain automated flows).

In other words, apart from administrators (and delegated administrators that I propose to add), labels must be strictly personal (even if you add a parameter to allow the 2 behaviors for normal users: collaborative or individual labels).

I would like to broaden the discussion to other people to see things can be changed in the sense of what I describe.

@jancborchardt @nickvergessen @skjnldsv ? or others ?

@nickvergessen
Copy link
Member

I think it makes sense to limit coloring to the user creating the label or the admin.

@skjnldsv
Copy link
Member

skjnldsv commented Mar 5, 2025

I think it makes sense to limit coloring to the user creating the label or the admin.

I remember taking the same decision with a discussion with @Altahrim on #49514
Maybe this got lost along the way 🤔

@susnux
Copy link
Contributor

susnux commented Mar 5, 2025

There is no reason or logic for users to be able to change the color.

There could be plenty reasons to do so, especially if you do not have a structure like "admin setup everything" but smaller work groups where people create and organize things in their teams.

In the case of labels managed by administrators, the colors should only be manageable by administrators.

If there is a special "admin label" then yes fully agree with you

@skjnldsv skjnldsv self-assigned this Mar 5, 2025
@skjnldsv skjnldsv added 2. developing Work in progress and removed 0. Needs triage Pending check for reproducibility or if it fits our roadmap labels Mar 5, 2025
@skjnldsv skjnldsv linked a pull request Mar 5, 2025 that will close this issue
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants