Version 5


    The Ghost Blog plugin allows blog posts to be posted as a different user than the one that authored the post.  This allows for a communications team or an assistant to blog for an executive.  In most cases the Ghost Blog plugin has been replaced by the Delegate Access (Ghost Blog) FAQ - Archived because of publishing issues Add-On.



    The Ghost Blog plugin and Add-On are both available for Jive 8, but the Add-on is recommended for Cloud and Hosted customers.


    Main Configuration

    Admin Console > System > Settings > Configure Ghost Blogging there are 3 main options available.

    Ghost Blog Enabled

    This feature enables the global enable or disable of the Ghost Blog functionality across all places in Jive.  It is recommended that you use the "Disabled" option so that Ghost Blogging can be enabled on a per place basis.   That allows you to keep the ghost blogging functionality restricted to a narrower set of people who need to use it.  We will use the ghostBlog.enabled property to specify spaces and groups that we specifically want to enable this feature for.  See the sections for enabling Spaces and Social Groups below for more details.


    Force User Affiliation

    This feature requires that the users who are ghost blogging for someone are being Followed by them in Jive first.  This adds a layer of security if Ghost Blogging is enabled all over the community without restriction by making sure that users are following one another before they can blog for one another.  It is recommended that this feature be "Disabled" and that you use the Ghost Blog Enabled feature to restrict access to a narrower set of Places.


    Audit Log Enabled

    This feature, when set to Enabled, keeps a detailed record of whenever authorship is changed on a draft of a blog post.  This makes sure that there is record of all changes, and that abuse could be easily tracked if necessary.  It is recommended that this feature be set to "Enabled".



    Enabling Ghost Blogging for a Space

    1.  In Admin Console > Spaces > Extended Properties menu, and using the "Change Space" link at the top select the Space that you wish to add Ghost Blogging functionality to.

    2.  Enter the Property Name: ghostBlog.enabled and Property Value: true

    3.  Save



    Enabling Ghost Blogging for a Social Group

    Adding Ghost Blogging to a Social Group or Project is different and requires the free Admin Essentials plugin.  Submit a support case requesting a free copy of this plugin if you do not already have it.  To note, this is different than the Admin Essentials Add-On just like the Ghost Blogging Add-On is different than the plugin this document focuses on.  More details at Admin Essentials FAQ.

    1.  In the main Jive interface, go to the Social Group that you would like to enable Ghost Blogging functionality in.  Click Manage > Settings to bring up the administration options for the group.  Don't change any options, just copy the number from containerID=XXXX at the end of the URL in your browser.  The number here is the Container ID which we need to set some advanced properties on in the Admin Console.

    2.  Go to Admin Console > Admin > Social Groups > Manage Properties and enter the container ID from the last step.

    3.  Enter the Property Name: ghostBlog.enabled and Property Value: true

    4.  Click Save.


    How to Ghost Publish a Draft Blog Post

    Important: Make sure you have your Timezone preference set in your User Preferences or the Ghost Blog Plugin will not be able to function.

    Step One -- Configuration and set-up to restrict those users that have ability to ghost blog

    • Disable ghost blogging for the entire system: Admin Console > Settings > Configure Ghost Blog > GhostBlog Enabled? > Disabled.
    • 1.png
    • Create a space in which ghost blog writing will occur.
    • Add the system property ghostBlog.enabled set to true to the space you created by adding the system property ghostBlog.enabled set to true to the space: Admin Console > Spaces > Settings > Extend Properties. This system property overrides the setting for the entire system and allows ghost blog functionality only in this space.
    • If you would like additional security, you can also enable Force User Affiliation? at the space level, which would require that both the true owner of the blog and the ghost writer be members of the group, following each other.


    Step 2 -- Create and save the blog as a draft

    In order for the the ghost blogging functionality to appear, a blog must 1) be created in the designated space and 2) be saved as a draft. The settings above mean if you create a blog outside of that space, even if saved as a draft, you will not see the Ghost Publish action. However, if you create a blog in the designated space and save it as a draft, you will see the Ghost Publish action as the last item in the Actions menu on the right side of the screen.


    Step 3 -- Write the blog

    Pretty self-explanatory step.


    Step 4 -- Publish the blog

    Once written, click the Ghost Publish action to select the user for whom you are writing the blog. You will also need to set the time to publish:



    While you might expect the blog post to become "live" when that time arrives, that is rarely the case. Instead, the selected time is when the blog post is "eligible" for publishing.


    The blog post will appear when the blogPostPublisherTask runs. Since the task only runs once every 10 minutes, it may seem like your publish time was ignored or something has gone wrong. However, waiting for the blogPostPublisherTask to run will cause the blog post to be publicly viewable (assuming the Publish Location, explained below, is acceptable). Fortunately, you can see when the next execution time of the task is scheduled in the Admin Console->System->Management->System Tasks page:




    Step 5 -- Move the blog

    Once published, the blog author can move the blog to the appropriate container. It is not possible for the ghost writer to move it to the personal blog of the person for whom they are writing. The person for whom the writer is ghost blogging can move it to their container. For executive blogs, we encourage this to happen in specific place vs. using their personal or system blog to post leadership messages for a few reasons:

    1. Creating an exec leadership place means that execs can post on a rotating schedule and the blog will still look fresh without each one having to post every week or so. Creating a content calendar helps them know when it's their turn.
    2. If each exec wants their own leadership blog, that's fine - multiple places can work, too, especially if they live within the business unit that the exec leads (like...the HR leaderhip blog lives in the top level HR space). Users can follow only the blog in the HR space if they don't want to follow the entire space.
    3. Execs can use their personal blog for non-leadership-message-type blogging - leaving the more "official" messages to be posted in the exec leadership place
    4. Personal and system blogs aren't able to be surfaced in the view blog widget - leaving you to use the recent blogs widget which picks up all recent blogs - not just the ones you want. Putting the exec blogs in a place allows you to surface only those posts in strategic places


    When a draft blog post becomes eligible for publication, and the blogPostPublisherTask encounters it, an attempt to publish the blog post occurs. However, because the Ghost Blog Plugin makes it possible to put blog posts in places where they would not normally be allowed, strange things can happen. To make a blog post "Ghost Publishable", they must be in draft state and in a place with a "ghostBlog.enabled" extended property set to "true". However, to keep everyday users from being able to Ghost Blog, these places are restricted to users in a specific permission group. Only those approved to Ghost Blog on behalf of others are allowed into these places.


    When setting up a draft blog post to be Ghost Published, a "target user" is selected as the new author.


    Once committed, the target user becomes the author of the blog post, and any relationship to the original "ghost blogger" is removed.



    At this point, if the blog post is moved to a place where the new author could normally write a blog post, everything works as expected. However, if the blog post remains in, or is moved to, a place where they could not normally write a blog post, the blog post will remain in draft mode. No error is generated, nor is anything logged in the sbs.log file. The blog post will appear to simply "disappear", never to be published or seen again.


    There is a warning at the bottom of the Ghost Publish form which warns that once a blog post draft is scheduled for publishing.



    This provides a hint that major changes will happen when the Publish button is pushed. However, what may not be obvious is how the change of authorship affects the "ghost blogger" who originally wrote the blog post draft.


    Most "ghost bloggers" probably realize (or will learn quickly) that if you want to move a blog post that is being ghost published, you'd better do it immediately after the Ghost Publish workflow is complete.



    Notice in the above image, even though Administrator is the currently logged in user, this is a blog post draft written by Barney Rubble. In a normal Jive instance, this would not be possible (unless Administrator was able to guess the url of the draft - and indeed was a full Jive admin). So, once Administrator leaves this page, they will not (easily) be able to get back to it!


    However, if Barney Rubble were to log in, and the blog post has been moved to a place where he can normally publish blog posts, he would be able to browse to the draft. However, if he does not have access to the place where the blog post draft is, he will not be able to see the draft! This is the perfect storm: the original ghost blogging user can not see the draft, the new target user can not see the draft, and the blogPostPublisherTask can not convert the blog post from draft to published . . . for all intents and purposes, the blog post has vanished!


    The easiest way to avoid problems is to ensure ghost published blog posts are moved to places where the new target user could normally write a blog post. Failure to do this will cause problems.


    If a blog post draft does get "lost", it still exists in the database. While manually changing records directly in the database can have undesired side effects, it is possible to have Jive support inspect the blog post, verifying that it is still stuck in draft state (which will have a status=3 in the jiveBlogPost table). More importantly, Jive support can determine the URL of the blog post, allowing a properly privileged user to find the blog post and move it to an appropriate location (or delete it, if that is more appropriate).