Blog post author unable to edit his own post


I'm trying to implement a feature where a user could edit his own blog post after he already created and published it. I ran into problems when the user is not an admin on the site and tries to edit his blog post.

Code looks something like this:

PublicApi.Users.RunAsUser(post.Author.Id.Value, () =>
var post = PublicApi.BlogPosts.Update(blogPostId, new BlogPostsUpdateOptions { BlogId = blogId, Title = title, Body = body }); });

Update returns empty (not null) object, and the blog post is not being updated. No exception is thrown.

I've granted "Blog - Edit Posts" permission for "Registered Users" role in "Blogs" group  where we create all the blogs for all the users.

But in my opinion the blog post owner/author, admin or no admin. should be able to edit his own blog post.

Can you suggest how to allow the editing of a blog post to a non admin user, who is an owner/author of that particular blog post ?

Thank You,


  • You may be able to do this by adding the blog - edit posts permission to your authors. This would allow them to edit any post though. Correct this by modifying the blog - links widget to not display the edit link if the accessing user<> blog author. then on the create edit blog widget, If editing, do the same check and, if the author display the WYSIWYG editor and if not the author display an error and link back to blog post.

  • In reply to Sean Carlisle:

    I think I'm doing the exact thing as you're suggesting. The authors are in "Registered Users" role, which has "Blog - Edit Posts" permission in "Blogs" group. Then I'm handling the editing of the blog as you suggest here as well.

    Thing is, that these permissions doesn't work. When the author tries to update his blog post, update returns empty blog post with some suspicious property.

    Code snippet is still the same:

    PublicApi.Users.RunAsUser(post.Author.Id.Value, () =>
      post = api.BlogPosts.Update(blogPostId, new BlogPostsUpdateOptions { Title = title, Body = body });

    In debug mode I can see this , when blog post returns after failed update try by it's author:

    post.Application.base.Source = "Telligent.Evolution.Api"

    post.Application.base.Message = "Parameter "Key" cannot be null or empty"

    post.Application.base.StackTrace = "at Telligent.Evolution.Api.Ensure.™ (String name, String message)

      at Telligent.Evolution.Api.Services.BlogService.GetBlog(Nullable`1 blogId, String key, Nullable`1 groupId)

      at Telligent.Evolution.Extensibility.Api.Entities.Version1.BlogPost.ŠŽ‚()

      at Telligent.Evolution.Extensibility.Api.Entities.Version1.BlogPost.get_Application()"

  • In reply to povilas:

    Hi povilas,

    A couple questions:

    1. Which version of the platform are you using?

    2. What method are you using to allow your users to create blog posts? Have you set them as authors or added "Blog - Create Posts" permission to some role? Or some other method?

    3. Where are you using that code snippet? Blog post editing happens in a control panel page (which anyone with blog post edit permission has access to) and the save logic should happen automatically. Are you creating a custom widget to do the editing?

    And as Sean mentioned, any method you use to allow authors to edit their blog posts will also allow them to edit other user's posts in that blog. You can prevent this by hiding the edit button when the accessing user and blog post author do not match.

  • In reply to Steven Heffner:

    1. Telligent Community 7.5

    2. We are using Telligent REST API method:

    3. The code snippet is being used in our own service which is called using AJAX. We use it in our own service to be able to use Telligent In-Process API for impersonation purpose (PublicApi.Users.RunAsUser(post.Author.Id.Value, () =>). Why impersonation needed ? Because we want to allow not only authors to edit, but also admins and when blog post would be edited by admin, the activity story, related to the blog post, actor would become the admin who edited, not the blog post author, so impersonation required to make as the author edits the blog post every time.

  • In reply to povilas:

    Can you provide the full Stack Trace of what you are seeing in debug mode?

    I'm guessing you are using some sort of OAuth or SSO to validate users when creating posts via REST?

  • In reply to Steven Heffner:

    1. This code snippet is being run in our web service, which is called from client side javascript and then service methods calls Telligent In-Process API, stack trace doesn't give anything valuable, because I can't debug Telligent.Evolution.Extensibility.Api.Version1.PublicApi.BlogPosts.Update method.

    2. When creating user blog posts, we use Telligent REST API on client side, like shown here in example: Creating blog posts works fine for every logged in user. - takes care of authentication for logged in users.

  • In reply to povilas:

    For what its worth you can impersonate in REST without the need to proxy the call:

    And how to set headers in the post  javascript call is the same was as jquery.ajax

  • In reply to Patrick Mason:

    It's possible that the permission code is checking the site permission "Feature Content" when it shouldn't be, can you test editing a blog after granting "Feature Content" permission to Registered Users?

    If this is successful then we will likely have a bug to log and hotfix.

  • In reply to Steven Heffner:

    To clarify, the exact permission is "Site - Feature Content" and it is in the Manage Site Roles section of Membership Administration.

  • In reply to Steven Heffner:

    Indeed. Granting the "Site - Feature Content" permission in the Manage Site Roles section of Membership Administration solved the issue. Now the blog post author is able to edit the post.

    1. What can be the negative effects of having this permission granted for "Registered Users" role?

    2. When the bug is fixed in the future and to not let the fix brake our functionality, we should now set the "Blog - Edit Posts" permission and remove "Site - Feature Content" permission after fix ?

  • In reply to povilas:

    Glad to hear that resolved the issue. I will file a bug to get this resolved in a hotfix.

    1. The downside is that any user can decide to make their content "featured" which may result in clutter on group pages. More info on featured content here: The fix would be to alter the widgets that ask about featuring content to not show that option at all (both the create and edit widgets if separate).

    2. After updating to a hotfix that includes the fix for this bug, you would be able to remove the "Site - Featured Content" permission from the Registered Users role, as well as roll back any widget changes made to hide the featured content options.

  • In reply to Steven Heffner:

    Thank You, Steven, great help.