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.
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.
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.
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 Institutional Administrators and 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 Institutional Administrators and Embargo Administrators (a new role designed to allow certain individuals with this role assigned to see embargoed content). You can assign this new role to your existing Group Administrator or Reviewer or any person suitable. However, this permission won’t be part of the existing roles by default, so the Group 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:
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.
This functionality allows users to add a “Request access to these files” button to embargoed objects. Uploaders can add some context that will be displayed to anyone requesting these files. Logged in users viewing the embargoed item can then:
This will then prompt an email to the uploader and any institutional administrators. How those objects are then shared must be handled in a separate workflow. You can share a private link, but there is currently no new functionality added to private links to restrict access. When enabled, it will be for all your users.
This functionality is optional. To enable this, please email email@example.com.
Option to hide restricted access at the group level
If the restricted publishing option “Share to logged in users” was enabled for your institution, then all groups within your institution were also displayed via a flat hierarchy drop down list. Sharing to any particular group within that list would allow users assigned to that group and that group only (no cascading rights) to have access to the restricted object. This new functionality allows you to remove all groups entirely or specific groups from this restricted access dropdown. You can do this by going to the configuration page of the top level institutional group or the specific group you wish to remove and checking the box.
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 firstname.lastname@example.org. 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.
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).
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 email@example.com 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.
Can’t find your answer here, check the community discussion or raise a support ticket.
Share this article: