Manager Cheat Sheet- vims



Download 44.34 Kb.
Date conversion13.12.2016
Size44.34 Kb.

Manager Cheat Sheet- VIMS


Online How Tos: http://www.wm.edu/cascade

E-mail questions or help requests to creative@wm.edu

Cascade Managers mail list: cascade-managers@wm.edu

The Home Page

Widgets


The VIMS home page has three custom widgets: Featured Research, Featured People and Featured Programs. When you edit the home page in Cascade (vims.edu/index) the first section has 3 file choosers labeled Widget 1 (for Featured Research), Widget 2 (for Featured People) and Widget 3 (for Featured Programs). These fields should typically not change as it is more likely that you'll want to change the contents of the widget rather than replace the widget entirely. You can change the widget contents by editing each widget file under vims.edu/_widgets/home/.

From an editor's perspective home page widgets look the same as standard right column widgets. However, instead of a rectangular image, home page widgets expect a 120px × 120px square image. Any larger square will work, but will be “shrunk” to 120x120 via css.

The key difference of the published home page widget (other than the altered layout that is handled by a combination of css and the format vims_formats/Home – Featured Content) is that if you assigned more that one Image/Teaser/URL set to any one of the home page widgets via the [+] option, that widget will select and present a random Image/Teaser/URL set on each page load. It will not, however, provide arrows on the widget that allow scrolling through all its sets.

Emergency Info


The second section on the home page edit pane is titled “Emergency Info.” If you check the checkbox “Show Emergency Notification,” submit and publish, the Top Stories region will be replaced with whatever you enter in the Emergency Title and Emergency Text fields. Unchecking the box, submitting and publishing restores Top Stories.

Home Page Banner Image


The William and Mary Logo and VIMS logo are placed over your home page banner image automatically by Cascade.

The actual banner images are stored in the folder: /vims.wm.edu/images/bannerphotos/home/ and should be 940px × 468px. If there are multiple images in this folder the home page will choose a random one each time a visitor reloads the page.


The Concept of Groups


Users can belong to any number of groups. Here is how we've chosen to implement groups, along with some terminology we've adopted to describe them.

An extremely basic description of the 5 standard roles in Cascade:



Contributor: Can do nothing without a workflow applied to a folder or asset that they have access to edit. With workflow, a contributor can edit and submit to the workflow.

Approver: If they are assigned to a workflow, an approver can approve or reject an asset that is submitted to the workflow.

Publisher: Can do what a contributor or approver can do. In addition, a publisher can publish assets.

Manager: Can do what a contributor, approver or publisher can do. In addition a manager can be an Administrator of assigned sites in Cascade- to include user administration, managing workflows, managing page types, and managing asset factories.

Administrator: A super user- an administrator of all sites in the Cascade instance.

You can view the detailed abilities of each of the 5 standard roles here: https://cascade.wm.edu/admin/security.act?tab=roles


"Access" Group


Access Groups are used to control read or write access to certain folders. For the VIMS site every user belongs to the group vims__allusers. This group has been given read access to the folder vims.edu and all the folder's children. This basically allows every user to browse to, and link to, any page or file in the VIMS site. In addition to this general access group, each user belongs to one or more additional access groups that grant him/her write access to certain folders. For example, you may create a group called “vims_programs” and at the folder vims.edu/programs set the permissions such that vims_programs has write access to this folder and all its children.

**********************************************************************



WARNING: Setting access permissions on a folder and “Applying to Children” is “destructive” meaning that exactly these permissions will get set to all children. If a child folder has different, more specific permissions those will be overwritten, not merged! For example, if you already have a vims_aboutprograms group set up with write access to folder /vims.edu/about/programs and you decide you want an overarching group called vims_about for the parent folder, when you set the new group on about and select “Apply to Children” the vims_aboutprograms access rights are overwritten and lost.

**********************************************************************


“Role-Defining” Group


We also use groups to define the role of a user. In our implementation, each Cascade user must have at least one access group and exactly one role-defining group. There is a group for each role level that exists in this version of Cascade (besides administrator) : vims__contributors, vims__approvers, vims__publishers, vims__managers.

Group Naming Convention


Note that access groups begin with “vims” followed by a single underscore and role-defining groups begin with “vims” followed by a double underscore. This helps differentiate the two types. The double underscore allows role-defining groups to appear together and at the top of any list or drop down select box.

The only exception to this naming rule is the “allusers” group. Even though it is an “access” group it was created with a double underscore because all users must belong to this group and the double underscore makes it easier to find when creating new users.

Why Use Role-Defining Groups?


We use role-defining groups instead of simply assigning a role to an access group or individual user for the reason that having a group allows a manager to quickly find all their publishers or all their approvers. If you instead selected users with a specific role, you'd get a list of all your users as well as all the users in other schools with that role. If roles were assigned in access groups, it would be extremely difficult to determine your users with a particular role.

Creating an Access Group


  1. Click on Administration in the blue bar

  2. Select New Group

  3. Enter the following data:

    Group Name: Remember the naming convention of prepending “vims_” (single underscore). We've also typically used the name of the folder to which we are attempting to grant write access as part of the group name. We've combined folder names when more specifics are required. For example if you have “programs” folder under “about” and also under “research” you might want to use vims_aboutprograms vs. vims_researchprograms.

    Starting Page: This should be the index page of the folder. For example if this is the vims_about access group the starting page should be vims.edu/about/index. Every user with a Default Group, sees that group's Starting Page in his/her Dashboard when logging into Cascade. (More about default group in Creating Users section below)

    Base Folder: The folder to which you are attempting to grant write access

    Asset Factory Container: For vims.edu select Asset Factories > VIMS or VIMS-User.

    CSS Classes: Usually leave this blank. You could define certain special classes here that would be included in the WYSIWYG style options for group members, but for these to work you also need to define the class in your site's css page(s) as well as coordinate with the CMS Administrator if you want to have the css visually represented in the WYSIWYG editor. We hope that in version 6, we will have separate WYSIWYG stylesheets per site, however right now, the “what-you-see” part of the editor is a single shared stylesheet and we have to find the happy medium... (so even though your site's links should look blue for example, for now they are green while in the editor, because the majority of editors have a site with green links.)

    WYSIWYG Toolbar Options: We typically set the rightmost 4: Content Formatting, Text Formatting, Image Insertion, Table Insertion.
    Note that a user's default group is what determines their WYSIWYG toolbar options- not necessarily the access group of the folder they are working in. For example, you could create a groupuser-with-html-buttonwhich has the HTML option checked, make that the default group for John Smith and everywhere John Smith can edit a page, he will have the html button available.

    Users: As a manager, you must include yourself in the group. Otherwise, you will not be able to maintain the group (you can only see groups that you belong to). If you accidentally miss this step, contact creative@wm.edu and we will add you to the group. Other users can be added to your group at this time, or users can be added individually via the edit user interface.

    Roles: Since this is required, just select Contributor (the lowest possible role). Remember that users will have a role-defining group that will establish their role in Cascade.


Creating Users


  1. Click Administration in the blue toolbar.

  2. Click on Users, Groups, & Roles, then on New User.

  3. Enter the wmUserId in the Username field, enter user’s Full Name and any Email. Keep Authentication selected at Normal.

  4. For Password and Confirm Password fields, enter any matching password you want. Upon submission, a trigger in the database will render whatever password you enter useless. Since these fields are required, however, you have to enter something in order to successfully submit.

  5. Make sure Enabled checkbox is checked (if you want this account to be active).

  6. For Groups, two "double underscore groups" are required for all users:

    1. vims__allusers. The __allusers group applies to all users of a school and enables them to have read access to everything in that site.

    2. A “role-defining” group. ONE OF the following: vims_contributors, vims_approvers, vims_publishers or vims_managers. “Role-defining” groups are used to define Cascade roles instead of the actual role field (see #8).

      In addition to the __allusers group and a "role-defining group," assign to this user any number of "access groups" from the groups field. Access groups are named after folders in the sites and can allow for write and even publish permissions on said folders.

  7. Select a Default Group. This should be the user’s primary “access group.” A user’s default group defines the Starting Page (see dashboard) and the available Content Wizards, or Asset Factories (also see dashboard). If users are in multiple groups, however, selecting New in the blue toolbar will display multiple asset factories.

  8. Make sure the Role is set to Contributor (the lowest possible). This is because a user’s role is defined by a group (see #6).

  9. Submit.

** Your new user will be added to the "cascaders" mailing list via an overnight scheduled job.**

Ensuring Users Are Functional


So you have a user and the user belongs to the "vims__allusers" group, a role-defining group (for example "vims__publishers") and an access group like "vims_somedepartment." The last thing you need to do is to make sure that the access group is in fact assigned write permission to the applicable folder. For example if the user is to have write access to the entire department folder, go to and select the vims.edu/mydepartment folder and in the main screen select Advanced tab > Access.

The Group Section Access permissions should look like:



Unassigned:

(most groups)



Read:

vims__allusers



Write:

vims__managers

vims_mydepartment

* note: You may have multiple "access" groups if you have multiple groups of users who will edit things in this folder.

Use the Arrows provided to push groups into the Read and Write boxes if necessary.

Select Apply to Children (see warning below) and submit.

**** WARNING: "Apply to Children" is exact, meaning if you have different lower-level permissions (on sub folders) the permissions will be overwritten with exactly what you apply at this site root level. Access permissions are not merged. This means that after you finish applying to children you will have to drill down and redo any lower-level permissions that may have been previously set (so make a note of any lower-level permissions first).


Asset Factories


Asset Factories are what you use to create assets (specific page types or widgets). These can be be grouped in “containers” and it is possible to have different groups use different asset factory containers. To adjust who can see an asset factory or a container select “Administration” in the blue bar, select Asset Factories, then select the particular container or factory. Click the edit tab in the main window then adjust the “applicable groups” accordingly.

*Note that even if you edit theapplicable groupof a container, you still need to edit the applicable group of each asset factory (and any sub-containers) within it.

Overview of Cascade Structure


The following is a high-level overview of how Cascade structures pages and content. The Hannon Hill knowledge base is a good resource for this information as this overview is not specific to our implementations.

(http://www.hannonhill.com/new-kb/index.html)


Templates


From the Hannon Hill knowledge base:

A Template is a fundamental system entity that defines the HTML/XML structure of page asset in the CMS. Templates are essentially XHTML documents that contain standard HTML tags and CSS that create what is commonly referred to as the "look and feel" of a web page.

The VIMS templates are all stored under the “root-level” /vims_templates folder (not under vims.edu).

**********************************************************************



WARNING: It is highly recommended that you do not edit templates in the production instance of Cascade. Data can be permanently lost! Instead, we ask that you use the test instance at http://cascadetst.wm.edu first.

***********************************************************************


Region


In addition to HTML, Templates consist of Regions (denoted by tags like ). Each Region can have a “block” and a “format” associated with it.

Blocks and Formats


Blocks are basically chunks of data. In Cascade blocks can be xhtml (text) or xml. The most often used block in our implementation is the “index” block- which when pointed at a folder pulls in all the metadata about the folder, all the metadata about each asset in the folder and all the information in each asset (fields, content, metadata). It will traverse the folder however deep you need it to go and all this information is compiled in a large, well-formed block of xml.

In general blocks that are not meant to change are stored under the vims_blocks folder. If there is a need for blocks to be maintained by non-managers they are stored in vims.edu/_blocks or vims.edu/path-to-section/_blocks



Formats (aka xml stylesheets) are pieces of xml code that “adjusts” the data in a block- this adjustment might include filtering, sorting, or repurposing the xml to html ready for display. As of version 5.7 Cascade Server also supports using Velocity (another language) in formats, however we did not use this in the vims.edu implementation (nor any other implementation to date).

Blocks and formats are why Cascade seems a bit sluggish to users at times, because each time you click on a “page” all the blocks in the regions are being pulled and compiled and any formats are being run against each block. If your block is not efficient (small), this can get pretty nasty. The good news is that on the web server, the published page is simply the end result of all that xml combining and formatting- There is no dynamic work happening to build the page on the published site.

Configuration Set


From the Hannon Hill knowledge base:

A configuration set is a collection of one or more configurations that can be used to help create one or more pages. In order to be used to create a page, a configuration must be a part of a configuration set. Configuration sets that include multiple configurations are typically used when multiple outputs are required, such as HTML, XML, or printer friendly. To make large numbers of configurations manageable, Cascade uses Configuration Sets to group a number of configurations, along with their respective targets, templates, and block and format assignments.

In our implementations, configuration sets are used to slightly alter a Template to produce a different page type. A Template can have multiple configuration sets. For example the “News Story” template has the following configuration sets:


  • Borrowed Story

  • Blog Post

  • Borrowed Event

  • News Story

  • Event

  • Announcement

(you can check this by clicking on a Template then clicking the “Subscribers” tab in the main window.) Blocks and Formats assigned to regions at the configuration set level trump the blocks and regions defined at the Template level.

Data Definition


Each Cascade asset has some form fields that are populated by the user who is creating or editing the asset (for example titles, checkboxes, or the WYSIWYG editor content). The fields that are presented to the user are customizable through a data definition. There are a certain number of fields that are pre-defined and are part of every asset called “wired” fields and there is the ability to extend these fields with some of your own called “dynamic” fields. Field types are discussed in more detail in the Hannon Hill knowledge base.

Metadata Set


From the Hannon Hill knowledge base:

A Metadata Set is a system component that provides the interface for customizing the kinds of metadata fields that can be visible and/or associated with an asset. Since metadata fields can be broken into two categories, wired and dynamic, metadata sets allow administrators to choose which wired fields can be made visible to end users and which ones will be turned off. Likewise, the interface allows for dynamic fields to be created that help to further describe an asset beyond the scope of what regular wired fields allow.

Metadata sets also allow for administrators to customize the wired and dynamic metadata fields so that they appear "inline" in the editing interface for an asset instead of appearing in the metadata pane, making the fields more accessible to end users. Additionally, fields can be set to 'required' so that end users must enter acceptable values for metadata before saving the asset.

Content Types


From the Hannon Hill knowledge base:

The addition of Content Types with the release of Cascade 5.5 provides users with a way of formally aggregating Configuration Sets, Metadata Sets, and Data Definitions into a single Administrative component that can be applied to pages. Content Types provide an intuitive and logical way for end-users to identify the proper type to associate with a page by grouping together the necessary configurations for predefined page types with familiar names, such as Blog Posts, Press Releases, Announcements, etc. Much in the way Cascade Server utilizes Asset Factories to create predefined recognizable assets such as pages, templates, etc., Content Types are given simple names that clearly identify their purpose to end users. The addition of Content Types simplifies the page edit interface by consolidating previous options into one Content Type chooser. This provides a single point of control for Administrators to modify a page's Configuration Set, Metadata Set, and/or Data Definition for selected pages without requiring a Bulk Change operation.



Content types can only be changed by Managers and Administrators.

**********************************************************************



WARNING: There are times when you may need to change the content-type of an asset. For example maybe someone created a News Story when they meant to create a Feature and they don't want to have to create a new asset and cut and paste the title, summary, WYSIWYG page content, etc. You may chose to simply change the content-type of the original page instead. However, when changing a content-type the values of dynamic metadata fields are lost This refers to values in fields like “Top story,” “Show third column,” “Show parent above menu,” and “Show siblings on menu.” Be sure to make a note of these values so you can reset them after changing the content type.

**********************************************************************


Adding Content to the “Extra” Regions


In many of the page templates we've added extra regions where you might want to include additional content. There is a region under the left hand menu that is typically unused and there is a region under the main body content that is only being used by listing pages. To add content to either of these regions all you need is a block and a format to assign to them.

In general blocks that are not meant to change are stored under the vims_blocks folder. If there is a need for blocks to be maintained by non-managers they are stored in vims.edu/_blocks or vims.edu/path-to-section/_blocks


Publishing


Publishing is handled by way of a transport, target and destination that are already defined for vims.edu. The transport is a sftp to a VIMS web server directory (the directory being the destination). The “applicable groups” for the target (the defining component of the destination with other metadata) are vims_managers and vims_publishers.

The entire vims.edu folder is scheduled to publish MON/WED/FRI at 9:30pm. To do this a publish set is used. A publish set can be created to publish any group of folders or files. The set can be published via a schedule or some other event trigger like a workflow.


Cleaning “Orphan” Files


Occasionally there will be files that are on the web server but are not managed directly in Cascade. This can happen when a user moves a file without unpublishing it from the old location. This can also happen when a user deletes a file but does not unpublish it. The problem is that since Cascade Server no longer has a handle on the file, we can no longer delete it though the Cascade interface. We refer to these files as “orphans.”

Since Cascade publishes to VIMS servers via sftp, VIMS IT support will manage any orphan files.


Custom Banners



Standard Page Banners


The random banners in your website work with a small bit of php code that is written in the “BANNER” region's format of all pages. The code selects a random image from a defined folder.

By default, the images located in the /vims.edu/images/bannerphotos/about folder are used. You can change this default behavior as follows:



  1. Create a new folder of images under /vims.edu/images/bannerphotos. You should use a folder name that is easy to associate with your section. Upload images into your new folder. The standard VIMS banner images are 940px × 203px. Note that not all users have write access to the bannerphotos directory but access can be controlled by a manager.

  2. Browse to and edit your section's main folder, click on the Metadata sub-tab and in the “Banner Photos Bank” field type the exact name of the folder of images that you just created under /vims.edu/images/bannerphotos/ (Just type the folder name, do not include the path.)

  3. Publish both the new folder of banner images and the entire section where they will be applied. Note that you do not need to set the Banner Photos Bank field value in every subfolder of your section. Each page in your site traverses up the tree of folders until it finds a defined folder (typically your section's main folder) or if it makes it all the way up to the root vims.edu folder and finds nothing it will use the default folder (/vims.edu/images/bannerphotos/about)


Advanced Banners- Primary Pages


You may notice that some pages in your site were set up with a taller (940px × 262px) banner image, where the third column actually juts up into the image a little. These are a different page type called a primary page.

To create a content page with a primary-sized banner select New > VIMS > Folder with Primary Page. If you instead create a folder with content page and later want to change the page to a primary one, you'll need to follow the instructions above for changing a content-type ... in this case fromStandardtoPrimary.

In addition to having the proper page content-type, primary pages need their own folder of banner images. Any section that might have a primary page requires a second folder of banner images. The name of the folder must be the same as the section's standard banner image folder with the word primary appended to it.

For example, Let's say you want custom banners for your giving section and the giving section willhave pages with both standard-sized banners and primary-sized banners. You'd create two folders for the banner images:

/vims.edu/images/bannerphotos/giving

/vims.edu/images/bannerphotos/givingprimary

… loading the shorter 940px × 203px images in the former and the taller 940px × 262px primary page banner images in the latter.

You do not have to do anything differently as far as assigning the “Banner Photos Bank” value in the section's main folder metadata. Primary pages are smart enough to “know” to use the name you enter but append “primary” to it.


Banner “Overlays”


In the VIMS site the transparent pngs “William & Mary” and “VIMS” overlay all banner images. If you want to replace “VIMS” for a particular section you can do the following:

  • Upload a transparent png in the folder /vims.edu/images/bannerdepartments and publish the image.

  • Edit your section's main folder.

  • On the Metadata sub-tab check “Use Department Info below?” and in the Department field enter the replacement png file name only.

  • Publish your entire section.

If you have the need to replace VIMS with 2 stacked images – an “umbrella” department with a department under it as is demonstrated here: http://www.wm.edu/as/english/index.php – follow these steps:

  • Upload 2 transparent pngs to the folder /vims.edu/images/bannerdepartments and publish them.

  • Edit your section's main folder

  • On the Metadata sub-tab check “Use Department Info below?” For Department enter the department's png file name only. For Umbrella Department enter the umbrella department's png file name only. For Umbrella Link field type the path of the umbrella department folder minus “www.wm.edu”, with a slash before and after (for example if the umbrella department was located at /www.wm.edu/as you'd enter /as/)

  • Publish your entire section


Test Instance


We have a second instance at http://cascadetst.wm.edu that can be used for training or testing. It is highly recommended that you use test for any experimental editing, particularly editing existing templates. Keep in mind that there is no way to import/export data or files between the production and test instances.

NOTE: There is no test publish target set up yet for VIMS.



The database is protected by copyright ©dentisty.org 2016
send message

    Main page