Discussion: should GeoLibre ship a small admin UI for configuration, users/groups, and plugins?

[deniial00]

Context

I'm looking at GeoLibre for an organizational deployment. The projects server is deliberately a contract
(docs/server-api.md) that an org implements, with a reference implementation in
backend/geolibre_server_api, and share.geolibre.app as the hosted instance. I think that split is
right and don't want to change it.

For someone who self-hosts, though, administration has no UI and configuration is spread out:

• The reference server exposes organizations, members, invitations, groups, and join-request moderation,
  but nothing in this repo calls the mutation routes. The client only reads /api/organizations/mine and
  /api/groups/mine for the share dialog. I assume share.geolibre.app has its own management interface, but
  I can't see it from here, so I don't know what it offers or whether it's reusable.
• Deployment settings live in several places: VITE_GEOLIBRE_CAPABILITIES (build time),
  admin-profile.json, GEOLIBRE_* env vars through entrypoint.sh, and server env like
  GEOLIBRE_CONVERSION_ROOTS. Capabilities can't be set on a prebuilt image at all (noted in
  deployment-capabilities.md).
• Which plugins, data sources, menus and services users see is configured per deployment by file or env.

I will need some admin UI for a self-hosted deployment. My question is whether GeoLibre wants one in the
project, or whether that should be the hosting organization's job.

The tension as I see it

For shipping a small one:

• It makes the reference server usable on its own, and shows the contract is implementable.
• Policy (capabilities, profile, services, plugin allowlist) only means something relative to what the
  client does with it, so the project is the natural owner of that part.
• Self-hosters currently get a documented server with no way to manage it, while hosted users get an
  interface. That's an uneven experience.

Against:

• A maintenance burden: the repo's i18n rule (every locale complete), CI, coverage floors, docs.
• An admin app is a high-value attack surface.
• It could pull the project toward being a product when it is a toolkit, and the docs say the reference
  server is "a correctness baseline, not a hardened deployment".
• Orgs that write their own server already have identity, directory, and admin tools and may never use it.
• If share.geolibre.app already has this UI, it may be better to open it up than to write a second one.

A possible middle path

1. Policy as data. One versioned JSON document, published as a JSON Schema, that the client fetches
   from the projects server and that replaces the scattered static settings. This is useful even with no UI,
   because an org can generate the document itself.
2. A small reference admin UI for the reference server, marked as reference like the server. It would
   hide panels the target server doesn't advertise.
3. Enterprise identity and the rest of the hosting org's concerns. SSO/SCIM, the account directory,
   audit storage, retention, and operations are the hosting organization's concern. The contract would
   describe what's expected of a server, and Enterprise sign-in for organizations: SAML/OIDC, SCIM, MFA, and session policy #1682 stays the place for it. I'm planning to address this next,
   after the policy and admin UI groundwork, since I'll need it for my deployment.

Questions for the maintainers

1. Does a reference admin UI belong in this project at all? If yes, in-tree (apps/admin, following
   the repo's conventions) or a separate repo that depends on the published contract, as with GeoLens and
   the plugin registry?
2. Is moving static config into a server-held policy document acceptable? It touches the client and the
   container image.
3. How should enforcement work for things the client can't hold? /sidecar and /ai answer the same
   requests whatever capabilities are set.
4. What settings do you picture in such a UI, and what would you refuse? My starting list is below.

My starting list, to be cut down or extended

Area	Settings I'd expect
Access	Organizations, members and roles, invitations; groups and join policy; public-sharing
policy and default visibility; ownership transfer
Capabilities	The six deployment capabilities (project:edit, data:add, processing:run,
export:data, plugins:install, settings:manage)
Interface	Experience level; hidden menus, menu items, data sources; lock
Plugins	Allowlist or blocklist; whether sideloading a zip or manifest URL is allowed;
default-active plugins; the registry URL
Data and services	The curated service library; GeoLens URL; allowed basemap and tile hosts;
NO_EXTERNAL_CDN-style restrictions
Sharing and embedding	Share and collab URLs; embed origin allowlist; link defaults and expiry
limits
AI and processing	AI providers and proxy on or off; sidecar on or off; conversion roots
Branding	App name and welcome behavior
Accounts and audit	Token lifetime limits, session revocation, activity log retention

I'm unsure about the last row. It may belong to the hosting org's own identity and logging and not to a
GeoLibre UI.

Where I am and what I'd like to know

I'll need these features for my own deployment anyway, so I'm happy to help drive this, whether that means
a design doc, PRs, or testing a prototype. I'd like to do it in a direction that fits the project. So
before I build anything, I'd like to know:

• Direction. Is a small admin UI something you want? If so, in-tree or a separate repo?
• Configuration. Which settings should it cover, and which should stay in env or files? The table
  above is only my guess. What would operators you've talked to expect, and what should stay out?
• Order. What would you want first? I'd guess the policy schema and client consumption, then org and
  group screens, but you may see it differently.

Whatever you decide, I'll write it up as a tracking issue with sub-issues so it's easy to follow.

Related: #1665 (access control), #1682, #1679, #1673, docs/server-api.md,
docs/deployment-capabilities.md, docs/ui-profiles.md.

[giswqs]

Thanks for the careful write-up. It lines up with how I see it.

share.geolibre.app: it's a private repo tied to our hosted infrastructure, and we don't plan to open it. It also has no organization or group management, so there's nothing to reuse. Any admin UI would be new work either way.

Direction: a separate public repo, not in-tree. An apps/admin would take on the full i18n requirement, coverage floors and CI. It would also add a high-value attack surface to the main repo and pull GeoLibre toward being a product. A separate repo that builds against the published contract (docs/server-api.md) keeps that burden out of the core, the same way GeoLens and the plugin registry work. Something like opengeos/geolibre-admin works. I'm happy to create it under opengeos and add you as a maintainer, or you can start it under your account and transfer it later. Please label it "reference" like the reference server.

What does belong in-tree is the policy groundwork:

1. One versioned deployment.json with a published JSON Schema, served at runtime from the app's own origin rather than fetched from the projects server. Many deployments (kiosk, classroom, embed, desktop) have no projects server. It would be a superset of admin-profile.json, capabilities, the plugin allowlist and the services library. entrypoint.sh generates it from env, and desktop reads it from the app config directory. This also resolves Locked-down deployment modes for the web container and embeds (kiosk, classroom) #1673. A projects server could supply an optional override later.
2. No secrets or infrastructure settings in it. Anything the client fetches is public. AI proxy tokens, conversion roots, trusted proxies and CSP or tile-host allowlists stay in env and files.
3. Server-side enforcement from the same policy. Client capabilities only change what users see. entrypoint.sh should derive the nginx config from the policy, for example /sidecar returns 403 without processing:run, and /ai isn't emitted when AI is off. The docs should say plainly that hiding something in the client doesn't enforce it.

Scope for the admin repo: Access, Capabilities, Interface, Plugins, Sharing/embedding and Branding from your table all look right. Leave out "Accounts and audit"; that belongs to the hosting org's identity and logging, as you suspected. The first piece could be a schema-driven editor that just outputs deployment.json, with no auth and no server, followed by org, member, group and invitation screens against the reference server's mutation routes.

Order: schema and runtime delivery (with #1673) → nginx enforcement → the admin repo (policy editor first, then org and group management).

A tracking issue with sub-issues for the in-tree parts would be great. Thanks for offering to drive this.

[giswqs]

I have created the geolibre-admin repo: https://github.com/opengeos/geolibre-admin

[deniial00]

Thanks for creating the repo, and for trusting me. I got the invitation to the org and accepted.

The split makes sense to me. Core keeps the policy groundwork (deployment.json with its
schema, runtime delivery, nginx enforcement),
and geolibre-admin stays a "reference" project
built against the published contract. I'm happy
you're open to working on this together.

Next I'll write the tracking issue with
sub-issues for the in-tree parts, in the order
you gave. Then I'll start geolibre-admin with
the schema-driven deployment.json editor.