Implementing such restrictions is pretty forward by using the Rules module for this. As a sample, consider this scenario:
- don't allow updates to the title of a node of type "Article".
- but do allow users with role "administrators" anyhow (just in case ...).
- If an attempt to update a title of an article is discovered by a user who does not have the administrator role, then just ignore the attempted update to the title (but do save all other updates to the node).
To implement this scenario, just use this rule for it:
{ "rules_verify_updates_to_node_properties" : {
"LABEL" : "Verify updates to node properties",
"PLUGIN" : "reaction rule",
"ACTIVE" : false,
"OWNER" : "rules",
"REQUIRES" : [ "rules" ],
"ON" : { "node_presave--article" : { "bundle" : "article" } },
"IF" : [
{ "NOT user_has_role" : {
"account" : [ "site:current-user" ],
"roles" : { "value" : { "3" : "3" } }
}
},
{ "NOT data_is" : { "data" : [ "node-unchanged:title" ], "value" : "[node:title]" } }
],
"DO" : [
{ "drupal_message" : {
"message" : "Tampering rejected ... An attempt to update the title of node with ID \u0022[node:nid]\u0022 was discovered (from \u0022[node-unchanged:title]\u0022 to \u0022[node:title]\u0022), by user \u0022[site:current-user]\u0022, who does not have the authorization to do so. The attempted update of the title has not been saved (all other updates were applied).",
"type" : "error"
}
},
{ "data_set" : { "data" : [ "node:title" ], "value" : "[node-unchanged:title]" } }
]
}
}
If somebody who is not an administrator tries the above scenario (with the above rule enabled), that user will get a Drupal error message similar like this one:
Tampering rejected ... An attempt to update the title of node with ID
"X
" was discovered (from "Original title of this article" to "Attempted update of title of this article"), by user
"Some.Userid
", who does not have the authorization to do
so. The attempted update of the title has not been saved (all other
updates were applied).
Obviously, X
and Some.Userid
will be replaced by the actual node ID and username.
Works like a charm ... Similar approach for any other node property ... And straight forward to apply for any other content type (instead of "Article"), or just all content types.