none
Blog Permission requires 'Manage List' level just to edit a post RRS feed

  • Question

  • SharePoint 2013

    I'm posting this is a few flavors all over the internet because I'm not getting any responses. Basically I feel their is a bug in that a user that has contribute permissions can not edit a blog post because the "edit" menu option does not show.

    To reproduce, you just need to log into a blog with Contribute rights only which gives you the ability to edit a item, but DOES not give you the ability to manage the actual list. You will see that the Edit menu does not show in neither the summary page or the Post page when looking at a specific post.

    You can however manually change the URL to the EditPost.aspx page and it will let you edit. It is as if the "Edit Menu" is linked to the "Manage List" permission instead of the "Edit Items" permission.

    Standard users should be able to create post, edit post, but not change the settings of the entire Blog Post library!

    Friday, February 21, 2014 5:27 PM

Answers

  • Yeah it's a bummer. Why "edit" rights would give someone the ability to adjust the actual list objects settings is beyond me. That is what "Design" rights are.

    After a very long and frustrating fight I finally gave up and decided to go a different route. It's not ideal but I was able to add my own "Edit Link". So my members only have "Contribute" permission on the Post Library but can still edit the posts.

    Open an individual blog post so that you are on the Post.aspx?ID=n page. Edit that page and add a "Script Editor" web part.

    The snippet code inside the script editor is as such..

    <script type="text/javascript">
       document.write("<a href='" + document.URL.replace("Post.aspx?ID=","EditPost.aspx?ID=") + "'>Edit Post</a>");
     </script>

    However, I found a nicer way of doing the same thing by changing the Script Web Part zone to the "Blog Navigator", and then changing the coded snippet to this....

         <div class="ms-core-listMenu-verticalBox ms-noList">
         <ul class="static ms-blog-listMenu-root ms-core-listMenu-root root">
             <span class="ms-core-listMenu-item ms-blog-quickLinksTitle">Post Tools</span>
             <ul class="static">
                 <li class="static">
                    <a class="ms-core-listMenu-item ms-blog-quickLinksEntry" id="myNewPostKludge" href="/myBlog/Lists/Posts/NewPost.aspx">Create a Post</a>
                  </li>
                  <li class="static">
                    <a class="ms-core-listMenu-item ms-blog-quickLinksEntry" id="myEditPostKludge" href="">Edit this Post</a>
                  </li>
                </ul>
         </ul>
     </div>

     <script type="text/javascript">
         document.getElementById("myEditPostKludge").href=document.URL.replace("Post.aspx?ID=","EditPost.aspx?ID=");
     </script>

    • Edited by da_jokker Wednesday, February 26, 2014 9:02 PM showing additional code fixes
    • Marked as answer by Lindali Sunday, March 2, 2014 6:33 AM
    Wednesday, February 26, 2014 6:30 PM

All replies

  • I had the same issue in my environment. I choose to resolve the issue by setting up custom permission for that list. Unfortunately the contribute permission does not allow users to edit the current list by default, only add, update and delete. So by setting up custom permissions on the list you can specify who actually has full control and who can edit. You can do this by choosing "list settings" and then "Permissions for this list". Once you have "Stop inheriting Permissions" selected the list will then only allow access to the groups specified. You can then select the group that you would like to have full access by clicking the check box to the right of the group and choosing "Edit User permission" in the ribbon, then choose "Full Control" and you will do the same for the users that need edit access but instead of granting them "full control" you will grant them just "Edit" rights.

    Thanks, Danny Hickman IT Support Specialist

    Friday, February 21, 2014 7:07 PM
  • Thanks Danny, but that is the problem: whether you add the "Edit"  Permission to the existing "members" group or just add the "Manage List" permission level to the "Contribute" permission it still ends up giving the end user too much power.

    (The "Manage Lists" permission is the single item that makes the difference between Edit and Contribute).


    Try it... as a person with "Edit" level access to a list, sure the Edit Post menu now shows, but I can go into the Settings of that list and do things like change the name, Turn On\Off Approval, Turn On\Off Versioning, mess with the List Advanced Settings... etc.

    Unless I'm missing something?


    Friday, February 21, 2014 9:24 PM
  • Are you inheriting permissions?

    Do your groups look something like

    Owners

    Members

    Visitors

    For all of my site collections I have this basic structure. By default SharePoint grants "full rights" to the "owners" group

    "Contribute" to the Members

    And "Read" to the visitors.

    Try taking the users out of the members group and putting them in the visitors group and granting the visitors group access to edit the list.

    I am implementing this process in my live environment and I haven't run into any issues with users being able to change or even get to the list properties. Let me know what you find. I could be wrong but I think this may help


    Thanks, Danny Hickman IT Support Specialist

    Friday, February 21, 2014 9:45 PM
  • Danny.. sincerely thank you for trying to help. This is very frustrating.

    So to make sure the problem is not something I caused, I've been doing all this on a clean Win 2008 R2 Virtual Machine. I then perform nothing special and simply do the following:

    1) Install SharePoint Foundation 2013 - Stand Alone (although this problem also exists in my Domain Farm as well as my trial version of Office 2013). As part of the install, I do install the required March CU (KB2768000) but no other SharePoint\Office patches.

    2) With no other changes but the fresh install, I open Central Admin  --> Create Site Collections --> myBlog (via the Blog Template)

    3) I then go to {/sites/myBlog} --> Site Settings --> Site Permissions. I then add the following test accounts as such....

       myBlog Owners (Full Control) <-- SPOwner

       myBlog Members (Contribute) <-- SPMember

       myBlog Visitors (Read) <-- SPVisitor

    4) Verify (which is the default) that Site Settings --> Site Libraries and List --> Customize Posts --> Advanced Settings --> Create and Edit Access = "Create and edit all items"

    ... Now I sign in as each of the 'test accounts' and the results are as follows.

    spOwner = Home page DOES show the Edit link next to the "email a link" option for the "Welcome" Blog Post.

    spMember = Home page does NOT show the Edit link next to the "email a link" option for the "Welcome" Blog Post.

    spVisitor = Home page does NOT show the Edit link next to the "email a link" option for the "Welcome" Blog Post.

    ... Now if I add the "Edit Permission" to the Members and Visitors group the Edit link DOES show. However, for both accounts (SPMember & SPVisitor), I can now do the following...

    COG --> Site Settings --> Site Libraries and Lists --> Customize Post --> Versioning Settings --> Require content Approval = Yes.

    As a Visitor (now with Edit Rights) I was even able to COG --> Add an App --> {take your pick}

    How scary is that ?!?!?!

    Tuesday, February 25, 2014 6:38 PM
  • Danny,

    Here is something you may want to check.. At a site level your visitors group is Read only. If you leave it read Only at the site level, but then break Inheritance at the List Level (for Posts) and add back the "Edit" level.... something also buggy happens.

    1) The COG wheel no longer shows "Site Settings" like in my Out of the Box test above. HOWEVER YOU ARE NOT SAFE!!.

    2) COG --> Site Contents --> Posts --> List Settings ... and you are right back in the same mess I'm in where your visitor can change all sorts of settings.

    Tuesday, February 25, 2014 7:12 PM
  • Da_Jokker,

    You may be right, I totally had this 3 paragraph answer and then I tested it out and it crashed and burned. :/

    So first Off,

    It seems blog site template has different permission settings than a team site. I was giving you an example using the team site template. I forgot you were using the blog site template.

    Im thinking (and im going out on a limb here) that the "blog" feature in SharePoint is really just actually a list. By default if you add the blog site template, SharePoint assumes that everyone accessing the blog will have edit access. Instead of it acting like an actual site, it acts like a list. That's why those test accounts can view the COG-->Site Contents and so forth when you grant them edit access.

    I don't really know a way around this as we are using MySites. When using MySites the users already have the ability to create blogs under their personal site versus setting up another site collection. I would try setting it up that way as users can create and manage their own blogs and then share them throughout the company

    I hope this helps and sorry for the confusion

    Let me know if you come across any ideas


    Thanks, Danny Hickman IT Support Specialist

    Wednesday, February 26, 2014 3:47 PM
  • Yeah it's a bummer. Why "edit" rights would give someone the ability to adjust the actual list objects settings is beyond me. That is what "Design" rights are.

    After a very long and frustrating fight I finally gave up and decided to go a different route. It's not ideal but I was able to add my own "Edit Link". So my members only have "Contribute" permission on the Post Library but can still edit the posts.

    Open an individual blog post so that you are on the Post.aspx?ID=n page. Edit that page and add a "Script Editor" web part.

    The snippet code inside the script editor is as such..

    <script type="text/javascript">
       document.write("<a href='" + document.URL.replace("Post.aspx?ID=","EditPost.aspx?ID=") + "'>Edit Post</a>");
     </script>

    However, I found a nicer way of doing the same thing by changing the Script Web Part zone to the "Blog Navigator", and then changing the coded snippet to this....

         <div class="ms-core-listMenu-verticalBox ms-noList">
         <ul class="static ms-blog-listMenu-root ms-core-listMenu-root root">
             <span class="ms-core-listMenu-item ms-blog-quickLinksTitle">Post Tools</span>
             <ul class="static">
                 <li class="static">
                    <a class="ms-core-listMenu-item ms-blog-quickLinksEntry" id="myNewPostKludge" href="/myBlog/Lists/Posts/NewPost.aspx">Create a Post</a>
                  </li>
                  <li class="static">
                    <a class="ms-core-listMenu-item ms-blog-quickLinksEntry" id="myEditPostKludge" href="">Edit this Post</a>
                  </li>
                </ul>
         </ul>
     </div>

     <script type="text/javascript">
         document.getElementById("myEditPostKludge").href=document.URL.replace("Post.aspx?ID=","EditPost.aspx?ID=");
     </script>

    • Edited by da_jokker Wednesday, February 26, 2014 9:02 PM showing additional code fixes
    • Marked as answer by Lindali Sunday, March 2, 2014 6:33 AM
    Wednesday, February 26, 2014 6:30 PM
  • Just wanted to update everyone.. my process above has been working like a charm. Found a very similar issue now though with "Task List" that won't be so easy to fix.

    Apparently users have to have that same higher level of "Manage List" in order to add tasks to the timeline. You're killing me Microsoft.

    Saturday, May 17, 2014 12:47 AM