I have 2 different roles with exactly the same permissions and text formats when I switch a user between these two roles with the first one I can edit one specific node but not with the second, is there something I'm missing? I basically want to make these two roles to work exactly the same and after that I will add/remove some permissions.
I even tried using the direct edit URL "node/XXXXXX/edit" with no success on my 2nd role, as soon as i swap to the 1st role I can access the edit page.
On the content type I looked on the User Permissions and both of them are checked on the "Roles that can EDIT any content of this type"
As suggested on one of the answers I re created the role and cleared the cache but with no success.
Do both roles have the right permissions to work with the text format?
/admin/config/content/formats
or go to Configuration > Content authoring > Text formats
Try to delete the second role;
Create again and
Clean cache.
That happened to me time ago.
Hope that helps.
Related
We have a Mediawiki installation at our company. The original Wiki admin has left. I don't know who has admin rights or the admin username and password.
I only have user rights on the wiki.
Goal: To change h2 headers, and the .mw-headline class, to have an underline when the page is printed.
I've searched Google and MediaWiki help and found I have to make a link to and edit User:Chuck/Print.css.
On one of my Mediawiki pages I've tried to make a link to [[User:Chuck/Print.css]], edited and saved it, but the changes don't take effect.
I don't know if the variable $wgAllowUserCss = true; is set because I only have Wiki 'user' rights.
What can I do to get the Print.css to work?
Thank you for your help.
There are two meanings of "admin": the one who is given a role administrator in the MediaWiki website, and the one who controls database and the server. I don't know which one were you referring to (it is also possible that both are the same person).
Assuming that $wgAllowUserCss = false;
Then, if you managed to find someone who can access the server, you could ask that person to edit LocalSettings.php so that $wgAllowUserCss = true;, and now your User:Chuck/Print.css will work. Note that it is absolutely impossible to make your User:Chuck/Print.css work while $wgAllowUserCss = false;.
Otherwise, if you managed to find someone who is given a role administrator, and it is okay to make your change to Print.css systemwide, you can ask the administrator to edit MediaWiki:Print.css. This guarantees to work even when $wgAllowUserCss = false;.
Usually there could be more than one user who are given the role administrator. You could see the list of administrators by going to the page Special:ListUsers. For example, here's all administrators in English Wikipedia: https://en.wikipedia.org/w/index.php?title=Special%3AListUsers&username=&group=sysop&limit=50
Please also note that if you can access the database, you can give a role administrator to a user in the website via the database too.
Assuming that $wgAllowUserCss = true;
It is also possible that in fact $wgAllowUserCss = true;, but the change doesn't take effect. Read https://en.wikipedia.org/wiki/Wikipedia:Bypass_your_cache for the solution.
Note: without an admin (in both meanings), pages cannot be deleted, and a lot of system changes cannot be done. Your company wouldn't be able to stay in this state forever. Perhaps you should ask your company to install a new wiki.
My website is used to administer customer accounts. If I access CustomerA's account through the website then open a new tab and access CustomerB's account the session holding the customer ID updates to think I'm now working on CustomerB. Then if I click back to CustomerA's tab and start editing that page I am in fact editing the database record for CustomerB. This has happened and caused all sorts of problems so I need to find a fool proof way of stopping it. I don't want to put the customer ID in the URL as this will make it open to abuse.
Session is not a place to hold information like this exactly because of problems you're describing. You need to pass customer ID along with the page itself (either in hidden field or in url), so when you post back the form, it exactly knows what are you trying to do. Session won't protect you nor add any extra security. You need to determine if the user has correct permissions either way, so you should focus on this aspect.
I am using SDL Tridion 2011 and need to take the permissions off from the user to localize a structure group so that he does not make any changes in the name of the structure group by localizing it. However, even after removing the rights and permissions and making the structure group ‘read only’, the user is still able to localize the structure group by right clicking on it and going to properties. Please help if there's any resolution for it.
Also, is there any way we can restrict the user from unpublising or updating a page?
Permissions on a structure group control what you can do to the things it contains. Remove the localize permission in the parent structure group instead.
To prevent unpublishing you can do any of the following:
Remove the Read permission.
Go to the Security tab in the properties of the relevant publication, and remove the right to Publish to Content Distributor
Go to the Security tab of the relevant Target Type, and remove the Use Target Type permission
To prevent them updating a page, remove the Write permission, although be aware that editing the page allows them to modify the page composition, and that controlling this doesn't prevent changes to the content if the person has permission to modify the relevant components.
If none of these is sufficient, then you will need to implement a custom solution with either the events system, or workflow.
Inspect the properties for your Structure Group and go to the Security tab. Check which users/groups have the localize right and then see if your user is a member of any of those groups. Groups can be members of other groups, so you may need to check recursively to find where this ability is being allowed from.
Also make sure that the user is not an Administrator.
To prevent a user from unpublishing a page then you need to make sure they do not have "Publish to Content Distributor" rights at the Publication level. If they need to be able to publish pages, but not unpublish, you will need to take care of that by writing an Event System.
To prevent them from updating a page, you need to consider the Write permissions on the containing Structure Group.
I have come across this problem in the past but never solved it.
I am on the verge of finishing a Drupal site for a client. I created two content types and gave him the permissions necessary to edit any occurrence of these node types.
The strange problem is the client can edit any node of type product_type except for one particular node of the same type.
So in other words, all nodes of type product_type are editable except node/3.
Do you have a node access module installed, like Content Access or Taxonomy Access Control? If you do, it could be that there are per-node permissions set and your client's role doesn't have permission to edit that node, or it could be that it is tagged with a particular taxonomy term which prevents him from editing it.
If you don't have any extra node access modules installed, is it just that the link to "Edit" is missing in the tabs section of the page? Can the client type in "http://example.com/node/3/edit" and reach the edit screen that way?
If you supply an answer to these questions in the comments, I'll edit this answer as best I can.
Check the author of the node. If it's different than the client's user account that may account for the problem. If that does not work you may need to "rebuild permissions."
I found out what the issue was. The client account could not edit anything with full-html input format.
I enabled that at /admin/settings/filters and it works just fine now.
Thanks for looking in.
I'm developing a website in Drupal 6.
I've 3 blocks (I use as footers), I've created the first 2 time ago and recently I've added a new one.
As root I can, of course, edit all of them, but authorized users can only edit 2 of them. I dunno how to change preferences for the third block.
thanks
Double check that the block was created in an input format accessible to those users. If they do not have access to the input format, you will need to grant them access to that format or change the format on the block to a more generally accessible one.
Did you look in the permissions page in /admin/user/permissions/ and check all necessary boxes for the authorized user?