Selecting a Security Framework for Your Publisher Environment

These articles have been prepared for schools using  25Live Pro and Publisher.

There are a number of important preparatory steps that need to be completed prior to logging in to Publisher and building live calendars from your 25Live data. First, you must decide whether you will have a Publisher framework with a Publisher Administrator and a separate Publisher User account (the Two Publisher Users Approach), or whether you will consolidate these roles into a single Publisher user account (the Single Publisher User Approach).  Either approach is workable and easy to set up. Let's explore the two models for building a security framework for 25Live Publisher.

The Two Publisher Users Approach

The two-level approach involves building security groups and user accounts for two types of Publisher users:

  1. A Publisher Administrator, and
  2. A Publisher User

Using this framework, the Publisher Administrator functions in a role that is very similar to a Functional Administrator and needs security rights to open events in the Event Form, edit Event Descriptions, set Event Categories, and adjust other elements of the event. The Publisher Administrator is also responsible for building applicable event searches to share with the Publisher User.

The Publisher User publishes these searches as event feeds and works in Publisher to build and style the associated calendars. Once this process is complete, the Publisher spud (the Javascript that drives the live calendar) can be integrated into a campus web page, either by the Publisher User, the Webmaster, or a web developer.  

This framework produces a layered approach to the calendaring process where the Publisher User is merely a consumer of events with no access to the Event Wizard (see diagram below). 


Two Publisher User Flowchart


Pros

Cons

  1. Added security benefits. 

    The Publisher Administrator account has functional security rights for managing events targeted for publication to campus websites.

  2. Extra layer of scrutiny.

    The process of editing events targeted for publication is delegated to a power user who can focus on vetting events for spelling, grammar and punctuation as well as clearing up any issues with event titles, event descriptions and other elements of events relevant for calendars.

  3. Delineation of responsibility.

    Allows the Publisher User role to focus on building and styling calendars and preparing the Publisher "spud" code for websites.

  1. Decreased efficiency.

    Adding more users to the Publisher process can extend the amount of time it takes for an event to show up on a published calendar.

  2. Additional security access.

    An additional user account with functional administrator type access is added to the security framework in your 25Live environment.







The Single Publisher User Approach

The single Publisher User approach involves building a user account and functional security group for a single Publisher User. This user needs some event editing ability, but not at the level of a full functional administrator – namely, they will need the ability to edit event elements like event descriptions, event names and titles, and categories.  With a single account, the Publisher User plays dual roles:

  1. Acting as a reviewer of calendaring data on events in 25Live (e.g., event names, titles, and descriptions) and modifying them for web presentation if necessary, and
  2. Creating searches, publishing feeds and building and styling 25Live Publisher calendars.

This approach has the advantage of being more streamlined, keeping all Publisher functions centered in one generic user account (with the optional involvement of a Webmaster or web developer to embed the Publisher spud Javascript code).


Single Publisher User Flowchart


Pros

Cons

  1. Increased efficiency.

    Having one user responsible for editing events and building calendars streamlines the 25Live Publisher publication process.

  2. Increased ownership.

    The Publisher User is responsible for many stages of the event publication process – searching for events, publishing feeds, building and publishing calendars, and styling those calendars for publication to campus websites.

  3. Increased expertise.

    Produces a knowledgeable user aware of the overall structure of published calendars and their contents across campus websites.

  1. Additional security access.

    Grants the Publisher user the ability to edit certain elements of events.

  2. Centralized knowledge.

    A large amount of expertise about Publisher and publication processes is allocated to one user.









Either of these approaches will provide a functional and successful framework for building and styling 25Live Publisher calendars.  Ultimately, the choice of which approach functions best for your campus depends on your institution's needs and preferences as well as campus staffing.

What about the Webmaster?

After reading about the two Publisher User and single Publisher User approaches, you may be asking yourself where the webmaster or web developers fit into the process. One possible option under both frameworks is to have the Publisher users review the events, build the searches, and publish the feeds for live calendars. At that point, the Webmaster, or web developers, would enter the process and use the CollegeNET-generated 25Live Publisher account to log in to Publisher, build the calendars, and style the calendars. The web developer would then be the only user on campus actually working inside of 25Live Publisher. At smaller campuses, it may well be that the Webmaster, or web developer, may also be the person generating the calendars and getting them published to campus web pages. The bottom line is that the system is configurable to meet your campus's staffing and business practices.