Share data with colleagues
This guide covers the team handoff in the bounded pilot: a contributor adds a file, shares it, a colleague reads or builds on it, and anyone outside the project is refused. No licence server, billing or commercial configuration is involved. Everything here is enforced by one authorization implementation on the server; Workspace, the SDK and the CLI are clients of the same API.
Who can do what
Section titled “Who can do what”| Person | Can do |
|---|---|
| Contributor (a project member who may edit) | Upload and inspect a LAS original, choose who can ever see it, share it, read what is shared with them |
| Member who may also run calculations | All of the above, plus configure, run and publish recorded calculations on data they may reuse |
| Viewer | Read what is explicitly shared with them; cannot upload or share |
| Not a project member | Nothing in the project; responses reveal no names or identifiers |
| Project administrator | Membership and connections; administration does not bypass sharing of someone else’s original |
Adding data does not require administration or permission to run calculations. Connecting a database or other credentialed source remains an administrator task.
Share an original
Section titled “Share an original”- Upload the file (Connect → Upload a file) and choose who can ever see this — the people who may later be given access to the original and to results built on it. Choosing them shares nothing yet.
- Open the original and, under Share original, tick who can view and download and who can build on it. Save.
Workspace saves your change only if the recipients are still the ones you were looking at. If someone else changed them first, you see Someone changed these recipients and nothing is saved: reload, review, decide again.
Remove access
Section titled “Remove access”Untick a person and save. From that moment they cannot open, download, export or build on the item through Ophiolite, and a delayed retry of an older request cannot give access back. Copies they already downloaded cannot be recalled; removal only governs new requests. Removing access grants nobody new rights to earlier exports.
Change who can ever see an original
Section titled “Change who can ever see an original”Under Who can ever see this, change the list and give a reason.
- Removing someone also removes their access to the original and to every result built on it (the author of a result keeps their own copy’s access, but cannot open it while they are outside the list). Workspace asks you to confirm who loses access.
- Adding someone only makes them eligible. It never restores earlier access or shares anything; share explicitly afterwards.
The summary lists affected results that you can see; others may exist.
Your inbox
Section titled “Your inbox”The Inbox button in the header shows how many updates you have not read: something was shared with you, you may now build on it, your access was removed, or someone published a result built on your data (shown only if you can see that result). Only you see your inbox. An update about something you can no longer open disappears; a removal never names the item. No email is sent.
Python and the API
Section titled “Python and the API”The SDK reads the current recipients with client.grants(asset) and shares with
client.share(asset, read=[...], reuse=[...], expected_generation=grants.generation).
After a lost response it repeats the identical request once; that repeat is
refused if anyone changed the recipients meanwhile. See the
SDK reference and the
collaboration API.
Requests without expected_generation still work during one announced
transition release and are then refused.
Limits
Section titled “Limits”Uploads are LAS 2.0 in this pilot; tops, trajectories and horizons follow the four-type checkpoint. Review stages, email notifications and changing the audience of reviewed releases are not part of this checkpoint.