Problems with permissions for non-Edit Mode contributors

Vote:
 

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:

  • Edit (for on-page editing -- Save and Publish and Cancel are there but disabled)
  • Print
  • Refresh
  • Copy to Clipboard (disabled)
  • Disable Menu

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:

  • Dashboard
  • Edit Mode
  • Print
  • Refresh
  • Copy to Cliboard (disabled)
  • Disable Menu

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.

Problems

Here are our problems under this scenario:

  1. We need the user to have Quick Edit rights but not Publish rights -- they can change content, but not publish without someone approving it (an automatic workflow is started on check-in).  But it appears that Quick Edit is tied to Publish rights, so this is not possible.  On-page edit will not work.  In 6R1, it's very limited.  Even in 6R2, you don't have access to all tabs like you would in Edit Mode.

  2. If we have to give all of these editors access to Edit Mode, this means their browser right-click menu is changed in all pages, even ones they don't have any editing rights on.  This is too disruptive, and would get flagged by the client's IT department.  (I think we do have to give them rights to edit mode, because the ASPX that rns QuickEdit is down that URL path...)

  3. Assuming we can get Quick Edit to work, can you manage workflow without full Edit Mode rights?  It strikes me that you need the Action Window for this.

Are there solutions to these options, either through configuration or code?

#52327
Jul 18, 2011 21:53
Vote:
 

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.

#52336
Edited, Jul 18, 2011 22:12
Vote:
 

I think I've managed to answer all my own questions on this, but would like confirmation, just to ensure I'm not mistaken:

  • To use either On-Page Edit or Quick Edit, you have to have Publish rights on the page.  This appears to be because neither mode has a "Save and View" option.  In both cases, you only get "Save and Publish."

  • To use Quick Edit, you have to have Edit Mode access, since you have to have access to that URL path via the forms authentication in web.config.  (I could probably rig up a different authentication rule and allow access only to Quick Edit -- not the rest of Edit Mode -- then remove Edit Mode from the context menu via a plugin.)

  • The only way to manage workflow is to have access to Edit Mode.  They need an Action Window to interact with it.

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:

  1. On-Page Edit
  2. Quick Edit
  3. Edit Mode

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.

#52337
Jul 19, 2011 1:11
Vote:
 

Hi Deane!

I just wanted to say that your assumptions of the last post are correct.

#52342
Jul 19, 2011 10:12
Vote:
 

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?

#52351
Jul 19, 2011 15:58
Vote:
 

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.

#52352
Jul 19, 2011 16:11
Vote:
 

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.

[PagePlugIn]
    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))
            {
                return;
            }

            PageData currentPage = (sender as TemplatePage).CurrentPage;

            if(!currentPage.GetSecurityDescriptor().HasAccess(PrincipalInfo.CurrentPrincipal, AccessLevel.Edit))
            {
                (sender as TemplatePage).ContextMenu.IsMenuEnabled = false;
            }
        }

    

#52354
Jul 19, 2011 16:19
Vote:
 

Deane

have you got around item problem #1

#52501
Jul 31, 2011 17:42
This topic was created over six months ago and has been resolved. If you have a similar question, please create a new topic and refer to this one.