Setting permissions on nested SGs

Question

I have a scenario in Tridion like this, with a handful of SGs and pages sitting in the root of a publication:

My requirement is to allow a certain group of users to publish content only from SG A. Ideally they would only be able to see SG A, but this is not a firm requirement.

This is quite straightforward on SG B and SG C, I can set the Permissions to deny read access for the group. However, I don't see a way to restrict publishing access to the loose pages in the root.

So far I've considered the following:

1. Publishing rights are set on the publishing target types, so this is not granular enough to handle what I need.
2. If I explicitly deny read access on the root for the group, but explicitly grant access to SG A, SG A is still unreachable and throws an error.
3. If I set SG A to be a favourite of the users in the group and have them access it directly from the favourites menu, bypassing the root structure group, it has the same issue as in point 2 above.
4. I could move all the loose pages into a SG. However, the homepage should still be in the root of the url, at www.clientsite.com, not www.clientsite.com/home or something like that. I could use the solutions provided here: How to override page publish url or path while publishing?, namely URL Rewrite, but this seems like a complicated solution to handle what I'm sure is not an uncommon use case.
5. I could also use custom page/SG metadata and a GUI extension, but again, this seems like a complicated solution to handle the scenario.

Am I missing an obvious solution to this scenario? It seems like a simple and common enough use case that it shouldn't require significant development.

Answer 1

I would imagine there would be a more general solution than this, but the one I am currently implementing is to manage publishing at the component level, rather than the page level. To this I have:

1. Removed read access to the root for this group of publishers.
2. Sorted the components used on pages within SG A into a folder, then given read/write access to this folder for the group and explicitly denied access to all other folders (all components are in at least one level of folder).
3. Trained the users to publish the components, not the pages. In the case of DCPs this is standard anyway. In the case of static CPs this is unusual, but does republish the page they are embedded on.

This solution works for a few very specific reasons for this organization:

1. The users in this group only need to edit components, and do not need to edit pages.
2. Components for this section of pages are not reused on pages for which the group should not be able to publish.

I view this as a temporary solution, something to meet a very specific use case while I implement a more permanent solution such as those suggested by Dominic, but it might be useful for someone else, so I'm going to post it as an answer, but not accept it.

Answer 2

You could make a separate publication that inherits from this one, and there give the users the relevant rights. Then you'd have to do whatever magic was necessary on the content delivery side to get the pages to the right place.

Another approach, probably better, is to use the events system. You could create an "on publish" event that checks the permissions and decides whether or not to abort the publish. You could use any kind of metadata or application data for this, but probably the most obvious would be to create a group that the people had to be in to publish in a given location.