nextcloud / nextcloud/server

[Bug]: When changing the permissions of a share to can edit and reloading the page, custom permissions is displayed

Open
#44,856 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

0. Needs triage 27-feedback bug feature: sharing
Dominant language
PHP
Stars
36.9k
Forks
5.2k
Avg merge
2d 3h
Merged PRs (30d)
713

Description

⚠️ This issue respects the following points: ⚠️
Bug description

When creating a share with custom permissions with an enforced password and a default expiration date, the following bug occurs:
When the created share is changed from custom permissions to can edit and then the page is refreshed, the share is displayed as custom permissions instead of can edit. But the permissions of can edit are applied correctly to the share. This happens only when changing the share to can edit and then refreshing the page. When creating a share with custom permissions and then changing it to view only, the bug does not occur. Also, when creating a share with view only permissions and then changing it to can edit, the bug occurs as the permissions are then shown as custom permissions instead of can edit.

The bug was reproduced on a fresh installation of Nextcloud 27.1.7 (using the Docker container). On 27.1.5 it could not be reproduced.

Steps to reproduce

Configure the following under administration settings -> sharing:

  1. Enforce password protection
  2. Set default expiration date (180 days)
  3. Remove everything by default share permissions
  4. Create a share with the instruction found in the description of the bug.
Expected behavior

The share permissions, which are changed to can edit, still display can edit, even if the page is reloaded.

Installation method

None

Nextcloud Server version

27

Operating system

None

PHP engine version

None

Web server

Apache (supported)

Database engine version

SQlite

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

Fresh Nextcloud Server install

Are you using the Nextcloud Server Encryption module?

None

What user-backends are you using?
  • Default user-backend (database)
  • LDAP/ Active Directory
  • SSO - SAML
  • Other
Configuration report
{
    "system": {
        "htaccess.RewriteBase": "\/",
        "memcache.local": "\\OC\\Memcache\\APCu",
        "apps_paths": [
            {
                "path": "\/var\/www\/html\/apps",
                "url": "\/apps",
                "writable": false
            },
            {
                "path": "\/var\/www\/html\/custom_apps",
                "url": "\/custom_apps",
                "writable": true
            }
        ],
        "upgrade.disable-web": true,
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "localhost:8080"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "sqlite3",
        "version": "27.1.7.2",
        "overwrite.cli.url": "http:\/\/localhost:8080",
        "installed": true
    }
}
List of activated Apps
Enabled:
  - activity: 2.19.0
  - circles: 27.0.1
  - cloud_federation_api: 1.10.0
  - comments: 1.17.0
  - contactsinteraction: 1.8.0
  - dashboard: 7.7.0
  - dav: 1.27.0
  - federatedfilesharing: 1.17.0
  - federation: 1.17.0
  - files: 1.22.0
  - files_pdfviewer: 2.8.0
  - files_reminders: 1.0.0
  - files_rightclick: 1.6.0
  - files_sharing: 1.19.0
  - files_trashbin: 1.17.0
  - files_versions: 1.20.0
  - firstrunwizard: 2.16.0
  - logreader: 2.12.0
  - lookup_server_connector: 1.15.0
  - nextcloud_announcements: 1.16.0
  - notifications: 2.15.0
  - oauth2: 1.15.2
  - password_policy: 1.17.0
  - photos: 2.3.0
  - privacy: 1.11.0
  - provisioning_api: 1.17.0
  - recommendations: 1.6.0
  - related_resources: 1.2.0
  - serverinfo: 1.17.0
  - settings: 1.9.0
  - sharebymail: 1.17.0
  - support: 1.10.0
  - survey_client: 1.15.0
  - systemtags: 1.17.0
  - text: 3.8.0
  - theming: 2.2.0
  - twofactor_backupcodes: 1.16.0
  - updatenotification: 1.17.0
  - user_status: 1.7.0
  - viewer: 2.1.0
  - weather_status: 1.7.0
  - workflowengine: 2.9.0
Disabled:
  - admin_audit: 1.17.0
  - bruteforcesettings: 2.7.0
  - encryption: 2.15.0
  - files_external: 1.19.0
  - suspicious_login: 5.0.0
  - twofactor_totp: 9.0.0
  - user_ldap: 1.17.0
Nextcloud Signing status
No errors have been found.
Nextcloud Logs

No response

Additional info

No response

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the behavior described in the issue with the files_sharing app on a current Nextcloud checkout, then trace the sharing-permission UI handling across a page reload. Done means a share changed to “can edit” continues to display that permission after reloading, while the existing reproduction cases remain correct.

Written by the indexing model from the issue text.

Assessment

Tech stack
php
Domain
frontend
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
32/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.