Skip to Main Content

Figshare for Institutions Admin User Guide: Home

Admin functionality for Figshare for Institutions.

Guide description

Welcome to Figshare for Institutions

 

Figshare is a place to make all research outputs citable, shareable, and discoverable. Use it to share supplementary research, papers, theses, special collections, conference outputs, open educational resources, and more.

This LibGuide will cover the administrative features and functionality of Figshare, including reviewing items, reporting on usage, impersonating users, setting custom metadata fields, unpublishing items, and more.

 

For more guidance on using Figshare as an end user, please visit https://knowledge.figshare.com.

What is Figshare?

What is Figshare?

 

Figshare is a place to make all your research data citable, shareable, and discoverable. Use it to share your supplementary research to make them first class outputs. Share both positive and negative results and get credit for all your research.

A few of the features of Figshare include the following.

  • Your research is assigned a DOI (Digital Object Identifier). This means you can cite it as a research output alongside your paper or as a freestanding piece of data.
  • Figshare complies with funder mandates around making data openly accessible and storing it in perpetuity.
  • You can use Figshare to make your data private or share it with the world by making it public.
  • Data that is uploaded to Figshare is marked for indexing in Google Scholar and Google Dataset Search. This helps improve the exposure of your research.
  • We track usage statistics, including views, downloads, citations, and Altmetrics.

For more information, you can find us at:

website: www.figshare.com

twitter: @figshare

general enquiries: support@figshare.com 

support site: support.figshare.com

knowledge portal: knowledge.figshare.com

Stage vs production

Stage vs production

 

Figshare will always provide a stage environment (where you can do your acceptance testing) and a production environment. Your stage environment will be on a figsh.com domain and the production environment will be on a figshare.com or a custom domain. Your implementation manager will share your stage domain with you during implementation.

 

Fundamentally, the two environments are configured the same way. The only difference is that the stage environment is updated frequently with features that will reach production at the end of a production release. This is so they can be tested and you can become familiar with them ahead of the production release. Please feel free to use your stage environment to test any of the features listed in these guides.

 

Items, collections, and projects published on the stage environment are live on the web. However, they are not indexed on Google. Every stage environment is protected by an HTTP gateway.

 

When accessing your stage environment, your browser will prompt you for a username and password, as requested by the gateway. The credentials will be provided to you during implementation. If you save it in the browser history you will not be prompted to save it again.

 

Please note: Any items uploaded to your stage environment will not be transferred to production for go live.

 

Groups

Groups

 

The groups display is available to administrators. In order to get to the administration settings, click on the profile drop-down menu and select Administration.

 

The first page you’ll see is the group structure page. This will give you an overview of the group structure at your institution. From this page, you can see how many users are in each group, the number of group projects in each group, and the amount of storage allocated to each group.

 

This page allows different levels of search and filters. An administrator can sort groups by name, number of projects, allocated quota, or available quota. The search term can be combined with the sorting options. Navigating between tabs will keep search and ordering results.

 

The Users column presents the users assigned to that group in total (including inherited from subgroups) and number of users associated strictly to that group. 

 

In the image below, 85 users are associated in total under the Faculty of Aeronautical, Automotive, Materials Engineering. Out of those 85, 80 are directly associated to this group and the other 5 are inherited from the structure below: 1 from Chemical Engineering, 2 from Group Aeronautical, and 2 from Materials. 

 

 

The Projects column counts the group projects associated directly to that group. These are the projects that have the type set to group rather than individual. 

 

In the Storage column, the user can see the quota that has been allocated to subgroups or to projects associated to that group. The first figure represents how much storage was allocated (either down to subgroups or to projects connected here) out of the total available. The last number represents the total storage of this group. The total storage is the value configured when creating the group in the attribute called total quota for projects. These figures do not show how much of the groups’ storage has been used. Usage only makes sense in the context of an account or a group project. This filter can be amended to show allocated storage, available storage, and total storage.

 

To configure groups, use the cog to the right of the group name to access the configuration page.

 

 

The description is presented on the screen as a text area, where an admin can add up to 1,000 characters. This will be displayed on the portal when clicking on the subgroup’s icon.

The public URL will be prefilled with the institution URL and cannot be amended. To amend the URL for any subgroups, please 
submit a support ticket.

 

Creating subgroups

Any administrator, group admin or group owner can create groups. 

 

In order to create a new group, navigate to the group structure page. Select the group to be the parent of your new subgroup, go to the cog wheel and select Create subgroup.

The only attributes mandatory for a group are Title and the quota, called Total quota for projects
The title must be unique in the institution, and can contain special characters. The description is presented in the screen as a text area, where an admin can add up to 1,000 characters. This will be displayed on the portal when clicking on the subgroup’s icon. The public URL will be pre-filled with the institution URL followed by the title of the group. If the title has more than one word, then the alias in the URL will contain an underscore.

If the administrator chooses to make the group public, then the URL cannot be edited. 

 

Please note: The group will become public and will have a portal page only if this flag is set and there is public content to be displayed.

 

Storage

Storage

 

To access your storage allocation, click on Administration from the administrator menu. On the groups tab, click the cog wheel next to the group whose storage you want to access. Storage is accessible in the middle of the configuration page.

 

The administrator can divide the overall institution storage between users and projects (group projects only). We have chosen to use the term project instead of group because the storage is used only for uploading data into projects connected to groups. This means that, even if quota is allocated to groups, it can only be used (consumed) by the content uploaded in group projects.

 

Administrators can either use a slider to divide quota or define it manually. When the quota division is done by using the slider, the number of TB/GB/MB from the text box is also updated. When the quota is divided by using the text box, the slider will be automatically repositioned to indicate the change. The percentage will also be updated. The scale of the slider will be configured based on the amount of space purchased by the institution. For example, if the institution configures a large amount of storage, then an allocation in MB will not be visible on the slider. 

 

New storage distribution allows administrators to divide another chunk of quota added on top of the existing one once your portal is live. When selecting evenly, the segment above will represent the new value. The percentage will not change, but the absolute value in the text box will be modified. Both users’ and projects' quota values will increase with the same amount of space equal to the amount bought divided by two.

 

If the selected value is fixed for projects, then all extra quota will be allocated to projects. In this case, the slider will be moved to the left; the percentage for the user quota will be decreased but the value will remain fixed. The project's quota will increase, as well as the percentage. If the selected value is fixed for users, then all extra quota will go to users. In this case, the slider will be moved to the right; the percentage for the projects quota will be decreased but the value will remain fixed. The user's quota will increase as well as the percentage.

 

The initial quota per user setting is the value given to any user in the institution by default at account creation. If the user quota is handled via the HR feed, then this value will be disregarded. If the administrator modifies this value, the change will apply only to created users. 

 

The initial quota per project parameter is an optional attribute that can be set at the creation of a subgroup or edited later. It represents the initial quota allocated to each project within this group. If this figure is modified at creation, then all projects associated to the group will have this quota by default. If this parameter is modified later, in the configure group screen, then only new projects will be affected by this modification.

 

The HR feed administrator section is only applicable for institutions that are using an HR feed for creating accounts. Administrators can define the association criteria on every group, but they can also define it at institution level for all groups. 

 

Virtual storage

We can apply a virtual storage to your instance of Figshare. This means that the value of your storage allocation can be higher than the actual amount available to your institution. 

 

The reason we define a virtual quota is to allow an institution greater flexibility, especially in the initial stages of the implementation when it is very difficult to guess the actual usage. 

 

After a period of time, when we can observe a usage pattern, we can reconfigure the quota for the entire institution or the allocation between users and projects. 

 

For example, if your institution has 100 active users and you would like to start with allocating 100 GB for every user, we will need to configure the total virtual quota by multiplying 100 GB by 100 users. Then, we will need to approximate the number of projects per group, if any, and the amount they will need in general. By doing these approximations, we will be able to add the 2 values and come up with a total “virtual storage” for the institution.

 

In general, we have observed that institutions tend to divide their virtual storage 80/20 between users and projects. With the help of the reporting module, administrators will be able to keep an eye on the actual usage and adjust the virtual storage when needed. Institutions will only be charged for the used storage and not for the virtual storage.

 

Custom metadata

Custom metadata

 

To create custom metadata fields, click on Administration from the administrator menu. On the groups tab, click the cog wheel next to the group to which you want to add custom metadata and click Configure. The option to add custom metadata will be at the bottom of the configuration page.

 

 

 

 

Custom metadata defined at the institution level will be applicable for all items, collections, and projects created within the institution context. These metadata will be inherited by all the subgroups and cannot be modified at that subgroup level. 

 

These metadata will be visible on all entities within the institution, on items, collections and projects. The institution level metadata will be displayed on both type of projects. 

 

Please make sure that the metadata defined at the institution is applicable for all your groups before marking it as mandatory. 

 

When defining custom metadata, administrators can:

  • Select the correct Label (field name) to be displayed both privately and publicly. The label can have up to 100 characters.

  • Choose if the custom metadata is Optional or Mandatory 

  • Select the Context for this field: items, collections, and projects. The admin can select any combination of those values. 

  • Select the Type of metadata field you want to configure: simple text field, text area, predefined drop down menu, email, url, date selector, or dropdown (large list)

  • Select help texts to be displayed on the tips section on the item edit

  • Add Placeholder text or default values, based on selected field type

  • Configure validations, depending on the type of field, like character limit. 

 

You can duplicate or delete a metadata field by using the cog. 

 

If the metadata is deleted, this will impact all users that have used the metadata field. Please be very careful when deleting defined metadata attributes. 

 

If there are public items that use this attribute, then the users will not be able to see this field anymore. Public items will not be impacted unless the user goes to My data and modifies the item. At this point, the old public version will be overwritten and the custom metadata fields will not be visible anymore.

 

Dropdown (large list) field type: This field type enables the upload of a large controlled vocabulary via a CSV upload. At this time, the upload needs to occur through the API documentation interface and is relatively straightforward.

  1. Create the custom field in the top level group or one of the subgroups in your repository
  2. Create a private token for your administrator account and paste that token in the box at the upper left part of the documentation page: https://docs.figshare.com
  3. Use this endpoint to see a list of Groups and copy the id for the group where you created the custom field: https://docs.figshare.com/#private_institution_groups_list
  4. Paste the id into the entry field at this endpoint to see a list of custom fields in that group: https://docs.figshare.com/#custom_fields_list
  5. Copy the id for the custom field you created
  6. Paste that id into this endpoint and upload the CSV that contains your controlled vocabulary: https://docs.figshare.com/#custom_fields_upload

 

 

 

Roles (administrators, reviewers, and reporters)

Roles (administrators, reviewers, and reporters)

 

We have several different administrative roles (each role having a subset of permissions) within Figshare for Institutions; an overview of these can be seen below followed by a guide on how to assign them within your portal. 

 

Apart from administrative roles, Figshare has a default role, called the user role, that allows any user to perform basic actions like creating items, collection, and projects, uploading files, and publishing items. This is the role given to any account created. We can tailor the role to remove permissions, such as creating collections, or we can add the ability to select which group items created by the user should be affiliated with.

An account can have as many roles as needed. 

Institutional administrator (displayed as Administrator in the role drop down): This role is given to all "administrators" configured at the top institution level. This role is not available on Edit group. The administrator can manage quota/storage for the entire institution, can manage quota request that are assigned to him and can create groups. The administrator has access to the reporting module (statistics dashboard) but also to the private stats page (OrganizationDomain.com/stats - see here for a public version of this page) if this is kept private. Administrators can modify the institution structure by creating or editing groups, impersonating accounts, downloading user reports and, if needed, unpublish public content. Administrators do not have access to the review (curation) module.

Institutional reporter (displayed as Reporter in the role drop down): this role has view only rights within the admin portal  and can see the private stats page. The reporter has access to the statistics dashboard.

Group owner (displayed as owner in the role drop down): this role will be attributed to the person that creates the group. A group can have only one owner at a time. If an owner is removed then another must be added. The group owner can edit the group’s details, create other groups, approve quota request assigned to them by the system. Every owner can impersonate the users assigned to their group(s).

Group admin (displayed as admin in the role dropdown): this role will be attributed to a person by the group owner, when the group is created or edited. The admin has similar permissions to the group owner, except deleting groups. 

Data steward: this role is available only for specific institutions on request. The Data steward is a type of group admin that cannot edit the group details, however they can manage quota request for users and projects associated to their managed groups. 

Embargo administrator: this role can be applied to any user within your organisation. This role can see the items that were created with an embargo on the whole item and files that have an Administration embargo, meaning they’re visible to embargo administrators. 

Institutional reviewer: this role is available only in the Configure institution page. The institutional curator can approve manage revision request from every group in the institution and can assign and deassign request from everyone. They can also edit all the metadata for the items sent in review and assigned to themselves. Institutional reviewers can add comments and send emails to submitting authors, for any of the pending/open requests visible to them.

Group reviewer (displayed as Reviewer in the role drop down): this role is available only in the Configure group page. The group reviewer can only manage requests coming within their group and subgroups below their managed groups. Group reviewers can only assign requests to themselves. They can also edit all the metadata for the items sent in review and assigned to themselves. Group reviewers can add comments and send emails to submitting authors for any of the pending/open requests visible to them.

Fellow: this role is part of the review module. It is designed to allow reviewers to perform an initial triage of new review requests before passing over to another reviewer. This role can see only requests assigned to them by actual reviewers. Upon opening a request, a user with the Fellow role can only see the files and metadata, in the same way as an actual reviewer but they cannot make any changes nor approve or decline the request. The only action they are allowed to do is post comments (internal only), and assign it to an actual reviewer; they cannot assign it to other fellows. The Fellow role does not receive any email notification when requests are assigned to them.

We currently have a constraint that the person given the fellow role cannot be a reviewer on any other group within the institution, because their permissions are mutually exclusive.

 

How to configure roles

If you have administrative rights for the institution (or a group), you will see an additional option called Administration in the menu in the top right. Select this option and you will see the groups that you have administrative rights over. To add a group level owner and/or admin click the cog under Actions for that group and select Configure.

 

Image of group administrative area in Figshare

 

You are now on the Configure group page. Scroll down and you’ll see a Define roles section.

 

Assigning a user roles within a group

In the example above, Alan Hammon is already set up as the group owner. You can remove him and add a different owner by clicking the x next to the user’s name. To add additional administrators for the group, select +Add more. Users can have more than one role. When you have finished, be sure to select Save configuration before leaving the page.

 

Managing end users

Managing end users

 

Information on users in your Figshare instance can be found on the Administration page under the Users tab at the top of the screen. From this page, you can see the names of all users within the system, the group structure they sit under, the number of projects they created, and the amount of storage allocated to their account. Users marked as inactive are displayed in lighter grey and italics. These are users your institution has deactivated via the HR feed or whatever your system is for creating user accounts.

 

 

In the storage column, the first piece of information is the quota they have already used by uploading files in My data or in individual projects. The segment represents usage, while the last value is the quota they have been allocated with. That value is the same value the user will see in their my data.

 

Impersonating a user

Impersonating a user

 

Administrators can impersonate any user that falls under their group structure. Administrators at the institution level can impersonate any user, whereas administrators of groups can only impersonate any user within their group or subgroups.

Impersonations can be useful for:

  • Making amends to metadata
  • Uploading on behalf of an author so the item remains within the author’s account
  • Troubleshooting support

To impersonate a user (either active or inactive), go to the Users tab on the group structure page. Find the user you want to impersonate, go to the cog on the right hand side, and select Access this account.

 

The user administration window with a list of users

Please note: when an administrator impersonates a user, administrators are able to see confidential files. Therefore, if a file is highly confidential, we recommend uploading a metadata record only. For more on restricted items, please see our Knowledge Portal page on conditional items.

 

While accessing the account, all the actions performed by the administrator are added to the audit log. The actions are set as performed by the administrator. For example, if the administrator modifies an item, the user will see on the item overlay that the item was last edited by that administrator. In the example below, the original author is the one listed in the author list with green text, while the administrator, Team Figshare, is the one that last edited the item as seen at the top.

 

 

Approving/rejecting quota requests

Approving/rejecting quota requests

Users

A user’s quota can be updated in two ways:

  • Within the feed, if the institution is sending this value in there. Please check the feed guide to see how it’s done.

  • Within the application but only if the user requests it. Administrators cannot modify quota directly for a user, they can only approve or reject the user’s request.

To request more quota, the user needs to go in my data and request more from above the item table.

The request will go only to the administrators of the group where the user is assigned. This request will appear in the activity tab and will be visible in the header after the administrator logs in. The administrator can approve, decline, or configure the value that was requested if the value is not appropriate. If the requester is an administrator of the group they are assigned to, the request is automatically approved.

Projects

Group projects are projects that will have their storage allocated from a group. Anyone can create a group project by selecting a group from the drop down in the Allocate storage part of the create project page. After selecting the group, the user will see the default initial value allocated for his project. This value cannot be edited in this screen. 

Only the project owner can request more space from the project edit page. To approve, the administrator should follow the exact same steps as for the quota for users.

 

Unpublishing items

Unpublishing items

 

Administrators have the ability to unpublish items that have been made publicly available. While we don’t encourage unpublishing items that have been assigned DOIs, we understand this happens occasionally. 

 

Please note: only items can be unpublished. To unpublish projects or collections, please submit a support ticket

 

To unpublish an item, select the Unpublish tab from the group structure page under Administration. In the box, enter the item’s DOI and select Submit. As a result, the DOI will direct to a tombstone page where we will display the reason why the item was unpublished. An unpublished item is returned to the user’s My Data as a drafted item, allowing them to make changes if necessary and republish.

 

 

 

Reviewing items

Reviewing items

 

Reviewing is the act of approving or rejecting an item, with feedback, before it becomes publicly available. You can turn on reviewing in the Administration page by selecting the group you want reviewing turned on in (groups inherit reviewing so if you turn it on at the top level, all subgroups will have reviewing turned on, as well), selecting Configure, and scrolling

down to Administration. There, you will have the option to turn on reviewing.

 

The administrative section for a group showing the checkbox to enable the review process

 

How to approve or reject an item

All reviewing requests can be found in the reviewing pool from the reviewer account. All reviewers set either at the group level or institution level will receive both email notifications and will also have them listed in the reviewing pool. If you would like to receive reviewing requests for every subgroup at your institution, you will need to add yourself as a reviewer to each subgroup or you can simply set yourself as institutional reviewer. While you won't be displayed as a reviewer on every Edit group page, you will be an implicit reviewer there and you will receive all the requests.

 

If the user creates the item in My data, then the review request will go to the group the user is assigned to. If the user creates the item in a group project, then the reviewing request is sent to that group. 

 

Please note: when creating items in projects, it is important to remember that reviewing is connected at group level, so depending on the group you select to link the project to might or might not have reviewing turned on.

 

To view items for review, click on the dropdown menu and select Review requests.

 

You will then see all review requests that are open, whether they’ve been assigned to you or not. You can opt to view only your assigned requests and sort by newest or oldest first. The number you see in the menu displays unassigned, open requests. The number might be different to what you see when you enter the pool. By default, the pool shows all the requests even if they are assigned already, filtered by the group(s) you can review. If you know there are open review requests but you cannot see them, it means they must be assigned to groups that you cannot review. 

 

To process an item through review, select the item and assign it to yourself as the reviewer. The image below shows a situation where you are an institutional reviewer. As an institutional reviewer, you can assign the request to yourself but also to other reviewers that are assigned to the same group of the request. If you are a group reviewer, you can only assign the request to yourself.

 

 

Once an item is assigned to you, you can edit in situ, write a review, email the author, reject and decline from the reviewer area.

 

If there is mandatory metadata missing or if you simply want to change some of the metadata, please use the Save button from the Edit item tab before approving. If you do not save the changes, you will approve the previous version. 

 

You can filter items in the review interface based on whether they’re under review or have been approved, rejected, or archived. Just click Status in the top right and select the statuses you wish to apply. You can also add additional filters like reviewer and date created. You can also collapse filters after searching for them. 

 

For examples of review checklists from other institutions, please see here.

 

Item types

Item types

 

There is a default list of item types available for items created in Figshare. There are also non-default item types that can be added to your instance. To add these non-default item types, please raise a support ticket.

 

The below list also indicates which item types are indexed by Google Scholar, Google Dataset Search, and Google Book Search.

 

Figshare Item Type

Default

Indexed by

Description

Figure

Yes

Figures are generally photos, graphs and static images that would be represented in traditional pdf publications.

Media

Yes

Media is any form of research output that is recorded and played. This is most commonly video, but can be audio or 3D representations.

Dataset

Yes

Google Dataset Search

Datasets usually provide raw data for analysis. This raw data often comes in spreadsheet form, but can be any collection of data, on which analysis can be performed.

Poster

Yes

Scholar

Poster sessions are particularly prominent at academic conferences. Posters are usually one frame of a powerpoint (or similar) presentation and are represented at full resolution to make them zoomable.

Journal contribution

Yes

Scholar

Any type of content formally published in an academic journal, usually following a peer-review process.

Conference contribution

Yes

Scholar

Any type of content contributed to an academic conference, such as papers, presentations, lectures or proceedings.

Preprint

Yes

Scholar

Preprints are manuscripts made publicly available before they have been submitted for formal peer review and publication. They might contain new research findings or data. Preprints can be a draft or final version of an authors' research but must not have been accepted for publication at the time of submission.

Presentation

Yes

Scholar

Academic presentations can be uploaded in their original slide format. Presentations are usually represented as slide decks. Videos of presentations can be uploaded as media.

Thesis

Yes

Scholar

In order to distinguish essays and pre-prints from academic theses, we have a separate category. These are often much longer text based documents than a paper.

Software

Yes

Code as a research output can either be uploaded directly from your computer or through the code management system GitHub. Versioning of code repositories is supported.

Book

Yes

Google Book Search (+Scholar)

Books are generally long-form documents, a specialist work of writing that contains multiple chapters or a detailed written study.

Online resource

Yes

Any type of resource available online.

Chapter

No

Scholar

Division of a book, which in a scholarly context usually treats a part of a larger subject in a stand-alone manner.

Peer review

No

The evaluation of a scholarly work, usually performed before formal publication by a number of field experts.

Educational resource

No

Any type of content useful for teaching, learning or research in an educational context.

Report

No

Scholar

A formal account of an observation, investigation, finding, activity or any other type of information. 

Standard

No

A formal and detailed description of an invention, protocol or workflow; examples include patents, patent applications and requests for comments (RFC).

Composition

No

A creative work in a fine art context, such as a piece of music or a poem.

Collection

No

Funding

No

A resource describing various aspects related to the funding of a research venture, such as funding agency, amount, grant name or recipient. 

Physical object

No

A record describing any type of physical object, such as a work of art, instrument or archaeological artefact.

Data management plan

No

Data management plans are an integral part of a research venture, describing what data will be collected or created and how, and also the means by which it will be shared and preserved.

Workflow

No

Resource describing protocols, procedures, methods or activities part of a scientific experiment.

Monograph

No

Google Book Search (+Scholar)

A non-serial scholarly publication (either one or multiple finite volumes).

Performance

No

The presentation of a theatrical play or music concert within a fine art context.

Event 

No

Information on the purpose, location, duration, agents or effects of an occurrence such as a conference, performance, natural phenomenon, or conflagration.

Service

No

A system supplying a research need, such as a facility, instrument or API. 

Model

No

A formal representation of any system, entity, phenomenon or structure useful in the research endeavour.

Statistics dashboard

Statistics

 

If you’re interested in information about views, downloads, citations, storage quota used, storage quota remaining, regional information about views, top viewed, top downloaded, etc., this information is available in a private dashboard available only to administrators and reporters at the institution. This can be found by selecting the dropdown menu in the top right, and clicking on Statistics.

 

Please note, the statistics dashboard only works on your production environment as we don’t track usage metrics on your stage environment.

  

This dashboard is powered by Kibana, a platform to display statistics in a visual, interactive way. This will allow you to run reports on demand, access information on a variety of fields, and visualize it in a more presentable way. The widgets in the dashboard can be customized based on your needs. All reports within the widgets are exportable in raw or formatted versions by selecting the downward facing arrow. These export as CSV files.

 

You can select the time frame in which the reports are run by clicking the arrow next to Last 90 Days at the top of the page. You can choose a quick view, a relative view or an absolute view.

 

If there are any reports that you and your organization would benefit from seeing regularly, please let us know via support and we’d be happy to add it.

 

There is also an optional public-facing statistics page available at yourinstitution.figshare.com/stats. This shows high-level information on views and downloads which is filterable by author, subgroup, and date. To turn this page on or off, please submit a support ticket.

We can also report on user information such as storage assigned, number of public items, number of private items, etc. Select the users you need in the report and select Download user report at the bottom of the page to download an Excel file of the user report. If you need only users associate to some groups, select that group in the top drop down then select all users from the table header. You can also use the checkboxes to filter only the users you are interested in. The parameters we report on in the user report can be found here.

 

Restricted Publishing

Embargoes and Restricted Access

 

Introduction

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 the standard embargo functionality, which allows you to restrict content, but does not give you the option to have it available for selected audiences. 

 

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 support@figshare.com. Once enabled, a number of restricted publishing options become available to you in the user interface as shown in the image below.

 

If enabled, the restricted access option is visible on the metadata entry form in the top right area.

Screenshot of the metadata entry form with the embargo and restricted access link indicated with a red box


 

Clicking on the 'Embargo and restricted access' link opens a popup with multiple options depending on what you've requested from Support. These options include

  • Nobody (this is the default)
  • Custom
    • Logged in users or logged in users assigned to one or many groups
    • IP range/ranges
    • Administrative publishing

 

In the image below all options are available.

Screenshot of restricted access options

 

Administrative publishing 

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. 

 

 

IP restrictions
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 (support@figshare.com) 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. 

 

Combining options 

 

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.

 

Request access

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:

  • Press this button
  • See the contextual information added by the uploader
  • Change their correspondence email address if needed
  • Add a message

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 support@figshare.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.

 

Set-up

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 support@figshare.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:

 

Screenshot of what an end user might see for restricted access

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).

Screenshot of what an end user might see for restricted access

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 support@figshare.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.