Sharing to group doesn't list newly created group

[Aesculapius]

Steps to reproduce

1. Create a new group and add some users to it
2. Create a new folder and share this folder with a group
3. Type in the group name

Expected behaviour

Would like to share a folder with a just created group of users

Actual behaviour

The interfaces tells me that specific group doesn't exist....but it does.

Server configuration detail

Operating system: Linux 4.4.0-109-generic #132-Ubuntu SMP Tue Jan 9 19:52:39 UTC 2018 x86_64

Webserver: Apache/2.4.25 (Ubuntu) (apache2handler)

Database: mysql 5.7.21

PHP version: 7.0.25-0ubuntu0.16.04.1
Modules loaded: Core, date, libxml, openssl, pcre, zlib, filter, hash, Reflection, SPL, session, standard, apache2handler, redis, mysqlnd, PDO, xml, calendar, ctype, curl, dom, mbstring, fileinfo, ftp, gd, gettext, iconv, imap, json, exif, mysqli, pdo_mysql, Phar, posix, readline, shmop, SimpleXML, sockets, sysvmsg, sysvsem, sysvshm, tokenizer, wddx, xmlreader, xmlwriter, xsl, zip, Zend OPcache

Nextcloud version: 13.0.1 - 13.0.1.1

Updated from an older Nextcloud/ownCloud or fresh install:

Where did you install Nextcloud from: unknown

Signing status

Array

List of activated apps

Enabled:
 - activity: 2.6.1
 - admin_audit: 1.3.0
 - admin_notifications: 1.0.1
 - announcementcenter: 3.2.1
 - bruteforcesettings: 1.0.3
 - calendar: 1.6.1
 - comments: 1.3.0
 - contacts: 2.1.3
 - dav: 1.4.6
 - deck: 0.3.1
 - federatedfilesharing: 1.3.1
 - federation: 1.3.0
 - files: 1.8.0
 - files_accesscontrol: 1.3.0
 - files_automatedtagging: 1.3.0
 - files_downloadactivity: 1.2.0
 - files_external: 1.4.1
 - files_pdfviewer: 1.2.1
 - files_sharing: 1.5.0
 - files_texteditor: 2.5.1
 - files_trashbin: 1.3.0
 - files_versions: 1.6.0
 - files_videoplayer: 1.2.0
 - gallery: 18.0.0
 - impersonate: 1.0.3
 - issuetemplate: 0.3.0
 - logreader: 2.0.0
 - lookup_server_connector: 1.1.0
 - nextcloud_announcements: 1.2.0
 - notifications: 2.1.2
 - oauth2: 1.1.0
 - password_policy: 1.3.0
 - provisioning_api: 1.3.0
 - quota_warning: 1.2.0
 - ransomware_protection: 1.1.0
 - richdocuments: 2.0.4
 - serverinfo: 1.3.0
 - sharebymail: 1.3.0
 - survey_client: 1.1.0
 - systemtags: 1.3.0
 - theming: 1.4.1
 - twofactor_backupcodes: 1.2.3
 - updatenotification: 1.3.0
 - workflowengine: 1.3.0
Disabled:
 - activitylog
 - deck-2018-01-10
 - deck-old
 - dicomviewer
 - encryption
 - files_retention
 - files_snapshots
 - firstrunwizard
 - mail
 - spreed
 - spreedme
 - user_external
 - user_ldap

Configuration (config/config.php)

{
    "instanceid": "***REMOVED SENSITIVE VALUE***",
    "passwordsalt": "***REMOVED SENSITIVE VALUE***",
    "datadirectory": "***REMOVED SENSITIVE VALUE***",
    "dbtype": "mysql",
    "version": "13.0.1.1",
    "dbname": "***REMOVED SENSITIVE VALUE***",
    "dbhost": "***REMOVED SENSITIVE VALUE***",
    "dbtableprefix": "oc_",
    "dbuser": "***REMOVED SENSITIVE VALUE***",
    "dbpassword": "***REMOVED SENSITIVE VALUE***",
    "overwritewebroot": "\/",
    "installed": true,
    "forcessl": true,
    "maintenance": false,
    "trashbin_retention_obligation": "auto,90",
    "preview_libreoffice_path": "\/usr\/bin\/libreoffice",
    "theme": "",
    "has_internet_connection": true,
    "check_for_working_webdav": true,
    "check_for_working_htaccess": true,
    "memcache.local": "\\OC\\Memcache\\Redis",
    "filelocking.enabled": true,
    "memcache.distributed": "\\OC\\Memcache\\Redis",
    "memcache.locking": "\\OC\\Memcache\\Redis",
    "redis": {
        "host": "***REMOVED SENSITIVE VALUE***",
        "port": 6379,
        "timeout": 0,
        "dbindex": 0
    },
    "trusted_domains": [
        "arc.int32.nl"
    ],
    "mail_from_address": "***REMOVED SENSITIVE VALUE***",
    "mail_smtpmode": "smtp",
    "mail_domain": "***REMOVED SENSITIVE VALUE***",
    "secret": "***REMOVED SENSITIVE VALUE***",
    "asset-pipeline.enabled": true,
    "preview_max_scale_factor": 1,
    "forceSSLforSubdomains": true,
    "app.mail.imaplog.enabled": true,
    "loglevel": 2,
    "appstore.experimental.enabled": true,
    "overwrite.cli.url": "https:\/\/arc.int32.nl",
    "mail_smtpauthtype": "LOGIN",
    "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
    "mail_smtpport": "25"
}

[Aesculapius]

It seems to be caused by this setting, which is a good thing initially:

But for some users eg. admins, it should be possible to breach that restriction and share with groups they're not necessarily part of... How can that be accomplished?

[schiessle]

But for some users eg. admins, it should be possible to breach that restriction and share with groups they're not necessarily part of... How can that be accomplished?

At the moment not. Either you restrict sharing to group members or not. Having a setting "Restrict users to only share with users in their group" and then a sub-setting "exclude admins" sounds quite confusing to me. Also what about all the other settings? Should be exclude the admins (optionally) from all restrictions? This sounds like a huge mess.

Also, why should have admins different share settings? The only difference between a admin and a normal user is that the admin is allowed to change the configuration of the instance. But for his day-to-day operations like sharing a file I don't see why a admin should have special permissions.

cc @jancborchardt what do you think?

[Aesculapius]

Not necessarily for admins only, I think.

The 'prohibit sharing outside your own groups' is an almost required feature in lots of situations I think, as you would expose other user names/details otherwise. But it at the same time limits the ability to share outside your own groups.

For example;

• I want to set up a shared folder for a few users (a workgroup)
• I don't need to be in that specific workgroup myself
• I don't want those users to see all other users on the nextcloud installation

doesn't seem possible with current settings? What I've done now, as a workaround, is to temporarily disable the option to disallow sharing outside own groups, then share the item with the just made group, then enabled the setting again.

[schiessle]

The 'prohibit sharing outside your own groups' is an almost required feature in lots of situations I think, as you would expose other user names/details otherwise. But it at the same time limits the ability to share outside your own groups.

Sure, it is a trade-off at the end. But if you say that it is not "admins only", this makes it even more complicated. Should we have a white list of users we exclude from restrictions? Should this white list be for all admin settings or just for a few? Should we introduce a white list for each individual settings? I hope you see the problem.

• I want to set up a shared folder for a few users (a workgroup)
• I don't need to be in that specific workgroup myself
• I don't want those users to see all other users on the nextcloud installation

Why don't you let the workgroup or the (work-)group admin take care of these folders?

doesn't seem possible with current settings? What I've done now, as a workaround, is to temporarily disable the option to disallow sharing outside own groups, then share the item with the just made group, then enabled the setting again.

Yes, this is a possible work around, although ugly. But maybe the best we can offer for this really special use case. Because as you can see on all the question marks above, a exception to this settings would raise a lot of questions/problems. Of course feel free to share your thoughts if you have some ideas how to answer the question in a general useful way.

[Aesculapius]

Thanks for your reply.

Should this white list be for all admin settings or just for a few? Should we introduce a white list for each individual settings? I hope you see the problem.

Well, actually that might be something to think about in general. Of course it should be with a clean interface and maybe not for every setting as it would be useless in some situations (exclude someone/groups from an exclude sertting would be one), but it would definately make nextcloud immensely more configurable to individual configurations. The existing fields used to exclude users or groups that is used for certain settings or apps would suffice. But I can see that it'd be a lot of work...

Why don't you let the workgroup or the (work-)group admin take care of these folders?

Two reasons: I want part to be read-only for them, making one of them owner would render that impossible I think. Second one: backup on the backend is done on user level and I'd have to include that specific user in the backup profile (but only want few folders backupped). But yeah, that would be the easiest solution maybe having the above compromise.

[jancborchardt]

I can see where @Aesculapius is coming from, and of course I understand @schiessle’s concern. A whitelist or blacklist is definitely a no-go, that’s just a total cop-out regarding UX.

I’d say let’s see if this comes up more. Maybe an admin override setting like mentioned above isn’t so bad.

[jancborchardt]

cc @nextcloud/designers

[nextcloud-bot]

Hey, this issue has been closed because the label stale is set and there were no updates for 14 days. Feel free to reopen this issue if you deem it appropriate.

(This is an automated comment from GitMate.io.)