BUG: Organization Structure overrides organization specific Mirror Destination #165

New Issue

2026-10-05T01:45:29+02:00

adam commented

2026-10-05 01:45:29 +02:00

Setting the instance to Organization Structure "Single Organization Destination Organization" to "mirrors" seems to have a higher priority than setting a Mirror Destination on a repo or organization, white in my understanding it should be only the fallback when nothing gets set on the per repo or per organization setting.

Setting Mirror Destination with a Single Organization set results in the Mirror Destination being ignored:

results in

I would expect that it preserves the "GrapheneOS" organization structure since I manually set it here to override the global Single Organization "mirrors" Destination Organization setting. I need to be able to manually set the organizations on specifig cases and not every repo should be forced into the Single Organization Destination Organization if a repo or organization specific setting is set to override the global setting.

So the usecase is to:

Mirror Organization1 into forgejo Organization1
Mirror everything else that is not part of the manually set Mirror Destination into "mirrors" organization as per Single Organization Destination Organization strategy.

Setting the instance to Organization Structure "Single Organization Destination Organization" to "mirrors" seems to have a higher priority than setting a Mirror Destination on a repo or organization, white in my understanding it should be only the fallback when nothing gets set on the per repo or per organization setting. Setting Mirror Destination with a Single Organization set results in the Mirror Destination being ignored: <img width="565" height="518" alt="Image" src="https://github.com/user-attachments/assets/8d46d909-6d79-4cc2-af0e-7b858e2f6641" /> results in <img width="557" height="447" alt="Image" src="https://github.com/user-attachments/assets/972b2878-08c9-4944-93c9-a88ae600459f" /> I would expect that it preserves the "GrapheneOS" organization structure since I manually set it here to override the global Single Organization "mirrors" Destination Organization setting. I need to be able to manually set the organizations on specifig cases and not every repo should be forced into the Single Organization Destination Organization if a repo or organization specific setting is set to override the global setting. So the usecase is to: Mirror Organization1 into forgejo Organization1 Mirror everything else that is not part of the manually set Mirror Destination into "mirrors" organization as per Single Organization Destination Organization strategy.

adam closed this issue

2026-10-05 01:45:29 +02:00

adam commented

2026-10-05 01:45:30 +02:00

Thanks for the detailed report, this was a real bug in the organizations UI and it is fixed in v3.36.0 (#418).

What happened: the Mirror Destination editor on an organization card treated a typed value equal to the organization's own name as "reset to default" and saved no override at all. That rule is only right under the preserve strategy. With the strategy set to single-org the default is the destination organization ("mirrors"), so GrapheneOS -> GrapheneOS was stored as "no override" and every repository kept going to mirrors. The card then showed "GrapheneOS -> GrapheneOS" without a custom badge, which made it look saved.

The server side was already right (per-repository destination, then organization override, then strategy), so only the UI changed:

A destination is saved exactly as typed. Clearing the field is the only way to remove an override.
The organization card shows the default for your actual strategy in the preview, the placeholder, the help text and the Reset button, and any stored destination is marked custom.
Reset to Default really clears the override now. It used to save the current value again.
The repositories table shows an organization's destination as the default for its repositories instead of "mirrors" for all of them, which is probably why the per-repository field looked ignored too.

Two things to do on your install after updating. First, set the organization destination again (GrapheneOS), since the earlier attempt stored nothing. Second, if a reconcile ran, or destinations were edited, while everything was sitting in mirrors, individual repositories may carry their own destination pin of "mirrors". A per-repository pin outranks the organization override, so those repositories would keep going to mirrors until it is cleared. On the repositories page they show a "custom" badge next to the destination: edit that cell, empty the field, save, and the repository falls back to the organization's destination.

Thanks for the detailed report, this was a real bug in the organizations UI and it is fixed in v3.36.0 (#418). What happened: the Mirror Destination editor on an organization card treated a typed value equal to the organization's own name as "reset to default" and saved no override at all. That rule is only right under the preserve strategy. With the strategy set to single-org the default is the destination organization ("mirrors"), so GrapheneOS -> GrapheneOS was stored as "no override" and every repository kept going to mirrors. The card then showed "GrapheneOS -> GrapheneOS" without a custom badge, which made it look saved. The server side was already right (per-repository destination, then organization override, then strategy), so only the UI changed: - A destination is saved exactly as typed. Clearing the field is the only way to remove an override. - The organization card shows the default for your actual strategy in the preview, the placeholder, the help text and the Reset button, and any stored destination is marked custom. - Reset to Default really clears the override now. It used to save the current value again. - The repositories table shows an organization's destination as the default for its repositories instead of "mirrors" for all of them, which is probably why the per-repository field looked ignored too. Two things to do on your install after updating. First, set the organization destination again (GrapheneOS), since the earlier attempt stored nothing. Second, if a reconcile ran, or destinations were edited, while everything was sitting in mirrors, individual repositories may carry their own destination pin of "mirrors". A per-repository pin outranks the organization override, so those repositories would keep going to mirrors until it is cleared. On the repositories page they show a "custom" badge next to the destination: edit that cell, empty the field, save, and the repository falls back to the organization's destination.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/gitea-mirror#165