Suppressing collections and content from view

From FIG

Jump to: navigation, search
Navigation
NewFig1201.png
FL-Islandora Guides (FIG)
FL-Islandora Overview
User Interface
Permissions and users
Collection Creation and Management
Content models
Creating Content Objects
Metadata
Suppressing Objects From View
PALMM guidelines
Fl-Islandora and Mango
Site Administration
Workflow: From Spreadsheet to Islandora
Using Google Analytics with FL-Islandora
Collection Information Menu
A-I. FL-Islandora Glossary
A-II. Field Inventory

Suppressing collections and content from public view

Contents

Overview of methods

There are three ways to suppress a content object from public view:

1) use an Object Policy on Object Viewing
2) put an IP embargo on the object
3) add the object to a collection with an Object Policy that suppresses members


NOTE: There is only one recommended way to suppress a collection object from public view: attach an Object Policy to the collection. FLVC recommends using the policy option All children of this collection and collections within this collection (existing and new) when suppressing a collection object, so that the child collections and content objects are not retrievable by the public and will not be contributed to the Discovery Tool (Mango).


Each manner of suppression works differently and is designed to serve a different use case.

Object Policy (XACML Restrictions)

Islandora Object Policies that restrict access to collection and/or content objects are implemented via XACML policies (written in eXtensible Access Control Markup Language). An Object Policy (XACML Policy Stream datastream) restricting Object Viewing will allow only users with roles specified in the policy to view the object. For example, viewing could be restricted so that only users with staff roles can see the object. Unauthorized viewers will not see the object in browses or in search results. Also, an unauthorized user trying to access the object directly by PID will get the message “You are not authorized to access this page.”

The roles defined in the system are:

  • anonymous user
  • submitter
  • editor
  • supervisor
  • collection manager
  • site administrator
  • administrator (this role is reserved for FLVC staff)
  • authenticated user

The role “authenticated user” automatically includes anyone logged on to the system, all but anonymous users. For more information about roles, see Permissions and users.

Inactive State

NOTE: At this time FLVC does not recommend using the "inactive" State to suppress a collection from public view, as this method also suppresses objects from staff view. Objects can only be retrieved from the Inactive Queue, which is shared by all sites and is not implemented in production on FL-Islandora.

An Inactive object is removed from the search indexes. It will not appear to any user in browses or in search results. However, any user can access the object directly by PID.

Content objects can be rendered “inactive” directly, by clicking to "Manage", then clicking "Properties" and changing the object status to “inactive”, or indirectly using the workflow module. Collection objects can be made inactive only by changing the object status to “inactive”.

IP Embargo

An embargo will restrict viewing of an object to users within a defined set of IP address ranges. The thumbnail of the object is visible in both search results and browses, but if the user is coming from an address outside the allowed address ranges, the thumbnail will indicate that the object is restricted. IP embargoes can be placed on collections or content objects, however an IP embargo on a collection object will not automatically place embargoes on the content objects within the collection and these content objects will be retrievable in search results. To display an embargo message on an entire collection and to also ensure that its content objects are not retrievable in search results, IP embargoes should be place on the collection and on all of its content objects.

Object policies (XACML Restrictions)

Attaching Object Policies to Content Objects

An Object Policy (XACML Policy Stream datastream) can be attached to an individual content object. Navigate to the object and click the "Manage" tab, then click “Object Policy”. (This link will only appear to users with permission to set Object Policies.)

Three permission categories will appear:

Enable XACML Restrictions on Object Management
Enable XACML Restrictions on Object Viewing
Enable XACML Restrictions on DSIDs and MIME types

Click the check box in front of “Enable XACML Restrictions on Object Viewing”. This will expand to a form:

EnableXACML.png

Set the roles which will be allowed to view the object by clicking on one or more role(s) listed under “Allowed Roles”. To select multiple roles, hold CTRL when you click. To a select a range of roles hold SHIFT and click the first and last roles in the range.

Note that selecting “authenticated user” will automatically select all the roles requiring authentication (administrator on down). However, at some point in the future, patrons will be able to log on to their own patron accounts for “mySpace” type of functions. Therefore it is not a good idea to select “authenticated user” if the intent is to restrict viewing to authorized staff.

Alternatively, permission to view can be granted to individual users, rather than all users with a certain role. Select the individual(s) with permission the same way you would select roles. It is also possible to select both roles and individuals.

After you select the roles and/or users to be allowed to view the object, click the “Set Permissions” button.

Note that Object Viewing policies set on Book objects at the title level will be inherited by the pages in the book. However, if pages are added via the Zip File importer to an existing Book object with an Object Viewing policy, those pages will not inherit the policy.

Object Viewing policies set on Newspaper issues will be inherited by the pages in the issue, with the same caveat about the Zip File importer as for books. However, an Object Viewing policy set at the Newspaper title level will not be inherited by issues or pages.

Attaching Object Policies to collection objects

To attach an Object Policy on Object Viewing to a collection, navigate to the collection and click the "Manage" tab, then click “Object Policy”. (This link will only appear to users with permission to set Object Policies.)

Three permission categories will appear:

Enable XACML Restrictions on Object Management
Enable XACML Restrictions on Object Viewing
Enable XACML Restrictions on DSIDs and MIME types

Click the check box in front of “Enable XACML Restrictions on Object Viewing”. This will expand to a form:

EnableXACML2.png

Select the role(s) and/or user(s) with permission to view the collection object in the same way you would do so for a content object (see “Attaching Object Policies to Content Objects” above).

The collection form gives another option that must be selected from a pull-down menu: “What items would you like to apply this policy to?”

The policy choices are:

  • New children of this collection
    • This will hide the collection object itself and all content objects added to the collection after the policy is set if the objects are added by online ingest or offline ingest.
  • All children of this collection (existing and new)
    • This will hide the collection object itself and all content objects in the collection, both current and new.
  • All children of this collection and collections within this collection (existing and new)(Recommended setting.)
    • This will hide the collection object itself, all subcollections (and sub-subcollections, etc.), and all content objects in the collection and its subcollections, both current and new. The entire collection hierarchy is suppressed from the collection with the policy to the lowest level. FLVC assumes that the user's intention when placing restrictions on viewing of a collection is to allow only logged-in staff to view that collection and its child objects.

Select the appropriate choice and click “Set Permissions”.

Note that if a book or newspaper issue is added to a collection with an Object Viewing policy, that policy will be applied to the book or newspaper issue and all its pages.

Checking an Object Viewing policy

After applying an Object Viewing policy to a collection or content object, it's always wise to check the "Manage"->"Object Policy" setting to confirm that an object viewing policy has been correctly set and that a "XACML Policy Stream" datastream has been added to the object.

Removing an Object Viewing policy

To remove an object viewing policy from a content object, navigate to the object, Click the "Manage" tab, then click “Object Policy”. Uncheck the box.

EnableXACMLbox.png

and click “Set Permissions”. The policy will be removed.

To remove an object viewing policy from a collection object, navigate to the collection and follow the same steps.
However, note that if you want the policy removed from existing members of the collection, you must select “All children of this collection (existing and new)” or “All children of this collection and collections within this collection (existing and new)” as appropriate. If you take the default option, “New children of this collection”, the policy will be removed from new additions to the collection going forward, but current members of the collection will remain suppressed to unauthorized viewers.

EnableXACMLdropdown.png

Inactive objects

NOTE: At this time FLVC does not recommend using the "inactive" State to suppress content objects from public view, as this method also suppresses objects from staff view. Objects can only be retrieved from the Inactive Queue, which is shared by all sites and is not implemented in production on FL-Islandora.


All objects have three object properties managed on the “Properties” screen: Label, Owner, and State. Allowable states are “Active”, “Inactive”, and “Deleted”. FLVC policy prohibits use of the “Deleted” state. FLVC policy also recommends against making collection objects Inactive. To suppress a collection and its members from public view, use a collection level Object Viewing policy.

To set the state of a content object to Inactive, navigate to the object and click the "Manage" tab, then click “Properties”. You will get a form displaying the object Label, Owner, and State.

ObjectProperties.png

Use the pull-down menu for State to set the state to Inactive. Click the “Update Properties” button.

To unsuppress the record, go to the same form and use the pull-down to change the state to “Active”.


Inactive queue

Note: As of 12/19/13 the Inactive Queue has not been enabled in production sites.

Operators with the “submitter” role will have all content objects they ingest created with “Inactive” state by default. This will happen regardless whether the objects are ingested interactively online, by zip file import, or by offline batch ingest. This feature exists so lower level staff like student assistants can have their work reviewed by supervisors before it displays to the public.

The “inactive queue” allows reviewers to find these suppressed (inactive) items more easily. Staff with the authority to review the inactive queue will see a link on the left-hand sidebar to “Manage inactive objects”. Clicking the link provides a view of the inactive queue.

SimpleWorkflow.png

At this time, only the title of an inactive object displays in the inactive queue.

Click the title to display the object. Click “Manage”, then click to display the "Properties" page for the object. The state can be changed to “Active” from the Properties page.

Using Embargo

(See also Site Administration: Embargo Setup)

The Embargo function is useful for limiting access to campus use only or other IP-definable populations. Embargoes work by prohibiting access to all users EXCEPT those coming from a particular set of IP addresses. (These sets must have been previously created by a site administrator. They may include an empty set including no IP addresses at all, which prohibits all access to the object.)

To add an embargo to an object, navigate to the object and click the "IP Embargo" tab. (The tab only displays to staff authorized to manage embargoes.) You will get the Set Embargo form:

SetIPEmbargo.png

IP address range list: Select the named range of IP addresses that should be allowed access to this object.

Expiry: Set this to the date the embargo should automatically expire. If the embargo should never expire automatically, click the checkbox “Never expire” The Expiry date displayed will not change from the default (today’s date) but the actual embargo will be set to indefinite.

Click “Set Embargo”.


Embargo quirks as of Islandora 7.x-2.1

When an embargo is placed successfully, the system does not respond with a message, it simply redisplays the embargo screen.

If you click “Set Embargo” without supplying the name of an IP address range, a long error message is produced. This can be ignored -- go back to the embargo screen and supply the IP range name.

Note that lower levels in an object hierarchy do not inherit an embargo placed at a higher level. That is, an embargo of a Book at the title level does not embargo each page of the book; the pages can be retrieved by full text searches and viewed. Similarly, an embargo of a newspaper at the title level does not embargo issues or pages, and an embargo placed at the issue level does not embargo pages.


Changing or Removing an embargo

You can use the same form to change a previously set IP range or expiry date. To remove an embargo completely, select the blank entry from “IP Address Range List”.

Personal tools