Joripo- Home
- Documentation
- Security and privacy
- Sharing a workspace with external clients
Security and privacy
Sharing a workspace with external clients
Giving a funder, a principal investigator's team or a partner access to one workspace, the roles a grant can have, and what a client can never do.
Joripo documentation · https://joripo.com/docs/security-and-privacy/external-clients
On this page
A survey organisation sometimes has to give someone outside it (the funder, a principal investigator's team, a partner firm) access to one workspace, without making them a member who could reach the rest. A workspace's External access page does this with a grant: exactly one workspace, shared with one person, in one role.
The roles a grant can have
| Role | Can |
|---|---|
| Viewer | See and test the forms (printable version, questionnaire, definition and media) and browse the data. |
| Downloader | Also download exports and form media. The default. |
| Data manager | Also manage data: server datasets, the case list, purging submissions, reviewing quality findings. |
| Form and data manager | Also administer the workspace's forms: create, upload, edit, duplicate, delete, their attachments, groups and quality checks. The most a grant can be. |
A viewer or downloader can also be allowed to see quality results (findings, scorecards, check results); data managers always see them. Without that, no page or file the client opens shows a finding.
What a client can never do
No grant reaches configuration or administration: workspace settings, external access itself, the field team and devices, privacy, people, the organisation and its plan, API tokens, garbling, Server administration, or creating and deleting workspaces. A client never collects, holds no device key and no API token, never has identity access, and sees identifying answers masked. In review, a client sees a submission's status and corrected answers, never the original answers, the comments or the history; on findings, their status, never the team's notes.
This is enforced in one place every request passes through on the server, not by hiding links: a client reaches only the read-only addresses (and the writes their role allows) of the workspaces their grant covers, and anything else is not found.
One password per grant
The client signs in on the ordinary sign-in page. Each grant has its own password: signing in with it opens only that grant's workspace, and nobody, the organisation included, knows the account's own password.
- New password replaces one grant's password and ends the sessions it opened.
- Revoke erases that grant's password, ends its sessions, revokes the person's API tokens, and turns the account off when no grant is left.
- Sharing again makes a new password.
Dashboards for clients
A field-monitoring dashboard is shown to a client only when it is published, shared with external clients, and their access includes quality. See Dashboards.