officer
d4efc52447
The form asked for a URL and a token together, on a fresh instance, while the machine in front of it often had both on disk already — somebody had run `tea login` by hand. Two changes. One thing at a time: until the platform knows where Gitea is, a token cannot be checked, because there is nothing to check it against. So the owner names the instance first, and only then does the page ask for — or discover — a token. That step now probes /api/v1/version unauthenticated, since demanding a token to validate a URL refuses a good URL for the wrong reason and sends whoever typed it looking for a credential problem. And it reads tea's own config when the platform has no instance yet, offering the URL it finds. A machine that already has a working login should not be asked to retype what it can see. Members skip the first step entirely — the instance is the owner's.
Gitea
Your own Gitea inside Officer — repositories, issues and pull requests, rendered as the real thing rather than a copy of it.
What you get
Gitea's own web interface, in an Officer panel. Not a reimplementation: the actual application, proxied through Officer so it stays signed in, with an open in a new tab button for anything the frame handles badly.
Requirements
A Gitea instance Officer can reach.
Setup
Install the plugin, open /gitea, and set the instance URL and an API token in the connection panel. Then sign in to Gitea inside the frame, once — the frame shows your Gitea account, not the owner's.
The stored token is used only for the small things around the frame. Everything you see in it is your own session.
For agents
This plugin ships an affordance: use plain git for clone, fetch, pull and push; use tea for pull
requests, issues, comments and releases. tea is logged in as you, with your permissions.
Permissions
One permission, gitea, grantable per role like any other app permission. Each account reaches its own
Gitea identity.