Administration

The admin dashboard provides aggregated usage statistics. It is available only to members of the SRAM group named by ADMIN_ROLE, matched exactly against the group URNs SRAM reports at sign-in; it does not appear in the navigation for other users. The hosted hub uses the metaseed-admin group of the metaseed collaboration, urn:mace:surf.nl:sram:group:tudelft:metaseed:metaseed-admin; the development Keycloak defines the same group.

Open it at /hub/admin/.

What the dashboard shows

Section	Contents
System Overview	Total active users and total datasets
Activity (Last 30 Days)	Daily counts of user registrations and dataset creations
User Directory	Registered users with email, display name, registration date, dataset count, and last sign-in

The dashboard reports aggregated counts and directory information only; it does not expose the contents of users' datasets.

Datasets per user

The Datasets column counts the datasets in that user's own account, excluding deleted ones. Every user gets a account of their own on first sign-in, and that account is what owns a dataset, so this is the count of datasets the user created rather than of datasets they can see. A dataset shared with them belongs to the account of whoever created it and is counted there.

Specifications per user

The Specs column counts the published specifications that user authored, wherever they live. Authorship rather than account, because the two can differ: publishing a draft shared from another account puts the specification in that account while recording the publisher as its author.

Withdrawn and unpublished specifications are excluded, so the column reports what is actually published.

The Last sign-in column records when the user last completed the sign-in flow, not their last request. It is written once per sign-in, so an active session that has run for days still shows the sign-in that started it, and a user who stays signed in shows an older date than their real activity.

Users who registered before this column existed show Never until their next sign-in. That is a gap in the record, not evidence that they have not used the hub.

Errors

The Errors section lists unhandled server errors, newest first, with the time, the request that failed, the exception type and message, and the signed-in user who hit it. A per-day count above the list makes a spike visible without reading every row. The list fits the page: the time never wraps, a request path and a message wrap inside their columns, and a message longer than a few lines is folded to its first 200 characters with the rest a click away, so a database error carrying its SQL does not push the table off the screen.

These are recorded in the database rather than read from the host's journal, for two reasons: the application runs several worker processes that log separately, and the dashboard has no privilege to read the journal. A stored row also survives a restart.

Only the exception type and message are kept — never request bodies or headers — so the list does not accumulate a copy of users' data. Messages longer than 2000 characters are truncated. The user column is empty when the caller was not identified, and becomes empty if that account is later deleted; the error itself is kept.

Administrators are told of new errors through the notification bell. An error is notified when no error of the same exception type on the same path was recorded in the hour before it, so a failure that repeats produces one notification per hour rather than one per request; every occurrence is still listed here. An administrator is anyone whose collaboration membership, recorded at their last sign-in, includes the admin group, so someone who has not signed in since joining it, or whose reading has gone stale, is not notified until they sign in again. Clicking the notification opens the Errors tab.

Records are removed automatically 30 days after they occur. Recording never interferes with the error itself: the exception propagates unchanged, so the usual 500 response and the log line are exactly as before, and a failure to record is logged rather than raised.

Removing a dataset or specification

An administrator can remove a dataset or a published specification belonging to any user, for content published or created by mistake, or on request from the person who owns it.

Removal is by identifier, not by browsing. The dashboard reports aggregated counts and does not list other people's content, and a removal tool that showed every dataset in the deployment would undo that. An administrator acting on a report is given the identifier; paste it into the Remove content form on the dashboard and choose whether it names a dataset or a specification.

The identifier is the UUID in the URL of the item. For a dataset that is /hub/datasets/<id>; for a published specification, /hub/spec-builder/spec/<id>.

What removal does:

The item is soft-deleted. It disappears from its owner's account, from the Explorer, and from the profile choices offered for new datasets, exactly as if the owner had deleted it.
Nothing is erased. The row stays in the database with the time of removal, so an administrator can still account for what existed.
The response names what was removed — the item's name and the email of the account that owned it — so a mistyped identifier is visible immediately rather than silently removing the wrong thing.

A removal can be undone with Restore, using the same identifier. This is the reason removal is a soft delete: an identifier is easy to get wrong, and an irreversible admin action on someone else's data is not. A specification cannot be restored while its owner has published the same name and version again since the removal; the response says so, and the newer publication stays.

Removing a specification does not affect datasets already created against it. Those carry their own copy and continue to open and validate; the specification simply can no longer be chosen for new datasets.

Security warnings

If the application is running with the default development SECRET_KEY, the dashboard shows a warning banner. Set a strong SECRET_KEY in the deployment environment to clear it; the secret is used to sign CSRF tokens.

Features and SRAM groups

The repository integrations are enabled per person through SRAM groups: importing from and exporting to ENA, PRIDE, BrAPI and MetaboLights, pushing to SEEK, and the DCAT export. A person may use one when they are in a group named after it, ena, pride, brapi, metabolights, seek or dcat, in any collaboration they are in: the application offers the group names, and each collaboration's admins decide who in their collaboration gets them. SRAM may report a group with a prefix ending in a hyphen: since a second collaboration was connected to the application (261013), the hosted hub receives metaseed-seek where the group is named seek. A group whose name is the feature, or ends in a hyphen followed by it, grants the feature; seeker and seek-old do not. This is deliberately the opposite of the admin rule above, which is the exact URN of one group and has to be updated in ADMIN_ROLE when SRAM changes it.

What a person is not granted they do not see: the repository's button on the From a repository tab, the import field of an empty dataset, the export button on a dataset, the SEEK entry in the header and everything under it. The server refuses the same requests, so a typed address does not get round the group. The membership read is the snapshot taken at sign-in, under the same limit as collaboration membership below, so a group granted in SRAM takes effect at the person's next sign-in.

Collaboration membership

The hub records each user's SRAM group membership at sign-in and trusts that record for MEMBERSHIP_MAX_AGE_DAYS (30 by default). A record older than that grants no access through a collaboration grant and lists nobody on Collaborations until the person signs in again. Lower it where membership changes often; raise it where people sign in rarely and rely on access tokens.

SRAM application tokens

Members of the collaborations connected to the Metaseed Hub application in SRAM can create application tokens there and present them to the REST API and the MCP endpoint (Connecting an agent). The hub checks each one against SRAM's introspection endpoint with a credential of its own.

To enable it: in SRAM, as application admin of the Metaseed Hub application, switch on User token introspection and create an introspection token; set it as SRAM_INTROSPECTION_TOKEN in the hub's environment. SRAM_INTROSPECTION_URL is the endpoint (https://sram.surf.nl/api/tokens/introspect; the acceptance instance for testing) and SRAM_INTROSPECTION_CACHE_SECONDS how long an answer is reused before SRAM is asked again (300 by default; a token SRAM has just revoked keeps working for at most that long). Without SRAM_INTROSPECTION_TOKEN the hub refuses SRAM tokens with a message saying they are not enabled, and hub personal access tokens are the non-interactive credential.

Each answer is handled by what SRAM says: a valid token acts as the account whose subject it names and refreshes that account's collaboration reading; token-expired, token-unknown, user-suspended and token-not-connected are refused with that reason; a SRAM that cannot be reached, or answers with a server error, is reported as not checked (503), never as a refusal. An introspection token SRAM no longer accepts is the administrator's problem, not the user's: it is recorded as an error on this page and the request is answered 503 with a message to that effect.