Skip to content

For Administrators#

Guidelines#

B2SHARE is designed to be easy to use and currently supports access restrictions, registration of PIDs for any uploaded data object or file, additions of checksums and transition of all metadata information to the EUDAT metadata search. Importantly, B2SHARE enforces the inclusion of metadata accompanying the deposited data, so as to increase the value and facilitate sharing of your assets. Metadata is defined in metadata schemas and includes default mandatory fields as well as fields defined by the community under which the deposit is made. As a default, uploaded materials are published with Open Access. Although access can be restricted at the time of upload, EUDAT strongly encourages Open Access to research data in accordance with the policy of the European Commission. B2SHARE hosts a tool to help the user choose the correct licence for their data.

How to access the B2SHARE service#

B2SHARE is available from the following URL: https://b2share.eudat.eu.

Communities#

B2SHARE enforces the grouping of dataset publications and users through communities. Communities act as an organisation within the service to contain the datasets of a specific European community’s researchers and their members and to regulate publications through various policies.

Communities are easily identified on the landing pages of dataset publications in B2SHARE which provide a link to the community landing page itself. This landing page provides an overview of the community, the latest publications and the community metadata schema.

Metadata schema#

A community can define its own metadata schema fields on top of the default metadata schema defined by B2SHARE. This way a community is able to enforce any researcher that publishes data under that community to include additional information about the dataset uploaded.

Policies#

Community policies enable a community to limit the access for users and enforce workflows. Policies can be changed at all times, but modifications to communities must be done by the B2SHARE administrators. Please contact EUDAT through the webform if your community wants to make changes.

Currently the following community policies are supported:

  • Members-only dataset publications A community can make sure that only members of that community within B2SHARE can create new deposits that will be part of the community. This ensures that a select group of users is able to publish new datasets and enables for example data stewardship workflows. If this policy is disabled all users of a B2SHARE instance are able to publish under that community. For example, the EUDAT community is open to any user.
  • Publication review workflows If required, a community can enable the publication review workflow to include a quality control step before a dataset becomes publicly findable after submitting it. If enabled, the community administrator(s) will be able to approve a publication based on its current metadata and included files. If declined, the original creator of the publication can make edits and resubmit it.

Known issues#

Although the review workflow policy can be enabled, it is currently not fully implemented and therefore not supported. In future updates of B2SHARE this will become available.

Administration#

SuperAdministrator#

The superadministrator right allows a particular user to run any B2SHARE operation. Please be careful in assigning it.

To add and revoke the superadministrator right, check the specific CLI section.

Communities#

B2SHARE has special command-line interface (CLI) commands to create and edit communities. Check the CLI documentation for more details.

Steps to create a community:#

  1. Create a comunity schema. You can fetch and existing schema (CLI commands) and adapt it according to the rules of json_schema.
  2. Create a community. You will need a logo and the json schema. (Instructions
  3. Add community admin to the community.

Community Admin#

Each B2SHARE record is assigned to a community. A community administrator has certain special rights, like the right to edit a published record’s metadata and the right to add members to the community.

To assign the community administrator role for a user, do the following:

  1. Check already existing roles in the application 
    b2share roles list
  2. Check if our target community already exists 
    curl -sk https://${TARGET_FQDN}/api/communities/ | jq -r '.hits.hits[] | select (.name=="'${COMMUNITY}'")'
    where ${TARGET_FQDN} is the fully qualified domain name from the b2share instance.
  3. Get the admin role “name” 
    admin_role_name=$(curl -sk https://${TARGET_FQDN}/api/communities/ | jq -r '.hits.hits[] | select (.name=="'${COMMUNITY}'") | .roles.admin.name')
  4. Add role to existing user 
    b2share roles add ${USER_EMAIL} ${admin_role_name}

Alternative way:

  1. Find the unique ID of the community, using the HTTP API, by going to https://${TARGET_FQDN}/api/communities (for example, the community id can be 8d963a295e19492b8cfe97da4f54fad2). The administrator role for this community will be com:COMMUNITY_ID:admin (please use the actual community id between colons).

  2. Run the following b2share command: 

     b2share roles add <email_address_of_user> com:COMMUNITY_ID:admin
    For more information, check the dedicated CLI section.

How to enable members-only dataset publications#

In order to enable members-only community to use the community medatada schema to create draft and to publish record, you need to enable the “restricted_submission” policy.

Using the B2share-CLI commands:

  1. Enable the policy: 
    b2share communities policies set COMMUNITY_ID restricted_submission
  2. A community admin, can add members to the community from the admin page

If a user try to create a record using a restricted_submission community in which they are not a member, an error message will be displayed on the page: “Error: You don’t have the permission to access the requested resource. It is either read-protected or not readable by the server.”

More examples can be found in the B2SHARE-Training github repository.

Fine-grained access controls#

Warning: Please only run the following commands if instructed to do so by a B2SHARE representative:

  1. Allow the community administrator role to update record metadata (this is enabled by default when a community is created): 
    b2share access allow -r com:COMMUNITY_ID:admin update-record-metadata -a '{"community":"COMMUNITY_ID_WITH_DASHES"}'
    For example: 
    b2share access allow -r com:8d963a295e19492b8cfe97da4f54fad2:admin update-record-metadata -a '{"community":"8d963a29-5e19-492b-8cfe-97da4f54fad2"}'

Records#

Delete a published Record#

The Command Line Interface is currently missing a way to delete a record while leaving a tombstone. This will be fixed shortly but in the mean time here is how to delete a record. Note that the following method just marks the record as deleted, it still keeps it in the database just in case we want to revert the deletion. If a user access the record page after that he will see a 410 Gone error code meaning that a record existed before but was deleted.

First go to the page of the record you want to delete. Look at the URL, it should have the form https://<B2SHARE_HOST>/records/<RECORD_PID>, where <RECORD_PID> is a UUID. Note this UUID, it is the persistent identifier of this record, we will need it later.

Next we open the b2share shell. This shell executes python code as B2SHARE. Be careful as any action is performed directly on the database. 

b2share shell
In the shell we will start by retrieving the record using the persistent identifier. 
>>> from invenio_pidstore.models import PersistentIdentifier
>>> from invenio_records_files.api import Record
>>> pid = PersistentIdentifier.get('b2rec', '<RECORD_PID>')
>>> record = Record.get_record(pid.object_uuid)
Where <RECORD_PID> should be replaced with the record persistent identifier.

Now we retrieve all the other persistent identifiers attached to that record 

>>> pids = PersistentIdentifier.query.filter_by(object_type='rec', object_uuid=pid.object_uuid).all()
Now we mark the record as deleted. 
>>> record.delete()
We also need to mark all the persistent identifier as deleted so that the proper error message is returned to users. As this is python code you must keep the indentation as shown bellow. 
>>> for pid in pids:
...     pid.unassign()
...     pid.delete()
Finally we commit our changes to the database. 
>>> from invenio_db import db
>>> db.session.commit()
If you go the record webpage you should now see the 410 error message.

Note that we didn’t delete the deposit. Everything is kept in the database and can be reverted if need be. The files are not removed either.

Upgrade B2SHARE#

From version 2.1.0 on, B2SHARE can be upgraded by running 

b2share upgrade run

Support#

Please visit our training site on GitHub for B2SHARE and other hands-on training material.

Our B2SHARE presentations offer training material for the service.

Support for B2SHARE is available via the EUDAT ticketing system through the webform.

If you have comments on this page, please submit them through the EUDAT support request system.

  Last review : 29.1.2025