Vulnerability in EPiServer.Forms
I have a client using EPiServer for their intranet. They use Windows auth, which means all users are logged in at all times.
The client wants individual departments to start contributing content. To do this, they want to allow access to add and edit content to selected employees via the right-click menu. So, if I'm the editor for the Human Resources department, when I am on a page I have Change rights on, I should be able to right-click and select Edit or QuickEdit.
The client does not want these people directly in Edit Mode. Their concern is that there's just too much complication there for these editors. The client wants them working through Quick Edit only.
We've encountered a number of problems with this.
Scenario: User does NOT have Edit Mode
If a user has only Read access to a page, but does NOT have Edit Mode rights, they get no right-click menu. This is good.
If you start giving them more and more access (Change, Create, Delete, etc.), they still don't get a right-click menu. Not until you give them Publish (detailed below).
If a user has ALL rights to a page, but does NOT have Edit Mode rights, they get a they get an abbreviated right-click menu, with only these options:
Scenario: User DOES have Edit Mode
If a user has only Read access to a page, and DOES have Edit Mode rights, they get a right-click menu with the following options:
Giving them Change, Create, or Delete does nothing -- they still have the same menu options.
Giving them Publish suddenly gives them a "complete" right-click menu, including Edit (on-page), Quick Edit, etc.
Here are our problems under this scenario:
Are there solutions to these options, either through configuration or code?
I resolved #2 with a page plug-in. I hook the PreInit event, then check if the user as at least Change on this page. If not, I disable the right-click menu.
So, with this, it's much less invasive to give everyone access to Edit Mode, since they won't know they have Edit Mode unless they are on a page they can edit.
I think I've managed to answer all my own questions on this, but would like confirmation, just to ensure I'm not mistaken:
So, this means that the editing prospects for users that don't have (1) publish rights, or (2) edit mode are dim, perhaps even non-existant. If we consider the three editings modes as:
If you have only Change rights, and no Edit Mode, you can't do anything, since none of three will work for you.
If you have Publish rights, but no Edit Mode, you can use On-Page Edit only, since the other two require Edit Mode.
If you have only Change right, and do have Edit Mode, you can use Edit Mode only, since the other two require Publish rights.
Finally, if you have Publish rights, and do have Edit Mode, you can use all three.
I just wanted to say that your assumptions of the last post are correct.
Linus, I think the loss of Quick Edit mode in these situations is pretty tragic. I find it so intuitive for users, and I really encourage people to use it more.
Why is there no Save and View option on Quick Edit mode? It would seem like such a simple thing to do. Would there be a way to modify it to enable this?
The main reason (except that we just never got the request to develop it) is that quick edit mode simply turns of all other tabs except edit. Save and view in quick edit mode would just add more complexity to edit panel that already is the most complex page in the system that deals with a lot of different modes and combinations. I don't think that it's possible to change this without having access to the editpanel code since most of this logic resides there. I will however take this request into consideration for future improvements since I know that it's a faily common case to just allow basic editing for some users.
Incidentally, here is my plugin to remove the right-click menu unless the user has at least Change rights to the page. I wrote this because even if a user could only modify a single page, their browser's right-click menu was overridden on every page, which seem a little intrusive to me.
public class RemoveRightClickMenu
public static void Initialize(int optionFlag)
PageBase.PageSetup += PageSetup;
public static void PageSetup(PageBase sender, PageSetupEventArgs e)
sender.PreInit += CheckForEditPermissions;
public static void CheckForEditPermissions(object sender, EventArgs e)
//If this isn't an EPiServer page, abandon...
if (!(sender is TemplatePage))
PageData currentPage = (sender as TemplatePage).CurrentPage;
(sender as TemplatePage).ContextMenu.IsMenuEnabled = false;
have you got around item problem #1