This idea sprang off of #1348 where two Drupal contrib modules were suggested as a possible solution to the issue reported. These modules are Content Access and Simple Access (Taxonomy Access Control has also been mentioned). @biolithic has started a port of Content Access in https://github.com/biolithic/content_access and @Graham-72 ported Simple Access in https://github.com/backdrop-contrib/simple_access
It's worth mentioning as a reference https://github.com/backdrop-ops/contrib/issues/105 too.
In #1348 there was this idea also for what could be implemented in core:
From a brief look at the features of these two modules, I have to say that Simple Access seems more ...well "simple" and useful to me. But that might be because I have specific use-cases in mind that happen to match its features and its "mechanics" (I like the approach of leaving the rest of the content accessible by everyone instead of the other way around). [...]
From their UI screenshots available on d.org, I have to say that they seem a bit "too much" for core inclusion, but I still would like to see something like that offered by core. Perhaps a simplified version (UI-wise) could be put together. I was thinking something along the following lines perhaps: 1. A flag that simplifies the distinction of "private" (more fine-grained access control) vs "public" (access content permission) nodes. 2. A per-content type setting that provides the following options: 1. no privacy flag feature at all (the default for all content types). 2. allow specific nodes of that type to be set as "private" (give authors an option). 3. make it so that all nodes of that type are set to "private" (no option given to node author). 3. A set of permissions for allowing users to edit node privacy (allow edit all/own privacy flags). 4. A second set of permissions to allow specific role(s) to view all "private" nodes (in essence a permission to override this feature altogether - intended for admins). 5. A per-node "make this page/article private" checkbox (available to users with the respective permission from 3 above - provided to nodes of type that are set to option 2ii from above). 6. Setting the private flag, would limit viewing only to the node author + users with the override permission from 4 above. 7. A bulk operation available to make nodes private en masse (credits for the idea to @Graham-72). 8. Contrib modules could extend this feature further. For example allow private nodes to be viewed by all users that have the same role(s) as the author (e.g allow some simplified version of group privacy) or OG integration (when ported).
Thoughts?
Recent comments
Hi ian, so, in your case all the other admin pages work fine, including the status page, only admin/reports/updates fails? But you can access admin/reports? Weird... I...
Update Report thows "Access denied You are not authorized to access this page."
The File (Field) Paths module should be able to move existing files. I've not tested it, but the module description says: Retroactive updates - rename and/or move...
Moving from /files into subdirectories
Yes indeed. We are exploring a few other more costly options, but as we are a low-resource start-up, we could save a lot of money by integrating Backdrop, CiviCRM and Ubercart for our membership...
UberPOS for Backdrop?