Hi,

To edit or post in the blog, the user must be in a page edit role or in an edit role on the blog instance settings under the security tab in settings for the blog.

If they can edit either the page or the feature instance they can both post new posts or edit existing ones. I can't think of a scenario where they would be able to edit existing posts without being in an edit role as described and I'm not able to reproduce that.

You should only grant trusted users a role that allows editing the blog since it is a powerful feature that allows adding javascript to a page.

If you can reproduce the problem on our demo site or provide steps to reproduce the problem I would look into it as a bug.

Best,

Joe

I just tested that and it worked correctly for me, the only link that dissappeared was the settings link when I added the role to roles not allowed to edit feature instance settings.

Best,

Joe

I cannot produce that problem either.

If you provide steps that will reproduce the problem or if you can produce the problem on the demo site I'll look into it.

On another page in my site, there is an HTML content instance where this role does NOT have editing permissions according to the feature settings yet they CAN edit it (when I give them edit permissions on the page).

yes its supposed to work that way, page edit permissions are sufficient to edit any feature on a page, feature edit permissions are just a way to give edit permission on a feature instance without giving them edit permission on the whole page.

Only other suggestions I have to try are:

logout and login again to see if its a role cookie problem

try a different skin to see if its a skin problem

try re-deploying the mojoPortal package in case some files are not up to date

check the logs for any errors

It won't really help me to see it if I cannot reproduce it I cannot fix it.

but also we cannot change the site - role permissions on the demo

I don't know what you mean by that, you can create test pages and test users and confiure the roles any way you want, just don't change the roles of the admin user.

Hi Guys,

Ok, you've pursuaded me that it is a usability issue that needs to be addressed in the UI. My resistance was mainly based on I do not want to change the way security is enforced and I do not want to update role permissions in the database during upgrades, but after thinking about it I beleive I can achieve the needed changes in the UI without doing either of those things.

Just to correct something you said, checking the Administrators box doesn't really "lock the page down" to Administrators only, because you can still check the box for other user roles to allow them rights in addition to Administrators. It really just locks out Content Administrators from editing.

Acutally that is not quite right, but it only makes it more clear that it is not easy to understand and needs improvement for usability.

The way it works is if a page or feature instance permission is set to Administrators and no other roles then only administrators have access. Yes it locks out Content Administrators but it locks out everyone else too.

If no roles are checked then Administrators and Content Administrators have access.

If any roles other than Administrators are checked (even if Administrators is also checked) then, access is available to Administrators, Content Administrators, and the other selected roles.

Basically Administrators and Content Administrators are not subject to role permissions, but the special case is designed in order to make it possible to have some content that is only available to Administrators. So in that case Content Administrators are subject to that special case rule where if Administrators is the one and only allowed role then only Administrators get access.

So I think from the UI we will need 2 radio buttons above the roles checkboxes and I will remove Administrators from the checkbox list. The radio buttons will be like:

1. Only Administrators are allowed

2. Administrators, Content Administrators, and roles selected below are allowed.

If the first radio button is chosen then I will set the role to Administrators only on postback, else it will be based on the checkbox list.

Best,

Joe

That's great news Joe, thanks a lot for doing this. We don't need to use the "restrict to Administrators" functionality, but for those who do, this will help out tremendously.

Just to follow this all the way through, can you also remove Content Administrators from the roles check box list? As I understand it from your correction, by definition Content Administrators will always be able to edit, except when the page is locked down to Administrators only (now via radio button). So there should never be a need to check that box either, correct?

Jamie