I am able to assign the roles to four custom group(Admin,Record manager,User,Info) as well as created the file plan category in particular agency(for instance, agency1).Then created the Agency admin(for instance,agency1 admin) for the particular agency(for instance, agency1).Based on the group needs to assign the contributor permission for admin as well as consumer permission for Record manager,user and info group.But If I create the another agency admin(for instance,agency2 admin).If I login to agency2 admin and assigned contributor permission,while viewing the file plan category got two categories agency1 and agency2.
Need to restrict the access to show only agency1 file plan category while agency1 admin login under the Record management site.Please help to achieve in alfresco webscript.
Resolved by creating the node and passing the node details to record management post webservice(api/node/"+Q.storeType+"/"+Q.storeId+"/"+Q.Id+"/rmpermissions",) as well as passing the permissions as data.
Related
I have a Drupal 7 site with single SSO via the LDAP module, which allows us to run the site as n Intranet and users that hit the site with IE will get automatically authenticated using their active directory credentials.
I have a personnel directory content type that holds a list of all of our employees and some of their stats (photo, email, phone number, etc.).
The problem I want to allow the logged in user to be able to edit the node in the personnel directory page that represents them, but because there is no relation between the logged in user and the nodes under the personnel directory content type I am not sure how to go about allowing users to edit their own entries?
The personnel directory page is automatically populated/updated via feeds (it looks at our AD, and pulls down users and updates them if it detects updates in AD meta data).
Somehow I need to tie the logged in user to the specific node, any idea how I could automate this as there are over 300+ nodes/users.
Ultimately, I'd like to have a "edit personnel bio" link that they can link, that will link based on their [current logged in user ID] it will allow them to edit the correct node in the [personnel directory] content type.
I hope this was clear enough to point me to some direction.
Thank you.
basically you want to create a user "role". Then in your permissions page (the one with 1000 checkboxes) you can add edit access to your "personnel bio" content type (or fields) for just that user role.
Then in your template you provide the user a link to the same page with /edit in the url.
Make sure the user has permissions to edit the node of that type. Upon creation of the node via feeds, create a rule (use the Rules module https://drupal.org/project/RULES) to change the creator of the node to that user's uid.
Add another field in the user's account to match their AD username to tie them together. To do this, create a module as seen at https://drupal.stackexchange.com/questions/8253/how-to-add-extra-fields-to-user-profile
I need newly created users to be assigned to a particular role as default.
as default, a new user automatically assigned as "authenticated user" I also need as "content admin (custom created role)"
any idea how to do that?
appreciate helps!!
Why I need that?
I create a content admin role for client, I dont give administrator access. and they need the ability to create new users as content admin. as default I need to give access to "administer permission", but by this way they can create administrator user as well :/ and can messed up with the site. So, if I can assign content-admin role as default to new created users, i wont give administer permissions access to client.
Take a look at the module Auto Assign Role. It allows you to automatically assign roles to new users. You can also set different role presets depending if a user registered himself or an admin created the account. Currently it is only in dev for Drupal 7, but from the issue queue it seems to be in working condition.
From the project page:
The Auto Assign Role serves three primary purposes. The first is to
provide an automatic assignment of roles when a new account is
created. The second is to allow the end user the option of choosing
their own role or roles when they create their account. The third is
to provide paths that will trigger a specific role when an account is
created. The administrator has full control over these functions and
can have them working together or independently of each other. Auto
Assign Role is integrated with the Content Profile module so that you
can have content types serving as registration pages. You can even
replace the default user/register page with a customized version of
your own design.
In my drupal installation I have created two type of nodes.
Free access (non - registered users)
Only member access (registered users)
I used a content access module to set permissions.
Now I have created a list of these nodes using views, the problem is that when free user sees that list, they are not shown the list of nodes accessible only to registered users.
I want to be able to show all the list of nodes, regardless of who is seeing them, but when a non-registered clicks on node not be accessed by him, they will be taken to login page.
Please see click here for the solution.
The Premium module allows to show teasers to all users and the full body only to privileged users.
I am using the calendar module with its iCal support for Drupal 6. I have made my event type which appears on the iCal feed. However, I want to make the event content type private, so only authenticated users can read it. By doing this they will not show on the iCal feed. Is there any way that I could get the iCal feed to still show these events?
I agree with calebthorne that normally a feed is public; I can understand the need of making a feed public for a group of users, and not to the anonymous users.
If the feed is created by a view, then you can change the view, and restrict its access to the users you want.
As you can see in the screenshot, you can restrict the access to the users with a particular permission, or to the users with a specific role (authenticated user is one of them).
Hmmm... I would give the Node Access module a look. I use this module to restrict access to content based on content type. I have never tested whether this works in conjunction with the Calendar module but it is worth a shot.
Some more details about the Node Access module (from its project page):
Nodeaccess is a Drupal access control module which provides view, edit and delete access to nodes. Users with the 'grant node permissions' permission will have a grant tab on node pages which allows them to grant access to that node by user or role. Administrators can set default access controls per content type, and also define which roles are available to grant permissions to on the node grants tab.
The upshot is, this module allows you to do things like 'node 123 can be viewed by authenticated users and edited by admin users and joeuser'. As an added bonus, update and delete permissions are separated, so you can make sure users with edit permissions cannot accidentally delete pages.
How do I give a specific user editing rights to a specific node?
I have a user role named "Student". Multiple users have that role, only a few of them can edit a node. How can I realise this?
I'll try and cover a few use cases, with how I would solve them:
If all members of a category of users can edit any node of a certain type
Create a new role for that subset of users ('Super Students', as Emyr suggested) and grant them 'Edit content of type' permissions through Drupal's core permission system (no node access module required)
If all members of a category of users can edit specific nodes
Create a new role for that subset of users and grant them edit permissions on the specific nodes (a node access modules is required, such as Node Access or Content Access). This will also require that someone has the permissions (and time) to grant access to the role whenever a new node is created.
Some users can edit some nodes; there is no 'elite' group of users who can edit all nodes, and not all members can edit the same nodes
This will require a node access module, such as Node Access or Content Access with ACL. There will also need to be administrative users who have the permission to grant other users access to edit the nodes.
Allow users to grant others access to edit a node they have created.
I implemented this recently with a user reference CCK field and Node Access User Reference. You can grant users permission to edit their own nodes through the core permissions system and they can then add other users to the user reference field. In my case creators are not given that permission and I set up the default value of the field to the creator's user id, which allows a user to remove themselves from being able to edit the node.
These all assume there is no categorization for your content. You may be able to utilize node access modules based on Taxonomy or Organic Groups if your content and users are organized sufficiently.
For sort of abnormal permissions stuff like this, I've always found that a small custom module is the way to go. General node access modules have to be general enough to be useful for a lot of different cases, which generally makes them sort of messy and confusing.
For this specific one, you could create a module that implements hook_nodeapi and on $op==prepare, check the user's ID against your user reference and do a drupal_goto the access denied page if they don't match up.
You can do this with Flexi Access. Giving a specific user the "update" privilege on a node will allow him to edit the node.
For more options, see the page: Overview of Node Access modules # Drupal.org.
Have you tried either Node Access or Content Access?
If only a subset should be able to edit nodes, you need an additional "super student" role.
The Node Access module may help you set appropriate permissions on the nodes. Here is an excerpt from its project page:
... provides roles and user specific security permissions for menus, menu items, nodes, and security integration into the administration and help systems. We would like to provide this suite of modules back to the community to share the usefulness of the suite and involve the community to provide additional support, testing, and moderation.
Special care was taken to ensure the usability of permission management was consistent across all sections of the system (nodes, menus, menu items). Also each security module uses a cascading security scheme to allow global security and the option to override or define exceptions to the security model for individual items.