On a Drupal 6 site, I have a 'moderator' role, who worka with an 'article' content type.
I want the moderators to be able to see the list of published/unpublished articles, and have the option to edit the articles (and change their 'published' status).
I do not want, however, for moderators to be able to edit (or see the list of) any other type of content.
If I give moderators the permission to 'administer nodes' I cannot stop them from editing other content types. If I remove that permission, they cannot access the content list (which is crucial for them).
Any ideas?
You might want to check out the Views Bulk Operations Module (http://drupal.org/project/views_bulk_operations). You should be able to use this module to build a custom view that displays only the content types you want the 'moderator' role to edit.
If you all your content types are created with CCK you can unset each content type's permissions for moderators. If not, I'd recommend you do create them in CCK :)
you definitely don't want to give them "administer nodes" permissions since it's a huge can of worms. if the nodes are unpublished you'll need to use the views module to get listings that will let them see the nodes.
that said unless the node type is one created by a specific contrib module you should be able to set the permissions on a per-role basis. if not you might look at using a node access module to control permissions.
Related
I wonder if I could Directus as a CMS back-end for my huge project.
This requires me to add pre-defined collections that cannot be deleted or edited. Also, I need to prevent users add new collections.
I couldn't find anything in the docs for now; since Directus is not invented the way I want; It is expected to be extendable as much as possible. So I think I need to edit -almost- the whole system.
I hope I can find someone to lead me. Thanks.
The Directus is having a roles & permissions module where you can define who can create/edit/update/read the collections as well as items inside it.
There are 2 default roles:
Admin
Public
Only admins can create & maintain collections. You can add additional roles and define permissions for it. More on roles: https://docs.directus.io/guides/roles.html
You can also ask Directus to skip specific database tables and don't manage those. If you need to read data from skipped tables, you can write custom endpoints.
You can check the Directus setup live at: https://www.directus.app
P.S. I've worked on Directus interfaces and my team is working on API. Let me know if you need more help.
Out-of-the-box, an Alfresco user can read a document based on:
The document's permissions
The user's role
The user's groups
Whether the user owns the document or not
Maybe some other factors I forgot?
Now, I want to add a new factor: Whether the document is currently part of a workflow.
Alfresco's permissionDefinitions.xml allows me to define permissions based on authorities such as ROLE_LOCK_OWNER etc, but it does not seem to be the right place to add permission conditions.
I guess I will have to write some Java source code, but I am not sure what classes are responsible for this, and whether there is an Alfresco way to customize them?
So, I assume you want to somehow have nodes that are attached to a workflow have different access rights? You need to think about the behavior you want in all of the UIs and protocols you are exposing (e.g. share, WebDAV, CIFS, FTP, etc.).
If you want to set a permission on a node, you can do that via JavaScript as well as Java (See http://docs.alfresco.com/5.2/references/API-JS-setPermission.html and http://docs.alfresco.com/5.2/references/dev-services-permission.html). As was mentioned in one of the comments, you can also get the number of active workflows on a node by referencing the activeWorkflows property in JavaScript (http://docs.alfresco.com/5.2/references/API-JS-ScriptNode.html) or in Java
Depending on the specifics, I might implement this in different ways, but if all you want to do is have the permission change, you could just update it at the beginning and end of your workflow with a simple javascript call. The only thing bad about that is that it doesn't take into consideration the workflow getting canceled. You could also create a policy/behavior on an aspect you attach or even have a rule or job run that updates content based on the activeWorkflows values.
I am reviewing Piranha CMS and really like the framework.
I am wondering how I can associate permissions to Regions and Media elements.
I was thinking that this may be easily accomplished through a custom extension but would like to know if this is the recommended approach.
What I'd like to do is to restrict rendering of a region if the current user's does not have access to it. I was thinking I may be able to add a group GUID as the permission property of the region extension. If the permission property is an empty GUID then it will render the region otherwise the current user must be a member of the group that the region is associated to.
I would like to do the same for Media elements.
Cheers
John
You could solve both the region & media question with a custom extension, however I'm not really sure I follow why you would need it for the page region.
As regions are merely considered a "part of a page" there's no way to customize security for a single regions, it is set on the complete page.
As media is usually rendered in some context, as a page, there's currently no security setting for uploaded media. This however is a feature that could be added into the core framework as it could make sense for some use-cases.
Best regards
Håkan
I have below queries in DFC and WDK:-
1) TBO is type base objects and is for specific object type in documentum. SBO is for global use. Can we make a SBO code to act like a TBO, if yes then how? How can I make my SBO specific for a particular object type.
2) How can I call a behavior class from an action.xml in WDK? If I dont want to use the component in my WDK customization. Any examples to support these queries will be appreciable.
3) Why is scope required in WDK? What is its role and can scope override over privileges in terms of hierarchy. If a user is provided a scope for a component in WDK but he/she doesnt have sufficient privileges to access it in documentum. Can the user still access the particular component?
4) Can folder security values override basic object level permissions? Which will come first folder security or basic level permissions or privileges?
Thanks!!
Deb
This is not kind of question for SO, at least in most parts. However:
1.) TBO and SBO are just architectural approaches for specific requirements. If you have specific code that you want to run for objects of specific type and not only for objects of subtypes, than you need to change object model to apply logic for all objects in type hierarchy. This isn't a problem with Documentum object/type model.
For example: You have custom_document as subtype of dm_document and custom_child1_document and custom_child2_document, both subtypes of custom_document. You have TBO set to custom_child2_document.
You don't want to apply SBO to have custom logic available everything under dm_document.
Just add TBO to type custom_documentm and you'll have your logic for all types under dm_document.
2.) You cannot call behavior class without invoking component. If you have specific code you want run from other places, isolate it at some other place and run it at will.
3.) You don't need to specify scope for your WDK configuration. However, once you learn WDK in details you will find it useful.
4.) Folder is object. You need to know that when you access objects via folders you need access permission for both folder and document linked to that folder (Read level is enough). You need only permissions on object id you access that object from DQL for instance. Basic and extended permissions are meant to be used in specific cases, you don't need extended permissions to read object content if you have Read basic permission on your object. However you need Relate basic permission + Run procedure extended permsission on target Workflow to start workflow with that specific object as attachment/package. Different rules go when you want to add object inside specific folder. But this is long story.
Regarding folder security - check this article.
A quick api uri design question. We have resources that belong to our clients. These resources can be edited / viewed / deleted by the client who entered them into our system. The resources can be searched by all clients but access is only granted if certain criteria is met (client has level 3 access etc).
Choice 1: include the client who owns the resource in the uri.
client/:clientname/widgets
client/:clientname/widgets/:id
Choice 2: ditch the whole "client/:clientname" since this part of the uri has to be verified and checked against the credentials of the user accessing the information.
/widgets
/widgets:id
We have other resources other than widgets that also belong to clients.
Which way is the more preferred way and why? Cheers.
The only advantage that Choice 1 gives it that it allows you to effectively namespace widgets/whatever by the user that uploaded them. Similar to Github, how different users can have projects with the same name. If Github were to exclude the username, no two users could have a project with the same name. If the widgets are all unique, I would go with option two and you will have a 1:1 mapping from a widget the the user that created it, thus supplying it is just extra work for whoever is calling it.
If you can have the same widget name for different users, use an approach which includes the username. You may not need to actually use the 'client' word in your url though; using a path like '/:clientname/widget/:widgetid' instead.
Note that this is kind of an opinion based question, so you may get different answers. You'll have to weigh the information provided and in the end make your own decision.