Custom Post Pages for site workflow

jleask — Tue, 26 Aug 2008 17:35:50 GMT

We recently had a client who required a custom post page for workflow purposes:

Please create role "DraftPosts" and allow them to create posts in the "Workflow" blog but only save drafts, not publish. Also, please make sure they use the site skin, not the control panel skin

Fairly simple with a few "gotcha" steps.

Create the new role "DraftPosts"
Update "Workflow" blog permissions to allow "DraftPosts" to manage content

That's fairly simple, but step 2, which I forgot, can cause quite a bit of headache if missed. The next step is creating your Post Editor page; it's also fairly straight forward.

From /ControlPanel/Blogs/ copy CreateEditBlogPost.ascx and PostEditor.aspx (and associated .cs & .resx pages) to your new location. You'll want the new location to have access to the appropriate theme, so I put it in /Themes/leanandgreen/common/.
Update both pages so the class names are unique. I renamed them to DraftPostsPostEditorPage and DraftPostsCreateEditBlogPost respectively.
Update both ASPX pages: inherit from the updated code behind pages and pointing them to the correct master pages. ex.:
        <%@ Page language="c#" Codebehind="DraftPostsPostEditor.aspx.cs" AutoEventWireup="false"
        Inherits="CommunityServer.ControlPanel.Blogs.DraftPostsPostEditorPage"
        MasterPageFile="~/Themes/leanandgreen/common/master.Master" %>
Assign the Workflow blog section ID to the CSContext:

        override protected void OnInit(EventArgs e)
        {
            .......
            MyWeblogSectionID = Weblogs.GetWeblog("Workflow").SectionID;

CSContext.Current.SectionID = MyWeblogSectionID;
.......

}

Lastly, remember they only want the user to be able to save, not publish. There are various ways of doing this and by far likely better ways than I chose to. That said, I just hid the "Publish" button!

Good luck, and don't hesitate to let me know if the above steps didn't work for you!

Accessing Blog Permissions (aka: Using roles for Blogs, not Users)

jleask — Thu, 06 Dec 2007 21:22:00 GMT

There are usually 3 or 4 hundred different ways to skin a cat within .NET - and programming in general for that matter - so in no way will I ever declare MY way of doing things THE way of doing things ... they are just A way. With that said I present to you my solution for displaying a blog in a custom list based on it's "role" (aka: Permissions Settings).

Customer Request:
Customizable list of blogs (yes, a Blogroll, if you will) from within this site. Must be able to add and remove blogs from this list.

This auto-generated list already existed and it was in our best interest to reuse that. In the past it was done by grabbing all the blogs, removing all the dead ones (no posts) and displaying them all. It's just a custom little list to show the blogs by author - nice, easy, clean; now they want the ability to remove a blog from THIS list without removing it from any of its groups or aggregate post lists. After talking it over with a few people the decision was made: let's (ab)use roles!

Membership Roles:
All membership roles (a site administrative list in Control Panel > Administration > Membership > Manage All Roles) appear within a blog's settings console (Control Panel > Administration > Blogs > Blogs (so nice I said it twice) > [open any blog] > Permissions). They each have a handful of options available to you, of which in this particular exercise we only care about one ... "view".

First, create a role "InAuthorList" - Second, select your blog and click the checkbox to the right of "InAuthorList" and below "View" in the blog permissions screen. That is the entire user experience for your site administrators . No new administration pages for you, and no convoluted instructions for your administrators to follow. 1, 2 punch ...

Building your List:
The first step here is easy: create an ArrayList of blogs using the Weblogs.GetWeblogs() method. After that, sort and filter - the real reason we are here though, that's the filter:

FilterBlogs()

private ArrayList FilterBlogs(ArrayList blogList)       
{       
   ArrayList cleanList = new ArrayList ();       
   foreach (Weblog blog in blogList)       
   {       
     Hashtable ht = blog.PermissionSet;       
     if (ht["InAuthorList"] != null)       
     {       
       WeblogPermission ebl = ht["InAuthorList"] as WeblogPermission;       
       if (ebl.View == true)       
       {       
         cleanList.Add(blog);       
       }       
     }       
     else       
     {       
       cleanList.Add(blog);       
     }       
   }       
   return cleanList;       
} 

The real guts of this is the Hashtable that is returned from Weblog.PermissionSet property. A hashtable is a list of key/value pairs - first you have to access the record you are looking for, and for our purposes that is the role we created earlier "InAuthorList". While I shouldn't have to check that it's not null, since roles can be deleted by site administrators it's smart to check for that and have a backup plan (mine is to add everything if the role is non-existant).

Now that we have our record within the hashtable, we need to get our value. First, set the record to a Community Server WeblogPermission object, then test that the "View" (our key) option is "true" (our value - and yes we're testing against the boolean true, not a string - when we cast the record as a WeblogPermission, it knew to cast he string "true" to a boolean). See, that wasn't so hard now was it?

Roles and Users:
While we didn't use them the way they are designed to be used, generally when dealing with roles you are more concerned with wether a user is in the role than if the role should be displayed - and with a simple "IsUserInRole" check you can - but since that's not what I was focusing on, I'm going to leave that for another post.

In Conclusion:
I'm curious how you would have solved this. Really, the only reason to have people read these thoughts is to get their opinions ... so tell me: How would you have solved the clients request with minimal effort?

Oh yeah, I have to thank fellow Telligenti Joel Dewbre (no blog to link) and Kevin Harder for the help they both gave in this little venture. I'm still very new to customizing Community Server and while it's very customizable if you know what you're doing ... well ... I'm still learning what I'm doing!

Digital Serenity : Community Server, Code

Custom Post Pages for site workflow

Accessing Blog Permissions (aka: Using roles for Blogs, not Users)