I know I can set up a role to allow user's to only edit their own pages, then go mark the appropriate pages to be authored by the appropriate user. But then I run into multiple users per page problems.
Is there any way that you can explicitly only allow a user to edit certain (perhaps multiple) pages, while accounting for overlap in the case that more than one user may be allowed to edit the same page?
Thank you
This would be fairly complex to do programmatically, but a fairly easy solution is to create a vocabulary to apply to the pages and then use the taxonomy access control module: http://drupal.org/project/taxonomy_access to set the permissions based on terms.
I answered a similar question a few months ago, with an overview of implementing a few different access scenarios:
How do I give a specific user editing rights to a specific node?
If you just need a module that set the access permissions of a user to a node of a specific content type, then use http://drupal.org/project/content_access; if the content type is a book, then you can also try http://drupal.org/project/book_access.
Remember that installing different modules for access control should be avoided, as they tend to conflict each with the other.
If you have patience, then you can create your own custom module, and implement hook_node_access_records() and hook_node_grants() as suggested by Jeremy.
try http://drupal.org/project/coherent_access
or http://drupal.org/project/content_access
this ish is crazy!#!!!#!#!
This is also possible to do programatically using hook_nod_access_records() and hook_node_grants().
With hook node_access_record create a relm with the UIDs of the users you wish to allow. and in hook grants create a grant with the users uid in the same relm. It is not that scary and very flexable.
Related
I have a question regarding WP Document Revisions. I have a client with a parent company and 14 sister companies underneath it. What they're looking to do is to have a document repository where all documents get stored, but the trick is that each sister company has their own financials that should stay visible only to top management in that sister company but needs to be visible to all Executives in the parent company.
I've looked into WP Document Revisions and it does pretty much what I want concerning the document part, what I can't figure out though is how to create user groups and setting permissions for those user groups. In other words:
Set up an Executive Team group with permissions to view and edit the documents
Set up an Top Management group per 14 sister companies each with their own permissions
And then when the different users log in they should only see the documents that's set with their individual permissions.
Can anyone please help me with this, I've searched high and low but can't seem to find an answer, even if there's a different plugin that would better enable me to do the above, I'd be grateful for the help.
Regards,
Anina
I am the lead developer of WP Document Revisions. The above should be relatively easy to do as you described. There are two ways to do it:
First, you could set up a WordPress multisite install, and have individual subsites for each subsidiary, with one parent site for the parent corporation. Executives would have a login on all sites, while managers would have a login for their individual subsite, and for the single parent site. The advantage to this approach would be flexibility (if you'd like to use the workspace for other tasks, branding, etc.) but this flexibility would come at the cost of complexity (setting up 14 subsites).
The alternative approach, and perhaps what I would recommend depending on your needs, would be to group documents into a custom taxonomy (perhaps "companies"), and then base capabilities on what company the document is assigned to. This would allow you to have one single site, and could assign capabilities based on the proven and tested WordPress Roles and Capabilities system.
The functionality described in the second option does not yet exist out of the box, but is a relatively minor undertaking and is actually already under development for a potential "Pro" version of the plugin.
I hope the above is helpful. If you would be interested in discussing customizing the plugin to your needs, either as described above, or otherwise, please feel free to contact me directly.
Update: Updated link to contact information as Stack Exchange was blocking e-mail links.
I believe I have a working version of an add-on plugin that should do exactly what you're looking for. The file is here ( https://github.com/benbalter/WP-Document-Revisions-Code-Cookbook/blob/master/taxonomy-permissions.php ) and would be installed like any other plugin.
A bit more information is listed on the last question of the FAQ ( https://github.com/benbalter/WP-Document-Revisions/wiki/Frequently-Asked-Questions ), but in short, out of the box it will make a "departments" taxonomy, and will create capabilities based on any departments added. You would then install and activate Members, if you have not already, and use the interface members provides to add roles and assign capabilities.
You can tell the plugin to create and use any different taxonomy (e.g., "company" instead of "departments"), as described within the file.
It may not be 100% stable as it hasn't been tested in the wild yet, but it should work. Please let me know if it works for you, or if you'd prefer to have me set it up, etc.
On my website, users have the possibility to upload different kinds of content (theme1, theme2, theme3,...). I also have different kind of user roles (author1, author2, author3,...). Every user role has only permissions to make, edit and delete one specific kind of content. I can do it the rough way and adding 8 different kinds of content types and 8 different user roles and make myself a complete mess while composing all the right roles.
I was wondering if there was a more easier way to do this in Drupal 7. The old D6-supported Upload Permissions per Content Type would have been ideal, but unfortunately, there was never a D7 version released.
Does anyone have an idea how to do this so I can just configure some kind of matrix to define all the user-roles and their permissions?
The "Content Type: Extras" module looks like it might help.
http://drupal.org/project/content_type_extras
I just want some opinions on what's the best way to go about meeting the following requirements.
I have
One main Drupal Installation
It is a typical "listings" site where users can list items
One user can have how many ever "listings" that are linked to his account
I want to be able to create sub-accounts, that use the same base site. However, for each subsite:
Only the users listings must appear on his site
It must have a completely different theme.
It must have its own menu items
The site must run off it's own domain OR subdomain
I need some answers:
Is this possible, or will each user need a completely new Drupal installation and just use a web service or something to get its listings from the main site?
What modules / components will make my life easier?
Any other suggestions to make this as simple as possible?
The problem description is not detailed enough to give a fully sound advice (and - additionally - it looks like you could probably get better advice on a drupal specific forum, as the question seems more related to installation and configuration than to programming), however - from what I understand - it looks to me that your solution could give in either of the two directions:
Tweaking a single installation to appear as different sites
Creating multiple sites that shares the same codebase and part of the data
The tweaking solution has the advantage that you have only one DB to mantain, but there is no actual real separation between the subsites. You could implement this by:
SUBSITES: mapping various subdomains on the same IP
CONTENT: using the native permission system to filter which list items to display (for example: each logged user can display only nodes created by himself, or set to be visible to its role, or having as associated taxonomy term its username...)
THEMES : if subsites will be used only by logged-in users, use the same mechanism that you would use for filtering content [each user can natively pick a different theme if you allow them to], if they must appear with a different look also to anonymous users, then use the URI to pick up the appropriate theme (if visitor X reaches the site via user1.example.com the site will have the blue theme, whilst if the URI is user2.example.com the theme will be pink).
The multiple sites solution has the advantage that you have a real separation between subsites (with even a different DB). But you would then have to either sync or transfer "on the fly" data between the main site and the subsites. If you go for this solution, you should probably take a look at the following links:
the services module, which allows to easy set up webservices
this page explaining how to connect drupal to different databases (surely faster than using webservices... reasonable solution if you for example have sites and subsites running on the same server)
I didn't want to stick this in a small comment but I am in agreement with mac on many of his points (upvote!).
The best way would be to create your subdomains and have them be symbolic links in the site folder to the default / main-domain folder.
Given what you have told us, you are much better off creating a module that creates its own node types (or even just CCK) and use a combination of the permission system (CCK offers this as well through content_permission), Views, etc. No need for separate sites, just need users to look at their own content.
The beauty of this approach is you can use Flag to allow user's to friend each other, use Views to allow them to see friend's lists, etc.
Theme's can be set on the account level, so no issues there.
"Have their own men" - does this mean have their own block on the sidebar or header than has customized links or a completely different menu SYSTEM? Will need clarification before I can answer that.
I'm trying to find a simple solution to a specific problem, which is a way to allow bloggers on my site to be able to control permissions on individual posts. So they could decide whether to have their post show up for all visitors, or for authenticated users only.
The closest module solution I've found so far is the Node Access module. It comes very close, but it doesn't quite do it for me, in the sense that it creates a new "grant" tab to the content type, then displays checkboxes with too many permissions options (allow a role to view, edit and delete), where I only want to display the view option, and I need it to be located right on the content edit/create page, not in a separate tab.
Unless I can find an alternative simple solution, I'll have to add a hack to the blog module or something. I can't think of any other way to do it.
Any ideas?
If you want to avoid coding and keep things simple, there are a couple solutions that come to mind.
TAC Lite allows you to associate a vocabulary with an access control schema. Each term can be associated with different view/edit access permissions for specific users or roles of users.
In this case, you would want a single term in the configured vocabulary. Set it up so that this term ("Restricted Access") when set, limits access to authenticated users only.
The advantage of TAC_lite is the flexibility of building out your access model as new requirements show up- such as having "premium subscribers" gaining access to even more restricted content.
Content Access allows you to set access control rules by content type, and override by node. I can't speak to the UI, as I've not used this mode.
In case Graysides (good) suggestion does not fit, you could do it yourself without 'hacking' the blog module by implementing hook_nodeapi() and hook_form_alter() in a custom module:
On the hooks 'load' operation, you could add a check for the nodes current access settings concerning anonymous vs. authenticated users. You'd add a property for that to the node object (be aware of potential naming clashes - you should prefix the names of custom properties in the node object with your modules name).
Via hook_form_alter(), you'd add a form element (e.g. radio buttons) to the node edit forms for your blog nodes that allows users to select the visibility, defaulting them to the new node property from above.
On insert and update operations of hook_nodeapi(), you'd then check the new property again and adjust the nodes access settings accordingly.
Note that this approach would possibly interfere with other node access module actions, so it might need some refinement. I do not recommend it - I just wanted to suggest an alternative to 'hacking core'.
I want to allow only one type of user to access a certain content type. It's simple and I've done it before, but today I can't figure it out.
Generally this requires an access control module like Node Access. Using a module like that, you can completely hide certain kinds of content from users who aren't allowed to view them.
If you mean "read" access, you'll indeed need some form of access control module, as Eaton suggested. OG, for instance, is one access control module although quite often people don't think of it that way due to its other features.
If you mean edit/delete access, OTOH, you have these by node type vs role at admin/user/permissions.
And, of course, if you only want to hide nodes from non-admins, you can just unpublish them: only admins will see them.