Let's say I have a data template that has 3 field sections: Basic Info, Navigation Info and Content Info. I would like to restrict Field Write access to the fields in these sections by role. I know that it is fairly simple to create a role for each of these and deny Field Write for the other sections. For example, I could create a role called Basic Info Editor Role and deny Field Write for all of the fields in the Navigation Info and Content Info sections. However I need to have the ability for a given user to be a member of more than one role sometimes. So I may have a user called jSmith that is a member of both the Basic Info Editor Role and also the Navigation Info Editor Role. I want jSmith to be able to edit both of those sections of content.
I can't figure out how to do this. It seems that by default all users have Field Write access to all templates. I think somehow I need to remove inheritance so that they don't all have the Field Write granted or something. Any ideas?
From what I remember you cannot assign Field Read and Field Write access rights on the section level - you can only do this on the field items directly.
Anyway, I think your approach is correct:
select chosen field which should be restricted
break the inheritance of this field for your base role (e.g. Standard Editor)
and then create Basic Info Editor Role which will be a member of the Standard Editor role
add Field Write option for the selected field for Basic Info Editor Role role.
All other Standard Editors won't be able to change this field, only Basic Info Editors will be allowed to change it.
Related
So what I am basically trying to do, is to have the ability to add custom field(e.g. Secondary URL) to Content item Meta Tab, so that the user can set it manually on demand. Reading docs did not bring any result
On the attached screenshot, you can see Path, Navigation title fields, so I need to add additional one
to be able to modify the content type - in your case adding a new field - it is required to have the proper permissions via assigned roles. More specifically, you need to have permission to modify content.
Content modeling could be done via UI - see Content modeling tutorial, in your case it is Adding an element into a content group "Metadata". You also can use REST Management API for that.
I've been a Notes developer for years but never used an Access Control Section on a Form.
I want to give (web) users (with the right [role]) access to edit only one field on a document. I'm assuming an Access Control Sections is the way to go.
A couple of things aren't obvious:
As well as adding the [role] name to the Access section's formula does it also have to exist in an Authors field on the document?
If #1 is true, then do all other fields have to also be in an Access Control Section where that role can not edit them?
Jake
The access control section controls access to what ever is in the section. It does not need an authors field.. Only the content or fields that you want to control access to are included. Authors fields define who can edit a document. Regardless of what level of access a user has, if there is an authors field and the role is not listed, that user will not be able to edit the document.
You can use an authors field to limit the editors to certain documents, from there you can further restrict access to fields to edit by sections. If you do have an authors field in conjunction with a section, the role needs to be in the authors field as well as the section access formula in order to be able to edit
In Lotus Notes Access is ALWAYS calculated top -> down.
If you don't have Author- Access to the document itself (defined by an Author- field or because you are Editor or higher) then a Section- Author- Role will not help you.
The answer is: Yes, you need an editor- field containing the role.
In consequence the answer to your second question is also: YES, you need to protect the other fields with a section (without the role) as well, if you really want to restrict access to that single section.
What I need
I have a custom Entity with that with multiple fields. Admin Role has "god" access. All other roles except for one have read only. The one non admin role with update access, should only be able to update a single field.
What I believe to be true
I believe I have three main options to implement this requirement:
Enable Update Access to the role for that entity then write Javascript to disable all fields on the form for that role, except for the one that I want that role to be able to edit
Enable Update Access to the role for that entity then create a new form that disables all fields on the form for that role, except for the one that I want that role to be able to edit.
Enable Update Access to the role for that entity then turn on field security for each field, disabling access using the field security, for each field except for the one I want them to edit.
What's the Best Practice?
What options should I choose?
If I go with options 1 or 2, will the user be able to edit the field on the bulk edit form?
From a user perspective, I think it's confusing when a form opens up with things enabled, then they get locked down. Plus someone could possibly get data in there before the fields get locked. I'd say you'd have to combine this with a plugin to prevent changing fields you don't want changed.
I like this option better, although again, the field can be unlocked if someone knows what they're doing, so a plugin to double check would be nice.
This would avoid having to double check in a plugin, but you also have to rely on the admin correctly setting up security for new fields going forward. If that's not a concern, this might be best.
Bulk edit is a global privilege, so they'd have bulk edit for all entities. Also, the bulk edit form does not load scripts, so that knocks out option 1. I'd say if it's just this one field, I might leave the privilege locked down and provide my own Bulk edit button on the grid that would show a custom page that just has that one field on it, then handle the updates though script.
2 is most likely best, or as an alternative put the fields in the header or footer rather than as read-only fields on the form.
This also means the fields won't be available to bulk edit, but other methods such as data import or workflows would let users get round this if they know how and have rights to do such things.
3 Field Security is the most robust and works for all scenarios
Possible option 4: create another entity to contain those fields and apply different security to that entity. If created as a child, show the record in a grid on the form with the values included in the view. If it is a parent then you could use methods such as showing the values via an HTML webresource page included on the form.
I would like to show / hide certain fields in my Drupal view accordingly to the user role.
Provided I can only have this view to work with, how can I achieve this programmatically or there's some settings that I am not aware of in Drupal.
P/S: I am aware of the access settings under basic settings in View but that would restrict access to the whole view, not field level.
You can create two identical Displays (within the same view) and override the field settings and access settings in each of them. For example, in the first display show the fields you only want a certain role to see, and set the access control setting to that role. In the second display, remove the unwanted fields and set the access control to the corresponding role.
Start by creating the most restrictive display first and then the least restrictive one.
I liked this answer, but in my case the field is dependent on the argument and I would need to create a new display for each argument (which isn't practical).
I installed the Views Custom Field module and used this code for the field:
<?php
if(user_access("some permission string here"))
{
print "Your field value here";
}
?>
Click advanced, theeming, find the field and make a _.tpl.php file for it, then in the file you will see:
print $output;
Change this to:
if (user_access('administer nodes')) {
print $output;
}
Or whatever the permission is you are checking against.
I think you have to try module Field Permissions
If your the fields you want to exclude are 1) created with CCK and 2) should be hidden from users of that role everywhere on the site (not just in this particular view) then you can just set the permissions on the fields so that users are particular roles can't view them. If the current user doesn't have permissions to view a field that is part of a View, the field won't be shown to the user.
I'm probably going about this the wrong way but...
I’ve added a field to the User Profile called profile_real_name which is required by the user. Is there a way to access the details in CCK?
For example in CCK when creating a new field I can access the user’s username with the ‘User reference’ Field type and setting the ‘Widget type’ to ‘Autocomplete text field’. Can I do the same with my real name field?
Many thanks
The problem is that Users are not a part of the node system and therefore fields cannot be mapped to Users using only Core code.
CCK doesn't have a way to manipulate and add fields to profile.
There is one solution to this: nodeprofile (Drupal 5). This module creates a node type for users, so each user effectively has one node that is associated with it. You can then add fields to this new content type and manipulate them how you wish.
There is also a module, content_profile, for Drupal 6 which does the same.