Repository navigation
Team setting: enable/disable sharing of team resources #2645
Description
How to use GitHub
- Please use the 👍 reaction to show that you are interested into the same feature.
- Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
- Subscribe to receive notifications on status change and new comments.
Feature request
Is your feature request related to a problem? Please describe.
When a team owns resources, like a team folder, collective, deck or others, it would be good to have the option to ensure all access is 100% mediated through team membership. This simplifies the task of keeping a clear overview of access rights. Many larger organizations have arranged their access control along team lines.
Describe the solution you'd like
At a team level, you can disable sharing of team resources outside the team. This should be split out for:
- internal shares
- federated shares
- public link shares
Discussion
Of course, a follow-up will be: can we allow resharing only for team owners/admins? For this, see #2646 - team member roles (read/write, (re)sharing).
I suppose that for the Team it would just be a flag, while apps then have to respect that. Maybe the unified sharing can play a role here.
When you restrict sharing of any of the options, what do we do? Options:
- Check if any of the Team's owned resources are currently shared. If they are, give a warning and don't allow disabling the sharing.
- Follow what ACL's do - all existing shares stop working if you disallow sharing.
Activity
[-]Team setting: allow re-sharing[/-][+]Team setting: enable/disable sharing of team resources[/+]Rikdekker commentedon Sep 20, 2026
Three notes from working on team resources in Talk, in case they help the triage.
"It would just be a flag, while apps then have to respect that"
This is the part I would gently push back on: a flag apps may respect tends to
hold everywhere except the one place that matters.
There is already a working precedent for the enforcing variant on the same
server. The Governance app blocks sharing by classification, and we measured it
on NC 34.0.2: creating a public link on a classified file returns 403 "You are
not allowed to share …", regardless of which app asks, because the check sits
in the storage layer (
files_accesscontrol's wrapper) rather than in each app'ssharing UI. Its subject model is also already what this issue needs —
SubjectTypeisEVERYONE | USER | GROUP | TEAM, withTEAMresolving throughCircles.
What it does not have is the other half:
LabelScopeisFILES | MAILSonly,sensitivity is hardcoded to single files (not even folders, so no container
inheritance), and enforcement never leaves Files.
I am not proposing this issue should depend on that app — it is enterprise-only.
The narrower point: an enforcing mechanism has been demonstrated, so "a flag
apps respect" is not the only option. If the team setting is defined now with
enforcement in mind, the two can meet later rather than diverge.
The open question about existing shares
The second option is cheaper than it sounds, and is how the classification route
already behaves. Because the check happens at access time rather than share
time, existing shares need not be found, warned about or cleaned up — they stop
resolving.
One detail worth copying: it answers 404, not 403, deliberately, so that
revoking access does not leak that the resource exists. For a team tightening
its setting after the fact that distinction matters — 403 says "this still
exists and you lost access", 404 says nothing.
The split is three options, but arguably four
Internal / federated / public link — I would suggest the first is really two,
because the lifecycle guarantee differs:
That is exactly the off-boarding concern #2644 opens with. When an internal
member leaves, your own process closes the door; when someone leaves a partner
organisation, whether their account disappears is that organisation's decision
and this team never finds out. So for a team handling HR or procurement
material, "this server only" is a materially different promise from "trusted
partners allowed" — and not one federated accounts can make, however trusted the
partner. Nextcloud already names this distinction internally: Talk's
CallProviderchecksisLocalSystemBook !== truewith the comment "Notinternal user".
Talk also already carries the kinds this would need —
users,federated_users,emails,guests,phones— so an ordered scale isavailable without inventing anything:
Each step adds one kind, ordered by how much is known about the person, which
also makes it explainable in a sentence. Worth something here: the Microsoft
equivalent ends up as a matrix where a guest can join a private channel but not
a shared one, an external participant the reverse, and the channel type cannot
be changed afterwards.
alimmroth commentedon Oct 15, 2026
The option to disable sharing outside of the team is an important requirement for our customer as well!