Answers.Body: <p>Neither assets nor users support multi-site. Their <em>content</em> does (i.e. custom fields for assets and/or users can be &quot;translatable&quot;), but all assets and users will always propagate to all the sites in the install, and there's no feasible way to prevent that.</p>
  <blockquote>
  <p>The only way I can see of achieving GOAL 2 is to have a separate Volume for each site</p>
  </blockquote>
  <p>Correct, the only way to effectively &quot;hide&quot; assets from specific users or user groups, is to create a separate volume (and not give those users or groups access to it).</p>
  <p>You don't necessarily have to create different/multiple asset <em>fields</em>, though – just give your asset fields access to all the volumes in their &quot;Sources&quot; setting, and make sure the &quot;Show unpermitted volumes&quot; setting is unchecked.</p>
  <p>A clean-ish way to do it could be to create one user group per site, with the appropriate permissions configured (i.e. &quot;User Group Site A&quot; is able to view &quot;Volume Site A&quot;, etc). Users can belong to multiple groups, which means that a single user could be put into one or multiple groups giving them the appropriate per-site permissions.</p>
  <p>Adding a new site with a setup like that should still be relatively simple – add the site, add the new volume, and then create the new user group giving access to that site and volume.</p>
  <blockquote>
  <p>content editors should be able to invite colleagues to their site. But they should not have visibility of user groups or content editors belonging to other sites.</p>
  </blockquote>
  <p>I'm not seeing a way to achieve this without resorting to some kind of &quot;hack&quot;.</p>
  <p>Potentially, you could create a <a href="https://craftcms.com/docs/5.x/extend/module-guide.html" rel="nofollow noreferrer">custom Yii module</a>, that taps into the <code>craft\elements\User::EVENT_REGISTER_SOURCES</code> event, checks the user group for the currently logged-in user, and unsets the sources for the <em>other</em> user groups, that this user shouldn't have access to.</p>
  <p>Another, and possible simpler option could be to use the <a href="https://plugins.craftcms.com/cp-css?craft5" rel="nofollow noreferrer">CPCSS</a> and <a href="https://plugins.craftcms.com/cp-body-classes?craft5" rel="nofollow noreferrer">Control Panel Body Classes</a> plugins in order to <em>hide</em> the unwanted user group sources from the CP.</p>
  <p>Neither of these options should be considered &quot;safe&quot;. I.e. if a user in site A has access to the Users section and is a bit savvy, they will probably find a way to view the data that they're not supposed to see.</p>
  <p>IMO, in the end both of these problems are signals that your use-case might be a bad fit for Craft CMS's multi-site feature. When it comes to assets and users, the system is not designed to work the way you need it to, and trying to work around that might not be the best idea (especially long-term, or if it's crucial that assets or users data does not &quot;leak&quot; between sites).</p>
  <p>Personally, I'd either live with the limitations, or if that's a non-starter, consider if these sites would work better as standalone Craft installs (potentially using the same codebase/repo, to reduce maintenance/upkeep).</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-04-08T10:35:49.330Z
Answers.Text: The last paragraph was my thought exactly. Build once, deploy many. One code-base with separate installs for every site. Environment variables for everything that's different between the sites (primary domain etc).
Answers.UserDisplayName: MoritzLost
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-04-08T22:35:56.603Z
Answers.Text: Brilliant answer - glad to be set right about asset fields. I'd got it in my head they can only use one Volume at a time because the one I quickly looked at had "Restrict assets to a single location" checked ‍♂️
Answers.UserDisplayName: Karl Bishop
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-04-08T22:42:34.113Z
Answers.Text: I take the point about the use-case being a bad fit for Craft. But using different Volumes as you suggested leaves just the one limitation which we can live with - it's far easier for us to centrally manage Users than have a separate Craft install per site. And maybe User management permissions will become more granular some time in the future.
Answers.UserDisplayName: Karl Bishop
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-04-08T10:22:00.863Z
Answers.LastActivityDate: 2024-04-08T10:28:21.023Z
Answers.LastEditDate: 2024-04-08T10:28:21.023Z
Answers.UserDisplayName: Mats Mikkel Rummelhoff
Body: <p>We have multiple sites defined in Craft and we want content editors to only have visibility of things that are relevant to the one site they've been assigned to.</p>
  <p>I've set this up using a User Group for each site that has permissions to edit only that site. But there are three major goals I am unable to achieve at the same time:</p>
  <p><strong>GOAL 1</strong>: it must be as easy as possible to add more sites in future when needed.</p>
  <p>To achieve GOAL 1, all sites use the same Globals, Sections and Entry Types. This works well but contradicts with GOAL 2.</p>
  <p><strong>GOAL 2</strong>: content editors should not be able to see folders and files belonging to other sites.</p>
  <p>I can't achieve GOAL 2 at the moment because all sites using the same Globals, Sections and Entry Types means they all use the same Asset Fields and therefore all content editors need access to the same Volumes.</p>
  <p>Asset Locations are defined using <code>{site.handle}</code> in the path, so file locations are siloed by site just fine. But content editors can see folders and files belonging to other sites on the Assets screen.</p>
  <p>The only way I can see of achieving GOAL 2 is to have a separate Volume for each site... but I think that would go against GOAL 1 because then every site would need to use different Asset Fields and consequently we'd need a complicated set up within Entry Types and Globals of duplicated Asset Fields that are hidden conditionally by User Group.</p>
  <p>Does anyone know of a way to achieve GOAL 2 without majorly contradicting GOAL 1?</p>
  <p><strong>GOAL 3</strong>: content editors should be able to invite colleagues to their site. But they should not have visibility of user groups or content editors belonging to other sites.</p>
  <p>I can't see a way of achieving this. It looks like everyone who has access to the Users screen can see all users and user groups. Does anyone know a way around this?</p>
  
Tags: <users><permissions><sites>
Title: Is it possible to silo Users and their Content absolutely by site?
ThreadText: # Is it possible to silo Users and their Content absolutely by site?
  
  (Asked by: username_0 on 2024-04-08)
  
  We have multiple sites defined in Craft and we want content editors to only have visibility of things that are relevant to the one site they've been assigned to.
  
  I've set this up using a User Group for each site that has permissions to edit only that site. But there are three major goals I am unable to achieve at the same time:
  
  **GOAL 1**: it must be as easy as possible to add more sites in future when needed.
  
  To achieve GOAL 1, all sites use the same Globals, Sections and Entry Types. This works well but contradicts with GOAL 2.
  
  **GOAL 2**: content editors should not be able to see folders and files belonging to other sites.
  
  I can't achieve GOAL 2 at the moment because all sites using the same Globals, Sections and Entry Types means they all use the same Asset Fields and therefore all content editors need access to the same Volumes.
  
  Asset Locations are defined using `{site.handle}` in the path, so file locations are siloed by site just fine. But content editors can see folders and files belonging to other sites on the Assets screen.
  
  The only way I can see of achieving GOAL 2 is to have a separate Volume for each site... but I think that would go against GOAL 1 because then every site would need to use different Asset Fields and consequently we'd need a complicated set up within Entry Types and Globals of duplicated Asset Fields that are hidden conditionally by User Group.
  
  Does anyone know of a way to achieve GOAL 2 without majorly contradicting GOAL 1?
  
  **GOAL 3**: content editors should be able to invite colleagues to their site. But they should not have visibility of user groups or content editors belonging to other sites.
  
  I can't see a way of achieving this. It looks like everyone who has access to the Users screen can see all users and user groups. Does anyone know a way around this?
  
  **Tags:** users, permissions, sites
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2024-04-08. Score: 3 | Accepted answer
  
  Neither assets nor users support multi-site. Their *content* does (i.e. custom fields for assets and/or users can be "translatable"), but all assets and users will always propagate to all the sites in the install, and there's no feasible way to prevent that.
  
  > The only way I can see of achieving GOAL 2 is to have a separate Volume for each site
  
  Correct, the only way to effectively "hide" assets from specific users or user groups, is to create a separate volume (and not give those users or groups access to it).
  
  You don't necessarily have to create different/multiple asset *fields*, though – just give your asset fields access to all the volumes in their "Sources" setting, and make sure the "Show unpermitted volumes" setting is unchecked.
  
  A clean-ish way to do it could be to create one user group per site, with the appropriate permissions configured (i.e. "User Group Site A" is able to view "Volume Site A", etc). Users can belong to multiple groups, which means that a single user could be put into one or multiple groups giving them the appropriate per-site permissions.
  
  Adding a new site with a setup like that should still be relatively simple – add the site, add the new volume, and then create the new user group giving access to that site and volume.
  
  > content editors should be able to invite colleagues to their site. But they should not have visibility of user groups or content editors belonging to other sites.
  
  I'm not seeing a way to achieve this without resorting to some kind of "hack".
  
  Potentially, you could create a [custom Yii module](https://craftcms.com/docs/5.x/extend/module-guide.html), that taps into the `craft\elements\User::EVENT_REGISTER_SOURCES` event, checks the user group for the currently logged-in user, and unsets the sources for the *other* user groups, that this user shouldn't have access to.
  
  Another, and possible simpler option could be to use the [CPCSS](https://plugins.craftcms.com/cp-css?craft5) and [Control Panel Body Classes](https://plugins.craftcms.com/cp-body-classes?craft5) plugins in order to *hide* the unwanted user group sources from the CP.
  
  Neither of these options should be considered "safe". I.e. if a user in site A has access to the Users section and is a bit savvy, they will probably find a way to view the data that they're not supposed to see.
  
  IMO, in the end both of these problems are signals that your use-case might be a bad fit for Craft CMS's multi-site feature. When it comes to assets and users, the system is not designed to work the way you need it to, and trying to work around that might not be the best idea (especially long-term, or if it's crucial that assets or users data does not "leak" between sites).
  
  Personally, I'd either live with the limitations, or if that's a non-starter, consider if these sites would work better as standalone Craft installs (potentially using the same codebase/repo, to reduce maintenance/upkeep).
  
  > **Comments:**
  > **username_2**: The last paragraph was my thought exactly. Build once, deploy many. One code-base with separate installs for every site. Environment variables for everything that's different between the sites (primary domain etc).  
  > **username_0**: Brilliant answer - glad to be set right about asset fields. I'd got it in my head they can only use one Volume at a time because the one I quickly looked at had "Restrict assets to a single location" checked ‍♂️  
  > **username_0**: I take the point about the use-case being a bad fit for Craft. But using different Volumes as you suggested leaves just the one limitation which we can live with - it's far easier for us to centrally manage Users than have a separate Craft install per site. And maybe User management permissions will become more granular some time in the future.  
  
  ---
  
  