Plugin Contributor
nwjames
(@nwjames)
@rayz0rr,
I believe that the question you refer to is “How do permissions work”.
I believe that it describes accurately what the Members plugin will do.
It enables you to manipulate the plugin’s default allocation of permissions to roles. That is it.
[There is an error in that it refers to a document_permissions filter. This is incorrect, it is called document_caps.
You don’t say what problem you’re having and what you had hoped that Members would help you with.
Possibly it is that you expected that Published Documents not to be visible to everyone – even those who have not signed on. This is because, like Pages, Posts and other types, the plugin is set so that Published Documents only require read permission to access the document – a permission that everyone has.
There is a delivered permission read_documents that can be required to be able to read a document. In this way you can control who can read Published Document. To enable this, you need to set the filter document_read_uses_read to return false.
Hope this is of use,
Neil James
To clarify, I expected Members to protect by role for each document, as it does for pages and posts. I’m asking if that is the intended interaction between the two plugins.
If you’re under the impression that Members only manages capabilities on roles, then this screenshot below might shed some light. In the middle of the image is a “Content Permissions” section that appears when editing pages, posts, and documents. There you can select individual roles that are required to view the content. However, it doesn’t seem to work for documents.
Thanks for the document_read_uses_read suggestion. That did allow me to set read_document on each role but I was hoping for the more fine-grained control of restricting each document to selected roles as mentioned above.
Plugin Contributor
nwjames
(@nwjames)
@rayz0rr,
Thanks for your clarification.
I have taken a quick look at how Members protects content. It will not do as you hope. As far as I can see, this will be for two reasons.
Firstly, it does not protect the document post itself – only its content. In the current version of WPDR, the standard function the_content which is designed to return the post content field returns an empty string. (Actually a bug since it can now contain some user_content.)
However the fundamental issue is that the Members code to determine accessibility in inc/template.php uses this logic before it looks up whether the specific roles are present (for role-based access):
user_can( $user_id, $post_type->cap->edit_post, $post_id )
Now for this to work as expected I believe it should have this role-based checking within a map_meta_caphook since if one role has edit_documentsthen it will not look up the role access.
You may like to look at https://wordpress.org/support/topic/restricted-access-does-not-work-as-expected/ to see how Members can be extended.
Regards,
Neil James
Okay that’s what I thought. Thanks for the confirm and the information. I’ll check out that thread on Members.
@rayz0rr,
Don’t know how you’ve been getting on. However, I think that there is a need for a role-based set of permission based functionality. Whilst an earlier question on these lines would work for separating disfferent individual’s documents (by using Private documents), this would fail if there were groups of users with shared documents.
I have modified the taxonomy-based permissions functionality contained in the WPDR Cookbook to provide the missing code that you need. This will be found in wpdr-role-permissions held in my fork of the Cookbook on GitHub.
It is incomplete to deliver as a “proper” plugin in that it assumes that you have Members installed and active. It also requires you to ensure that the appropriate roles have been assigned to the documents. If the default process of no roles being applied to a document then it is accessible to all. But for the part that controls access to documents using any defined roles, it is, as far as I know, the complete processing needed.
If you would like to try it, then you should simply copy the wpdr-role-permissions directory from the Cookbook into your plugins directory and activate it. I would grateful if you do use it, then let me know how you get on.
Hope this is of use,
Neil James
