Restricted publishing allows for the publication of files and metadata in various permutations to a variety of different audiences. Restricted publishing is an addition to our current embargo functionality, which at the moment allows you to hide content, but does not give you the option to have it available for selected audiences.
Changes to confidential files
As this is an entirely optional feature, let’s first discuss the changes to your repository if you choose to not add restricted publishing functionality to your instance of Figshare for Institutions.
The embargo area now merges the old embargo and confidential sections to introduce ‘permanent embargo’ as an option for making files not publicly available indefinitely.
All your items that had confidentiality on files have been automatically migrated to permanent embargo.
Options for restricted publishing configurations
As we currently have no administrative page to allow the self-serve of enabling or disabling restricted publishing, all initial setup must be done via email@example.com. Once enabled, a number of restricted publishing options become available to you in the user interface as shown in the image below.
Logged in users or logged in users of one or many groups
We are not removing the option to have the files and/or files and metadata fully hidden. If you enable any of the restricted publishing options you will still be able to use the current option, by selecting Nobody in the “Who can access the embargoed content “ area.
This publishes an object so that the public item’s metadata and/or its files are available only to designated people from within your institution who have a specific permission attached to their role.
With this configuration, you can restrict access to certain individuals within your institution only. The embargoed content, files and/or metadata, will be visible on public pages like the browse page or the portal only to the person that has the new permission, which we have assigned to a new role: Embargo Administrator. You can assign this new role to your existing Administrator or Reviewer or any person suitable. However, this permission won’t be part of the existing roles by default, so the Administrator or Reviewer won’t see the content without having the newer role also assigned.
Please note: the item owner themselves will not be able to see the public object. Objects go through the normal review processes, assuming your institution has the review turned option on.
This is a great option for CRIS/RIM systems and other interoperability use cases, as well as some very specific embargo scenarios.
Logged in users of my institution and/or logged in users of a group(s)
These two options can only be enabled together in the initial setup. They give you the option to publish the files or files and metadata so they are available to all logged in users or to users assigned to specific group(s).
If you select a specific group, then this means that only users associated with that group (by your HR system or at first log in) will see the items on the portal where they are “published”.
The group of the item does not need to be the same as the group of users selected to see the embargoed content. The groups list will show all available groups within the institution and cannot be customised to only show specific groups. This is not just the list of groups that the person setting the embargo is associated with, but all groups. If your institution does not have users assigned to groups, and all are assigned at top level, this setting won’t display the hidden content to anyone.
This option is great for teaching materials, institutionally-purchased datasets, etc.
To start, let’s look at three concepts to help understand this easier:
IP address - A single fixed address
IP range - A band containing a variety of IP addresses. Should be provided ideally utilising CIDR notation
IP Label - Figshare nomenclature to describe the presented option to the user when selecting IP range restrictions. An IP label can contain one or many IP ranges and/or IP addresses
When defining IP restrictions, the options available to the user will be IP labels and the naming can be defined by the Figshare support and implementation team (firstname.lastname@example.org) based on your request. You can have one or many IP labels.
Each label can define one range or a set of ranges. For example if you have several campuses and each has their own IP range you can define them separately, to allow you the ability to restrict access only to one of the campuses or you can group them together and each time you restrict to the “campus” label everyone from all the several campuses can see the data.
This will allow the files or the files and metadata to be hidden from audiences not specified by the selection. This use case is great for theses, external auditing, campus-specific data etc.
If you enable both logged in users and IP ranges, you can select both options for an item. With this configuration, users need to be either within the configured IP range(s) or logged in but do not have to be both.
With the current setup, you can combine the options under the CUSTOM option (IP range(s) and logged users) but you cannot combine the options you find under CUSTOM with the Administration option.
As we currently have no administrative page to allow the self-serve of enabling or disabling this setup, all initial setup must be done via email@example.com. You can choose to enable these options at an institutional level or only at a group level. Group level options do not cascade, so all individual groups you wish to apply this to must be specified. You can also choose to enable only some of them. To help understand this, here’s a few examples of setups:
Enable at an institutional level so all of my users have access to these options the following set-up: administrative publishing, logged in users of my institution and/or groups
Enable to the theses group only the ability to publish to IP range only
All options can be applied to files only or files and metadata, dependent on usage requirements. All three options can be added independently in the initial set up, so you could choose only administrative, or only logged in, or only IP, or a combination of all three.
Who can use the feature?
You can set up this feature either at the top institution level, so all your users can use the restrictions you define, or you can set it up for one or more groups only.
If, for example, you turn this option on for one of the groups in your hierarchy, then all other users will continue using embargo as is (with the modification mentioned above) and only those users from the selected group can allow access of their restricted content to a selected audience.
If you decide to configure this feature only to a group, then users that belong to that group can create items and set embargoes but allow access to their items for all logged users or to users from a specific group (which does not need to be the group they are affiliated to).
You might want to have this feature on for the library department for example, and they can publish different materials available for your students, by selecting the correct department for each of the materials.
If you want to turn the feature on a per group basis, you will be able to define a different configuration for each group.
Options that restricted publishing won’t allow
With restricted publishing, you can give access to a selected audience (based on the 3 options explained above) to the restricted content.
You cannot combine the options from Custom with the restriction to Administration. On top of that, you cannot define multiple restrictions on a single item. For example you cannot say metadata is restricted to logged users and files can also be seen by the Embargo Administrators.
Impacts on other areas of the system
Restricted publishing impacts many areas of the system. Public items will be marked up so users know that if they share it, other users may not see the same as you. This is shown under the title:
We will also have an indicator on the browse/portal page, but this will be coming at a later date.
Restricted publishing status will also be displayed in curation (although not editable at this stage; that will require impersonation).
Impact on identifiers
If you use the whole item embargo and do not provide us with details of your handle server or choose to use ours, this will block the publication of these objects. If your institution will be configuring these options, please email firstname.lastname@example.org to make sure we configure handles correctly for you.
The specific situation in which a handle is needed is if you want your whole item (files and metadata) to remain hidden (embargoed), and only visible for a limited group of people, then this item will have a handle. If the embargo is removed or it expires and the item goes fully public it would continue to have a handle. Figshare would not mint a DOI upon full publication.
The options that require a handle are: full item embargo where only logged users can see the files, full item embargo where only users within an IP range can see the file, or full item embargoes shared only with administrative users.