Getting Permissions via ZCatalog

Development
1

Hello,

often times there are strong use-cases for fine-granular permission levels via (placeful) workflows, local roles (w/ and w/o inheriting permissions) and add-ons like collective.workspace. These are typically needed to map client's real world workflows into the Plone world.

One problem arises, when looking into folder_contents view and its functionalities. There are often actions offered, the user cannot do. Like for example the user has no permission to edit the object, but the edit button is still offered. The user has no permission for getting the folder's listing, but they yet can click it which is yielding into an error message. This applies both to Classic and Volto, since both rely on the information given by the catalog (side remark: I know plone.restapi offers the "fullobjects" parameter for the @search endpoint if needed).

Now I was wondering, if there are efforts make the permissions directly accessible in the ZCatalog? We have already something like this with the allowedRolesAndUsers index that contains all the eligible principals for the View permission. In one issue on the editLink (in Classic UI) I proposed to introduce another index just for the Modify portal content permission. But thinking about it, we should need more indexes too like one for Listing folder contents that tells, if the user can browse into a folderish object.

The action points would be to add the needed indexes, that also gets updated whenever object.reindexObjectSecurity() is being called and using the brain's index data for new attributes like "can_view", "can_edit", "can_browse", etc. Do you think, that this way is viable when doing this for the most-needed permissions? This also could be made configurable, when the integrator wishes to have more permissions indexed at hand for the brains.

Downside: This bloats obviously the reindexing process and requires a full reindex upon introduction. I haven't looked into experimental.securityindexing, but it might be useful in that regard. Alternatively, we could also retrieve the objects for just the brains, we wish to interact with (like just on the current page in folder_contents) and get the permissions as we wish.

What do you think?

2

Catalog is ok when listing a lot of things, without waking up the objects. Folder contents, IMHO, just need to access objects by an editor request, so there should be no need to use the catalog. But maybe there are optimizations we can put in place. For example, actions and security just need to access some kind of metadata of the object. Security checks, for example, access some attribute of wrapped objects (using a proxy object) that use the security info as source. So you're not accessing the object attributes but just one that contains security info. Consider also that you've acquisition so security can depend on the context.

If you're going to implement this, a good idea could be to use a metadata with all the security informations (maybe in json format) as the image_scales metadata do for scales. Being used in folder_contents, the filtering logic can stay in the view.

So: allowedRolesAndUsers carry all the objects that I can view. The security_info metadata carry the security of the object. But there's a security problem because security info should be accessible only by managers to it should work as allowedRolesAndUsers index works. I don't know if it is possible with metadata.