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

Person	Can do
Contributor (a project member who may edit)	Upload and inspect a LAS original, choose who can ever see it, share it, request review, 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 shared with them or with the whole project; cannot upload or share
Not a project member	Nothing in the project; responses reveal no names or identifiers
Project administrator	Membership and connections; approve, return and rename review stages; administration does not bypass sharing of someone else’s original

Adding data, sharing it and requesting review do not require administration or permission to run calculations. Running recorded calculations additionally needs permission to run calculations. Approving, returning and renaming review stages need project administration. Viewers read only what is shared with them. Connecting a database or other credentialed source remains an administrator task.

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. Before anything is saved, Workspace says how many people will be told (1 person will be told.) and, when you remove someone, how many will lose access; choose Save to share or Back to change your choice. A server that cannot count says so, and you can still decide.

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

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 see an original

Under Who can see this original, choose one, give a reason and choose Save who can see this original:

Only me — nobody else can be given access.
Me and people I choose — the people you list may be given access to the original and to results built on it. Listing them shares nothing yet.
Me and everyone in this project — everyone in the project can see the original, including people who join later. A person who leaves the project loses it at once.
Narrowing removes access to the original and to every result built on it for the people it leaves out (the author of a result keeps their own copy’s access, but cannot open it while they are outside). Workspace says how many people will lose access and asks you to confirm.
Widening only makes people eligible. It never restores access that was removed or shares anything; share explicitly afterwards.

The summary lists affected results that you can see; others may exist.

A published result has the same three choices under Who can see this, and the Save sheet of a calculation offers them when you save. Me and everyone in this project lets everyone in the project view and download the result, including people who join later; Build on this is still given by name. It is refused, with the input named, when the result is built on something not everyone in the project can see (project-input-not-shared: share that input with the whole project first, or choose people) or on a release with a fixed audience (project-input-fixed-audience: choose people). Curve results from a calculation, import recipes and wells are shared by name only.

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, someone published a result built on your data (shown only if you can see that result), or a source you locked has a newer version (nothing moves until you choose). 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.

Review stages

Every version of an original or result has one review stage: Draft, In review, Approved or Withdrawn (administrators may rename them under Settings → Review stages; what each means never changes). See them under Data → Review stages or in the item’s inspector.

The author (or an administrator) requests review.
An administrator approves it for a stated purpose, or returns it to draft with a reason. The approval is recorded as its own line — who approved it, for what, and whether they approved their own work. Approval shares nothing.
The author or an administrator can withdraw a version with a reason. Nobody can then open, download, export or build on that version or on results built from it, and running calculations that use it cannot publish. The stage and its history stay visible to people who could see the item. Withdrawal is final for that version; copies downloaded earlier cannot be recalled.

Shared packages under Shared versions keep their own review; the board shows their state read-only, and a withdrawn package can no longer be previewed or compared.

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. For a derived publication, project=True also shares it with everyone in the project and project=False withdraws that (ophiolite share --project / --no-project); a server that does not report the project audience refuses either before anything is sent. See the SDK reference and the collaboration API. Requests without expected_generation still work during one announced transition release and are then refused.

Limits

Uploads are LAS 2.0 in this pilot; tops, trajectories and horizons follow the four-type checkpoint. Custom stages, email notifications and changing the audience of reviewed releases are not provided. Requests without expected_generation are still accepted during one announced transition release.

Result groups, recommendations and comparisons

Open a Python result and use Result groups to gather related results in a named group. A group only points to results: it copies nothing and shares nothing, and deleting it deletes no result. Colleagues see a group only when they can open at least one of its results, and they see only those results — never a count of the others.

The group’s owner or a project administrator can recommend one exact version per group, with a reason. Everyone who can open that version sees who recommended it and why; earlier recommendations are listed. A recommendation is a person’s judgement. It is separate from the note “A newer version of the input exists”, which Ophiolite derives and which never recommends recalculating.

Compare with another version or result… lists the other versions of the result and the other results in its groups. The comparison names changed, added and removed settings, whether the method or the exact input differ, and how many samples changed — including missing samples that gained a value and values that became missing, the largest change and the depth range. Results calculated from different inputs, with different units or depth samples are not compared; nothing is resampled or converted.