Administration

Users, functions on and off, limits, usage, system jobs.

“Administration” is visible to Portal Owners only.

Portal Owner and project administrators

The Portal Owner is the main administrator of the whole portal («Владыка портала» in Russian). They see every user and every project, run this section and may delete another person's project or account. A Project administrator is whoever created the project, and the people they gave this role in the Team. A project administrator runs the team, the settings and the rest, but only in their own projects; they do not see other projects. The server checks the rights, not only the menu.

In a study whose team they are not in, the Portal Owner looks, read-only: they open every page a project administrator opens, but cannot change anything (data, settings, the team, signatures), and takes no file out of it (no data export, list, report or document): files are for team members only. Their own work as the portal's administrator they do outside the team too: renaming the study, rescuing its network access when the address list locked the team out, and confirming signers' identities when the study has no administrator left; each such act goes to the audit trail. They see a blinded study like a team member who is not unblinded, and cannot break a code. A banner on every page says so, and each visit goes to the study's audit trail (“Portal Owner looked into the study”). To work in a study, the Portal Owner joins its team with a role like anyone else, so the team page and the delegation log stay true (ICH E6(R3), 21 CFR Part 11).

Users

A searchable list with last sign-in and the functions each person uses. You can reset a password (the new one is shown once), block and unblock, lift a lockout, grant or remove Portal Owner rights.

Here you can also delete a user for good (or anonymise them if they worked in studies) and delete in one go the bots that never confirmed their e-mail: see E-mail confirmation, bots, deleting users. The invented team of demo projects has its own filter “Demo team”.

Your projects

In “My studies” a Portal Owner, like everybody else, sees only the projects where they are in the team: those they created and those they were invited to. Other people's projects, demo projects included, are listed only in Administration › Projects. Every card says whose project it is: “Owner” on the projects you created, “My role: Data manager” (or another role) where you were invited. The newest added project is at the top, and under the name each card says who created it and when, in the portal’s time zone. Hold the mouse over any badge or icon on a card (on a phone, tap it) to see what it means; the same hint works for icon buttons and badges all over the portal. Example: you own TST-01 and are a data manager in REG-02, and a colleague runs ONC-03 without you: “My studies” shows two cards, TST-01 with “Owner” and REG-02 with “My role: Data manager”; ONC-03 is only in Administration › Projects. The counters, the status filters and the search at the top of the portal count only your projects.

Deleting a project

Administration › Projects: the bin icon on a project's row opens the deletion page. Every copy of a study has the icon: production, its QA and training environments, and a demo. The page lists the copies with their patients and shows how many audit records, team members and signatures the project has.

Choose what to delete: “The whole project” (production with every environment; for a demo, also its YouEDC Studio twin) or one copy, “Only QA” or “Only Training”. Confirm with the project code and your password: it is your electronic signature, and a wrong password counts towards the lock as at sign-in. You may add the reason.

What you delete goes to the trash and lies there 30 days: it stays in the list of projects with the status “In the trash” and the date it goes for good, and the status filter “In the trash” shows only them. Nobody sees or opens it, letters and reminders about it stop. In the trash you can “Restore” it (a copy deleted together with its production comes back with it) or “Delete now” with the code and your password. After 30 days, or after “Delete now”, a background job deletes everything for good: patients and data, team and sites, queries, signatures, files and DICOM on the disk and in S3, documents and the study's own audit chain. Each study has its own audit chain, so deleting it does not break the check of the others. The portal audit keeps every step: who deleted, restored or deleted for good, when and why.

A study with real patients is kept for years after it ends (ICH E6(R3), 21 CFR Part 11, local law). So production with patients is never deleted here: the page offers “Close and archive” instead. The study becomes read-only for everybody, and its full archive (data, casebooks, audit trail, signatures, files) is built in the background for the team to download. If it was closed by mistake, “Back to work” returns it to its former stage. Only on a test installation with invented data can this rule be switched off: Administration › Settings › “Deleting studies”. The same place switches all deletion off; then the database refuses it too.

Functions and limits

Every function can be switched off: it leaves the menu and direct links show “function switched off”. For each function you see who used it and how often over 7, 30 or 90 days, and you set a daily per-user limit next to it.

Global limits protect the server: studies per user, invitations per day, upload size, profiler rows, requests per minute, background jobs per minute. Limits do not apply to Portal Owners.

Access

Which functions people and groups are allowed or denied, functions only for allowed people, the project role matrix and the “why can this person see it” check. In detail, with examples and a diagram: Access management. New accounts can wait for the Portal Owner's approval: choose the mode in Settings.

Portal settings

Open sign-up or invitation only, a banner for all users at the top of the screen, the switch for deleting studies, installation facts.

SMS

The SMS gateway through which studies send patients their ePRO link and reminders, only with the consent recorded by the site: the provider (SMS.RU or “Log only”), the API key kept encrypted, the sender name registered with the provider, the daily limit for the portal and the sending hours. “Send a test SMS” and “Check the key” show the provider’s answer at once; below are the last messages with the number masked. In detail: SMS to patients.

System

Background jobs (mail, nightly audit check, clean-up), running a job by hand, a test e-mail, table sizes and the date of the last backup.

Personal data encryption

Personal data encryption in the database is postponed until the production installation; the System page says “postponed”. At the first start of the stage-a.19 release the portal decrypted everything stage-a.18 had encrypted, in one transaction and with a record in the audit trail of each study. Do not remove the PII_KEY key from .env: it protects the key of the SAML sign-in (sign-in with the company account); without it that key would have to be made again, and the companies’ configured sign-ins would stop working.

When an older database backup with encrypted values is restored, the start needs the PII_KEY that .env had then: the portal decrypts them and again needs no key. Details: docs/PII_KEY.md.

Pages

Texts of the public part of the portal are edited right here, in Russian, English and French: the personal data policy, Contacts, your own pages (for example “About us” or “Webinars”, address /page/…), the notice on the home page, the footer note, help articles and the roadmap. A Portal Owner sees an “Edit this page” button on public pages.

Home page. Administration › Pages › Public home page: the titles and texts of the public home page, a field per language. Example: change the title “All of data management in one window” to your own wording, save, and the home page shows it at once; “Show the built-in text” brings the original back. The lists of what each section does are not edited: they follow the portal’s functions. When a new version of the portal brings a newer built-in text, the slot is marked “built-in text is newer”.

Home page blocks. The home page is a column of blocks: top of the page, who it is for, the sections, what already works, from the protocol to the study structure, coming next, data stays where it should, questions and the invitation at the end. The arrows change the order, “Hide” takes a block off the site (it stays in the editor), and “Add your block below” creates a block with a title and a text in each language of the portal. Example: under the top block add “Webinar on 10 November” with a text and a last line [Sign up](/signup): that line becomes a red button. Every action goes to the portal audit.

• Formatting is simple: ## heading, - item, 1. item, **bold**, [text](https://address). HTML is not allowed, so nobody can put a script on a page.
• Preview shows the result without saving anything.
• Every save stays as a version you can restore. All changes go to the portal audit.
• A language without text shows the English one. The personal data policy and help articles have a built-in text: it is shown until you write your own, and you can go back to it.
• A new page starts as a draft that only Portal Owners see until you publish it.