Safety and security of personal details

[Graham-72]

Is it safe to keep membership records within Backdrop? If so, how?

If I create a content type 'member details' and create one node for each member of an organization, how can I restrict permission to view this type of content?

I would like to have, in core, an extra permission in the section 'Node' for each type of content 'Node type : view any content' , and then I could control who is granted visibility of membership records.

Surely this is something that is needed by anyone keeping club membership records on-line?

[quicksketch]

I would like to have, in core, an extra permission in the section 'Node' for each type of content 'Node type : view any content' , and then I could control who is granted visibility of membership records.

You've probably noticed that there are per-type controls on creating/editing/deleting content, but no "view" permissions at all other than "access content". This is because there are so many ways of controlling access to content: by type, by taxonomy terms, by "groups" (as provided by OG) and many other ways. Core does provide a central mechanism for controlling access, through a combination of hook_node_access() and hook_node_grants(). The first is for viewing an individual node, the second when doing queries of multiple nodes that need to be shown in a list.

I don't think we have any node access modules ported to Backdrop as of yet, but there are number of solutions out there:

https://www.drupal.org/project/content_access
https://www.drupal.org/project/taxonomy_access
https://www.drupal.org/project/og

Personally, I find that if you want any sort of access control beyond the out of box "unpublished" flag, ultimately you end up needing Organic Groups, which is the most flexible/complicated solution out there. But the different levels of control needed is exactly why core itself doesn't provide built-in access control, because there are so many ways of managing it.

[Graham-72]

@quicksketch Thanks for your comments. I think this an important function to have available in Backdrop. Previously with Drupal sites I have reverted to plain PHP/MySQL to handle lists of members or for example purchasers of tickets, and it could be nice to do it within Backdrop without the whole thing getting very complicated. Wishful thinking perhaps.

I am making a start by porting Simple Access in the hopes that this may be the easiest contributed module to get working. It will help me understand some of the issues involved. Perhaps one day I will be able to graduate to Organic Groups but if you describe it as complicated it must be a tough nut to crack!

I previously commented about this matter, and you replied, in backdrop-ops/contrib#105.

[biolithic]

Graham, I started a port of https://github.com/biolithic/content_access this morning. I got through the porting process but I have to get back to work.

The module gives an error on a node page "unsupported operand type" probably because it doesn't initialize the config variable yet (variable should be an array to add to array). Here is the offending snippet in the module file:

function content_access_get_settings($setting, $type_name) {
$settings = array();
// $settings = config_get('content_access.settings', 'content_access_' . $type_name);
$settings += content_access_get_setting_defaults($type_name);
if ($setting == 'all') {
return $settings;
}
return isset($settings[$setting]) ? $settings[$setting] : NULL;
}

I hope to get back to this tonight and finish it, or you can finish it if you feel you need it for your project. I don't think I'm up for porting Organic Groups without the financial incentive. ;) Thanks for bringing this up.

[Graham-72]

Andy, Thanks for letting us know. That's really good news. My project can wait a week or so because of other delays so I will leave you to carry on with Content Access. I have just started preliminary tests of Simple Access, so we may well have two node access modules very soon 👍

As a Retired Person I am in the fortunate position of not having to worry about financial incentive and am more driven by curiosity and intellectual challenge 😄 But I do have other commitments to fulfil at the moment.

[klonos]

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). Unfortunately, simplytest.me seems to not like any of the projects I try to test today, so I currently cannot give them a more thorough UX review.

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?

[Graham-72]

My port of Simple Access is now at https://github.com/backdrop-contrib/simple_access.
It needs a little bit more work to deal with test result exceptions, and also to check its functionality and usefulness in a real situation.

[Graham-72]

Now that I have Simple Access working on a test site I am realising its shortcomings with respect to my needs, in particular that it will not change access rights for a batch of existing nodes, only for nodes one at a time, or for new nodes. @klonos I like your list above.

I am now going to look at Content Access and see how that compares.

[klonos]

... in particular that it will not change access rights for a batch of existing nodes, only for nodes one at a time, or for new nodes. @klonos I like your list above.

Oooh-oooh bulk operations yeah-baby! 👍 I added that to my list above. Thanx for the idea @Graham-72 😉 ...gave you proper credits for it too.

[Graham-72]

I have now spent some time looking at the Content Access module thanks to @biolithic 's initial port and have become stuck because of the changes in the way Backdrop provides user roles and associated functions, as described in the change record 'Converted User roles to CMI' at https://api.backdropcms.org/node/26870. These changes would seem to have major repercussions on the internal workings of Content Access which, in any case, I find difficult to understand.

So I am now going back to considering the Simple Access module and the possibility of adding a bulk operation to change access rights for a batch of existing nodes - as now added by @klonos to his list above. [Thanks @klonos]

[Graham-72]

I have now added a bulk operation to Simple Access in order that a predetermined 'profile' can be applied to all nodes of a selected type, and this meets my need to keep a club's membership records hidden from view except to those with a specific named role.

Simple Access uses the 'Grant' system of node access control with 3 realms appearing in Backdrop's node_access table: simple_access_author, simple_access and simple_access_profile.

I propose to close this issue after allowing some time for any more contributions. Thanks for those made so far.

[klonos]

No objection to close this specific issue here. I've moved the comment with my suggestion to its own separate issue.