Skip to content
sjTasks
AI

Integrations

Tasks into Gitea, and back

Connect a project to a Gitea repository: a task you send opens as an issue there, and an issue a developer labels for you becomes a task here.

Development shops run two conversations about the same work. The client talks about it in plain words, on the task. The developers talk about it in the repository, on the issue, with the branch and the pull request beside it. Nobody should have to type it twice, and no client should have to read a stack trace.

Connecting a project to a Gitea repository joins the two, one piece of work at a time. Plenty of tasks never involve a developer — the invoice, the copy, the call — so nothing crosses on its own. A person sends a task to the developers, and from then on the task and the issue keep each other in step. A developer labels an issue for the client, and from then on the issue and the task do the same. What a developer writes on the issue stays in the repository unless the developer chooses to share it.

Connecting

Open the project, press Settings, then Integrations. Only admins see this page. In the Gitea card:

  • Gitea address — the server itself, https://git.example.com, without a path, on the standard port.
  • Repository — owner/name, the way it appears in the address bar.
  • Access token — made on Gitea under Settings → Applications, with the issue scope. We check it against the repository before saving, and we keep it encrypted. The field empties after you save; leave it empty later to keep the token you already gave.
  • Which tag sends a task to the repository — dev unless you name another. Send to developers on a task puts this tag on; so does the tag picker.
  • Which label brings an issue here — client unless you name another. A developer puts this label on an issue in Gitea and it becomes a task in this project.

Press Connect. There is no "every task in the project" setting: most work in a project is not for the repository, and the tag and the label are the whole rule.

Letting the repository talk back

Once connected, the card shows a target URL and a secret. In Gitea, open the repository's Settings → Webhooks → Add webhook → Gitea, paste both in, tick the two issue events (the issue itself, and what is written under it), keep the content type as JSON, and save. That is all: from then on the repository tells the project what happened to its issues, and the project checks every message against the secret before believing it.

Sending a task to Gitea

On a task in a connected project, under the details on the right, press Send to Gitea. The task gains the send tag, an issue opens in the repository, and the button gives way to a chip — Issue #57 in owner/name — that opens it. The tag stays on the task, so a glance down any list shows which work has a twin in the repository.

Taking the tag off later changes nothing: the issue stays open, the chip stays on the task, and the two keep following each other. The tag is how a task is sent, not how it is kept.

Who is who

Under the connection, Who is who names the Gitea login behind each developer on the team. Assign a task to a person named there and the issue is assigned to their login; a developer assigning the issue to themselves puts their name on the task. A person not named in the list is never assigned or unassigned by the other side. Only admins and members can stand behind a login — a client does not work in the repository.

If the Gitea server is your own, tick This Gitea server is our own on the card. Then a developer whose Gitea email is the email they use here is recognised without being listed, and the list is for when the two differ. Leave it off for a server where anyone can make an account: there, an email on a Gitea account is only what its owner typed, so only the list says who is who, and anything from a developer not on it arrives as written in Gitea by that login.

What crosses, and how

On the task On the issue
Send to Gitea, or the send tag goes on An issue opens: acme-142 · the title, the description, and a line saying who opened it in sjTasks with a link back
The title is edited The issue is renamed
The description is edited The issue's text is rewritten to match. The description is the client's, kept in the client's tool
Marked done or canceled The issue is closed, with a line on it saying which
Reopened The issue is reopened
In progress, blocked or on hold The issue carries a status/in-progress, status/blocked or status/on-hold label; open carries none of them. On hold leaves the issue open on purpose — the work is paused, not finished, and closing it would tell the developer to stop caring rather than to stop working
Assigned to someone in Who is who The issue is assigned to their login. Taken off them, the issue's assignee is cleared
A note is written The note appears under the issue, prefixed with who wrote it
On the issue On the task
A developer puts the receive label on an issue, when opening it or later A task is created in the project, wearing the send tag, with the issue's text as its description. If the developer is known here, the task is theirs; otherwise it says who opened it in Gitea
An issue without the receive label does anything at all Nothing. It is the developers' own business
The issue is closed The task is done — or canceled, when the issue wears wontfix or invalid
The issue is reopened The task is open again
A developer adds or removes status/in-progress, status/blocked or status/on-hold The task's status follows
The title is edited The task's title follows
The issue's text is edited Nothing. The description belongs to the task, and the next edit here rewrites the issue's text anyway
The issue is assigned to a developer who is known here The task is assigned to them. Assigned to nobody, the task is unassigned only if the person on it was one the repository could name
A developer writes something under the issue Nothing crosses. The task's chip counts it — Issue #57 · 3 in Gitea — so you know the conversation is happening without reading it
A developer writes something whose first line is /share The rest becomes a note on the task, with the developer named, and a thumbs-up goes on what they wrote so they know it crossed

Files on a task do not cross.

How a developer answers the client

Begin what you write under the issue with /share. That one — and only that one — becomes a note on the task, with the developer's name on it:

/share Fixed on staging. Please check the header on your phone.

The /share itself is stripped, so the client reads the sentence and nothing else. It has to be the first line, the rest of what was written comes with it, and a thumbs-up appears on it once the note is on the task — that is how a developer knows it landed rather than wondering.

Nobody has to remember the syntax. Every issue sjTasks opens ends with the line that explains it, so it is in front of whoever is reading the issue, and it stays there even after the client edits the description and the issue's text is rewritten.

Why what developers write does not cross on its own

A client reads every note on a task. A developer's "rebased onto main, please re-test" is not for them, and a stack trace is worse. So the repository's conversation stays in the repository, and a developer decides, line by line, what the client should see. The client's notes always cross the other way, because what the client said is exactly what the developer needs.

When something goes wrong

A repository that stops answering is not something the person who moved a task should hear about. Changes are sent in the background and retried; the Integrations page shows the last error and, if the repository refuses ten changes in a row, the connection switches itself off and says so there. Fix the token or the repository name and save to reconnect.

Disconnect forgets the token, the secret and the list of who is who. The issues already opened stay in the repository, and the chips on the tasks still open them; the repository's webhook stops being accepted until you connect again and paste the new secret.

Tasks into GitHub, and back →

Updated 2026-09-29