Summary
Make each layer carry an explicit capability set — query, create, update, delete, export — instead of deriving what a user may do from the layer's source kind, and enforce the write and export capabilities on the server paths that can actually enforce them.
Why
Whether a layer can be edited today is inferred, not declared. LayerPanel.tsx decides by asking what kind of source it is (isPostgisLayer, source-kind checks), and the attribute table and geometry editing follow the same inference. The result is a rule users learn by trial: a drag-and-dropped GeoJSON layer is editable, the same data added as a remote vector layer is not.
That has three costs:
- The rule is invisible. Nothing tells you why Field Calculator is unavailable on this layer and available on that one; the capability is not shown because it is not represented.
- It cannot be narrowed. "Editors may update attributes but not delete features", or "this layer is editable but must not be exported", are ordinary requirements with no way to express them. Export is the one people care about most, because a project shared with someone who may look at a dataset often should not hand them a full download of it.
- It cannot be widened either. A PostGIS table the sidecar can write (
postgis_write) has no way to advertise that it is read-only by policy rather than by capability.
Proposal
1. A capability set on the layer record
Add to GeoLibreLayer an optional capability set — query, create, update, delete, export — defaulting to today's inferred behavior so nothing changes for existing projects. Persist it in .geolibre.json (a docs/project-format.md addition).
2. Drive the UI from it
Attribute-table editing, geometry editing, Field Calculator, delete-feature, and the export/download actions all read the capability instead of re-deriving from source kind. Where a capability is absent, disable with a reason — "this layer is read-only because it was added as a remote service" is a better answer than a greyed-out button.
3. Enforce where enforcement is possible
Say plainly which of these are real and which are advisory:
- Real:
postgis_write in the sidecar can refuse a write to a layer whose capability set excludes it, on its own authority, alongside the existing _validate_postgis_target allowlist. Server-backed layers are where this has teeth.
- Real:
export can be enforced at publish time — the share upload rewrites the project, so a layer marked no-export can have its embedded data dropped and be republished as a reference the recipient cannot download in bulk.
- Advisory only: a client-side GeoJSON layer already fully in the browser's memory. Marking it non-editable is a workflow guard against accidents, not a security boundary, and the UI should not imply otherwise.
Being explicit about that split is the most important part of this issue. A capability that looks protective and is not is worse than no capability at all.
Scope notes
- Touches
packages/core (types + project format), LayerPanel.tsx, AttributeTable.tsx, the export actions, and backend/geolibre_server/geolibre_server/app/postgis.py.
- Pairs with the editor-tracking issue:
update and delete are much more useful once there is a record of who did them.
- Prerequisite for the saved-view-definitions issue, which needs a per-layer place to hang a server-enforced filter.
Effort
Medium.
Part of #1665 (access control umbrella).
Summary
Make each layer carry an explicit capability set — query, create, update, delete, export — instead of deriving what a user may do from the layer's source kind, and enforce the write and export capabilities on the server paths that can actually enforce them.
Why
Whether a layer can be edited today is inferred, not declared.
LayerPanel.tsxdecides by asking what kind of source it is (isPostgisLayer, source-kind checks), and the attribute table and geometry editing follow the same inference. The result is a rule users learn by trial: a drag-and-dropped GeoJSON layer is editable, the same data added as a remote vector layer is not.That has three costs:
postgis_write) has no way to advertise that it is read-only by policy rather than by capability.Proposal
1. A capability set on the layer record
Add to
GeoLibreLayeran optional capability set —query,create,update,delete,export— defaulting to today's inferred behavior so nothing changes for existing projects. Persist it in.geolibre.json(adocs/project-format.mdaddition).2. Drive the UI from it
Attribute-table editing, geometry editing, Field Calculator, delete-feature, and the export/download actions all read the capability instead of re-deriving from source kind. Where a capability is absent, disable with a reason — "this layer is read-only because it was added as a remote service" is a better answer than a greyed-out button.
3. Enforce where enforcement is possible
Say plainly which of these are real and which are advisory:
postgis_writein the sidecar can refuse a write to a layer whose capability set excludes it, on its own authority, alongside the existing_validate_postgis_targetallowlist. Server-backed layers are where this has teeth.exportcan be enforced at publish time — the share upload rewrites the project, so a layer marked no-export can have its embedded data dropped and be republished as a reference the recipient cannot download in bulk.Being explicit about that split is the most important part of this issue. A capability that looks protective and is not is worse than no capability at all.
Scope notes
packages/core(types + project format),LayerPanel.tsx,AttributeTable.tsx, the export actions, andbackend/geolibre_server/geolibre_server/app/postgis.py.updateanddeleteare much more useful once there is a record of who did them.Effort
Medium.
Part of #1665 (access control umbrella).