feat(org): org-level email domain policy for members (#727) #732

Merged

jmiller merged 1 commits from feat/org-email-domain into dev 2026-07-05 04:34:26 +00:00

Conversation 0 Commits 1 Files Changed 9

+257

jmiller commented 2026-07-05 03:41:07 +00:00

Owner

Copy Link

Copy Source

Part of the org-governance series (#728–#731). Adds an org email domain policy — the one bounded piece of the "access/security" tier.

⚠️ Stacked on #731 → #730 → #729 → #728. Migrations contiguous (362→366). Merge in order. Diff self-cleans as the earlier PRs land. This commit is f32fe74 (9 files, +257).

What it does

When an org configures allowed email domains, a user can only be added to the org (via any team) if their primary email matches one of the allowed domain globs (e.g. example.com;*.example.org). An empty policy imposes no restriction.

How — one choke point

Every membership-add path (API, web UI, external group-sync) funnels through services/org.AddTeamMember, so a single check there covers them all. On violation it returns a typed git_model.ErrEmailDomainNotAllowed; the API team-add handler maps it to 422 (web surfaces the message).

• Model models/git/org_email_domain.go: OrgEmailDomainPolicy + EmailAllowed (domain glob match) + OrgEmailDomainAllowed + typed error + CRUD. Migration 366.
• API GET/PATCH/DELETE /orgs/{org}/email_domain_policy.
• Enforcement in AddTeamMember; 422 mapping in routers/api/v1/org/team.go.

Scope note — the rest of Tier 4 was deliberately NOT built

I built only this piece. Org 2FA-required and org IP allowlists were left out on purpose: they're cross-cutting enforcement (auth gating on many actions; request middleware on every request) with no single choke point — a blind, uncompiled bug there means "nobody can log in," not "a policy doesn't apply." They deserve compiler-backed, tested work. And org-wide required status checks — the fourth Tier-4 item — is already delivered by org branch protection (#728, StatusCheckContexts).

Caveats

• Primary-email only — checks user.Email (the primary), not secondary emails. Reasonable default; noted for review.
• Swagger omitted; no Go toolchain locally → not compiled/gofmt'd/tested. Hand-verified: gofmt, gci import order (git_model added to the api team handler), typed-error detection, migration contiguous. Integration check: set an org policy and try adding a user whose email is outside the allowed domains — expect 422 / rejection.

https://claude.ai/code/session_01Wsno14cxE49MstXFs9G5KT

Part of the org-governance series (#728–#731). Adds an **org email domain policy** — the one bounded piece of the "access/security" tier. > **⚠️ Stacked on #731 → #730 → #729 → #728.** Migrations contiguous (362→**366**). Merge in order. Diff self-cleans as the earlier PRs land. This commit is `f32fe74` (9 files, +257). ## What it does When an org configures allowed email domains, a user can only be added to the org (via **any** team) if their **primary email** matches one of the allowed domain globs (e.g. `example.com;*.example.org`). An empty policy imposes no restriction. ## How — one choke point Every membership-add path (API, web UI, external group-sync) funnels through **`services/org.AddTeamMember`**, so a single check there covers them all. On violation it returns a typed `git_model.ErrEmailDomainNotAllowed`; the API team-add handler maps it to **422** (web surfaces the message). - **Model** `models/git/org_email_domain.go`: `OrgEmailDomainPolicy` + `EmailAllowed` (domain glob match) + `OrgEmailDomainAllowed` + typed error + CRUD. Migration **366**. - **API** `GET/PATCH/DELETE /orgs/{org}/email_domain_policy`. - **Enforcement** in `AddTeamMember`; 422 mapping in `routers/api/v1/org/team.go`. ## Scope note — the rest of Tier 4 was deliberately NOT built I built only this piece. **Org 2FA-required** and **org IP allowlists** were left out on purpose: they're cross-cutting enforcement (auth gating on many actions; request middleware on every request) with no single choke point — a blind, uncompiled bug there means "nobody can log in," not "a policy doesn't apply." They deserve compiler-backed, tested work. And **org-wide required status checks** — the fourth Tier-4 item — is already delivered by org branch protection (#728, `StatusCheckContexts`). ## Caveats - **Primary-email only** — checks `user.Email` (the primary), not secondary emails. Reasonable default; noted for review. - **Swagger omitted**; **no Go toolchain locally** → not compiled/`gofmt`'d/tested. Hand-verified: gofmt, gci import order (`git_model` added to the api team handler), typed-error detection, migration contiguous. Integration check: set an org policy and try adding a user whose email is outside the allowed domains — expect 422 / rejection. https://claude.ai/code/session_01Wsno14cxE49MstXFs9G5KT

jmiller changed target branch from main to dev 2026-07-05 03:58:27 +00:00

jmiller added 31 commits 2026-07-05 03:58:27 +00:00

chore: sync pr-check.yml from Template-Generic [skip ci] 108b19dcc8

release: code security scanner (#552) ... f8a91ed34e

Code security scanner with 22 OWASP pattern detection rules across 7 CWE categories (SQL injection, XSS, command injection, path traversal, insecure deserialization, hardcoded credentials, weak cryptography). Language-filtered scanning for Go, PHP, Python, JS/TS, Java, C#, Ruby.

chore: sync auto-release.yml from Template-Generic [skip ci] 11b2195bdf

fix: remove orphaned deploy-manual workflow [skip ci] 84c6a94333

Merge pull request 'fix: remove orphaned deploy-manual workflow' (#718) from fix/remove-deploy-manual into main ... 78328146e5

fix: remove orphaned deploy-manual workflow [skip ci]

fix: support radio inputs in admin system config form ... 982e45a56e

The system config form JS (config.ts) only mapped checkbox, text, textarea, and datetime-local elements. The fork landing_page.tmpl uses radio inputs for the Mode field, so fillFromSystemConfig() hit unsupportedElement() and threw, aborting all JS init on the admin settings page.

Add radio handling in both directions: fill checks the option whose value matches the config value; collect returns the checked option's value and skips/nulls unchecked radios so a group resolves to exactly one value. Adds a radio-group test case.

fix: preserve server-rendered radio default when config value is empty ... efb0433412

LandingPageType.Mode defaults to "" (Go zero value), and the template renders the home radio as checked for an empty Mode. The initial radio fill would evaluate home.checked = ("home" === "") = false, unchecking the default on a fresh install. Skip assignment when the config value is empty so the server-rendered selection is preserved. Adds a test for the empty-value case.

ci: allow fix/patch branches to target main and guard missing manifest ... b252e9569f

Branch policy in pr-check.yml only allowed fix/* and patch/* to target dev/rc, blocking fix/* PRs to main despite the documented policy. Allow fix/* -> main and patch/* -> main. Also guard the Detect platform step for a missing .mokogitea/manifest.xml (removed in favor of the metadata API) so it no longer aborts the Validate PR job under set -e.

fix: remove dangling mcp-mokogitea-api submodule gitlink ... fc234bc911

The tree carried a gitlink at mcp-mokogitea-api (mode 160000) with no .gitmodules entry, so git submodule update --init --recursive failed with exit 128 at checkout, breaking every PR build/release job. mcp-mokogitea-api is a separate repo, not a submodule; remove the gitlink from the index (keeping the local working-tree clone) and gitignore the path so it can't be re-added.

ci: no-op PR RC Release when updates.xml is absent ... aea4370845

The RC release workflow drives a Joomla-style updates.xml update stream. On a generic repo with no updates.xml, the Determine RC version step ran sed on a missing file and aborted under set -e (exit 2). Detect updates.xml presence and gate the update-stream steps (edit/create-release/commit) on it so the job succeeds and no-ops when there is nothing to package.

Merge pull request 'fix: support radio inputs in admin system config form' (#724) from fix/admin-config-radio into main cb9516b79b

chore: sync auto-release.yml from Template-Generic [skip ci] 844b4b6e81

chore: sync ci-generic.yml from Template-Generic [skip ci] 8fc2700c16

chore: sync cleanup.yml from Template-Generic [skip ci] 51332a587d

chore: sync notify.yml from Template-Generic [skip ci] 296df7792a

chore: sync pr-check.yml from Template-Generic [skip ci] adf0e923df

chore: sync pre-release.yml from Template-Generic [skip ci] 8680fd1cab

chore: sync sync-on-merge.yml from Template-Generic [skip ci] 0c45a2fda3

chore: sync branch-cleanup.yml from Template-Generic [skip ci] 05763eb661

chore: sync ci-generic.yml from Template-Generic [skip ci] 1256f57d40

chore: sync pr-check.yml from Template-Generic [skip ci] 22b0b14ea8

chore: sync ci-generic.yml from Template-Generic [skip ci] d77b82a8af

chore: sync pr-check.yml from Template-Generic [skip ci] ea87b3db97

chore: sync pr-check.yml from Template-Generic [skip ci] 4ed45a5916

fix: render org teams list and make issue type editable (#720, #721) ... 0cc569aef6

#720: org Teams page wrote ctx.Data["OrgListTeams"] but the template iterates .Teams, so no teams rendered. Use the canonical Teams key (matches org/home.go). #721: issue type sidebar gated editing on a FieldEditFlags data key that no handler sets (always nil -> always read-only). Use HasIssuesOrPullsWritePermission like the priority field; the /custom-type endpoint is already protected by reqRepoIssuesOrPullsWriter.

Merge pull request 'fix: render org teams list and make issue type editable (#720, #721)' (#726) from fix/team-list-and-issue-type-editable into main 5ffed39449

chore: sync auto-release.yml from Template-Generic [skip ci] 377dd019be

fix(org): layer org-level branch protection with repo rules, most-restrictive wins (#727) ... 24b3516c1d

Org-level branch protection was already consulted at the single enforcement
choke point `GetFirstMatchProtectedBranchRule`, but only as a FALLBACK: if any
repo-level rule matched the branch, the org rule was ignored entirely. That let
a repo define a looser rule for a pattern and effectively opt out of the org's
protection.

Make the choke point LAYER the two rules instead: when both an org rule and a
repo rule match a branch, return their most-restrictive (fail-closed)
combination, so the org rule is a mandatory floor a repo can only tighten.

- models/git/protected_branch_merge.go: mergeMostRestrictive + helpers. Allow
  flags AND'd; gate/require/block flags OR'd; RequiredApprovals max'd; required
  sets (status contexts, protected files) unioned; allow sets (whitelists,
  unprotected files) intersected. A disabled allowlist means "everyone", so it
  only constrains when enabled.
- models/git/protected_branch_list.go: GetFirstMatchProtectedBranchRule now
  fetches both the repo rule and the org rule and merges when both match;
  returns whichever exists when only one matches. Org lookup factored into
  getFirstMatchOrgProtectedBranchRule.

Supersedes the materialization approach previously proposed for this issue —
the org fallback already existed, so only this one function needed to change.

Fail-closed by design: any merge edge errs toward MORE protection (over-restrict)
rather than less, so it cannot open a hole.

Note: no Go toolchain available locally, so not compiled/gofmt'd/tested here —
relying on CI to validate build, formatting, and tests.

Claude-Session: https://claude.ai/code/session_01Wsno14cxE49MstXFs9G5KT

feat(org): show inherited org branch-protection rules in repo settings (#727) ... 86bd8a2cad

The org "floor" is enforced implicitly at the choke point, so a repo admin
couldn't see which org-level rules apply to their repo. Surface them in the
repo's Branch Protection settings page (read-only), the way GitHub shows
organization rulesets in a repository.

- ProtectedBranchRules handler: when the owner is an org, load
  FindOrgProtectedBranchRules and expose them as OrgProtectedBranches.
- branches.tmpl: new read-only "Organization Branch Protection" section listing
  each org rule with an "Organization" badge, a lock/read-only marker, and
  compact indicators (required approvals, signed commits, status checks). No
  edit/delete controls — these are managed at the org level.
- en-US locale strings.

Note: no Go toolchain available locally, so not compiled/gofmt'd/tested here.

Claude-Session: https://claude.ai/code/session_01Wsno14cxE49MstXFs9G5KT

feat(org): add branch-deletion protection + expandable inherited-rule view (#727) ... 4b68853f08

Two related additions:

1. Branch deletion as an org-level ability. OrgProtectedBranch gained
   CanDelete / EnableDeleteAllowlist / DeleteAllowlistTeamIDs (migration 362),
   ToProtectedBranch maps them, and the API (create/edit/response DTOs +
   handlers) exposes enable_delete / enable_delete_allowlist /
   delete_allowlist_teams. The layering merge already combined delete fields, so
   org delete-protection now enforces once ToProtectedBranch populates them.

2. The repo Branch Protection view now renders each inherited org rule as an
   expandable detail (direct push, force-push, branch deletion, merge, required
   approvals, status checks, protected files) with team names resolved, instead
   of three headline badges. Still read-only.

Note: no Go toolchain available locally, so not compiled/gofmt'd/tested here.
Verified by hand: struct-field gofmt alignment, template block nesting balances,
every .Rule field exists on OrgProtectedBranch, and all locale keys referenced
in the template are defined.

Claude-Session: https://claude.ai/code/session_01Wsno14cxE49MstXFs9G5KT

feat(org): org-level tag protection, layered with per-repo protected tags (#727) ... b31336d1fe

Adds org-level tag protection as a parallel to org-level branch protection.
An org tag rule is {NamePattern, AllowlistTeamIDs}; it cascades to every repo
in the org and layers on top of the repo's own protected tags — a tag is
controllable (push/delete) only if allowed at BOTH levels (fail-closed).

- models/git/org_protected_tag.go: OrgProtectedTag model + CRUD +
  ToProtectedTag() (reuses the ProtectedTag matcher/allowlist logic) +
  IsUserAllowedToControlTagInRepo() which ANDs the repo decision with the org
  decision. Migration 363.
- API: /orgs/{org}/tag_protections CRUD (routers/api/v1/org/tag_protection.go,
  DTOs in modules/structs/org_tag.go, wired in api.go).
- Enforcement: the git push/delete hook (hook_pre_receive.go) and the two
  release paths (release.go create/delete) now call the layered check, so no
  per-site tag logic changes beyond swapping the helper.
- View: the repo Tag settings page lists inherited org tag rules read-only.

Stacked on #728 (branch-protection PR) for migration ordering — merge #728
first. Swagger annotations omitted (can't regenerate the swagger JSON without
the toolchain); routes still register.

Note: no Go toolchain available locally, so not compiled/gofmt'd/tested here.
Hand-verified: gofmt (tabs, no blank-in-block, struct alignment), template
nesting balances, all .Rule fields exist on OrgProtectedTag, all locale keys
defined, JSON valid, migration contiguous (363).

Claude-Session: https://claude.ai/code/session_01Wsno14cxE49MstXFs9G5KT

jmiller added 3 commits 2026-07-05 04:23:17 +00:00

feat(org): org-level push policy enforced in the pre-receive hook (#727) ... 3aac1b456c

Adds a single per-org push policy that cascades to every repo of the org and is
enforced in the pre-receive hook:

- Branch/tag name conventions (glob) — a pushed ref name must match. Fail-closed.
- Mandatory secret-scanning block-on-push — org can force secret blocking that a
  repo cannot disable (overrides the per-repo scanner config in the orchestrator).
- Max pushed-file size — rejects a tip tree containing a blob over the limit.
- Blocked file-path patterns — rejects pushes changing matching paths (reuses
  pull_service.CheckFileProtection).

The two content checks (blocked paths, max size) FAIL OPEN on any error so a
policy/parsing bug can never wedge all pushes; naming is fail-closed.

- models/git/org_push_policy.go: OrgPushPolicy model + CRUD + matchers +
  GetOrgPushPolicyForRepo. Migration 364.
- API: GET/PATCH/DELETE /orgs/{org}/push_policy (routers/api/v1/org/push_policy.go,
  DTOs in modules/structs/org_push_policy.go, wired in api.go).
- Enforcement: routers/private/hook_pre_receive.go (branch: naming + blocked paths
  + max size; tag: naming) and services/security/orchestrator.go (secret mandate).

Deferred: a repo-facing read-only view of the org push policy (it is an org-wide
config, not per-repo overlay rules; readable via the API for now).

Stacked on #729/#728 for migration ordering (this = 364). Swagger annotations
omitted (can't regenerate without the toolchain).

Note: no Go toolchain available locally, so not compiled/gofmt'd/tested here.
Hand-verified: gofmt (tabs, no blank-in-block), escape sequences in the ls-tree
parser, imports used, migration contiguous (364), fail-open on content checks.

Claude-Session: https://claude.ai/code/session_01Wsno14cxE49MstXFs9G5KT

feat(org): org-level repository defaults applied on repo create/transfer (#727) ... d3134b1c53

Adds a single per-org repository-defaults config, applied to a repo when it is
created in or transferred into the org via a notifier (services/org):

- ForcePrivate — force new/transferred repos private (Repository.IsPrivate).
- PR defaults (when ApplyPRDefaults) — allowed merge styles, default merge
  style, and auto-delete-branch-after-merge, written to the repo's pull-requests
  unit config via repo_service.UpdateRepositoryUnits.

Best-effort: the notifier logs and swallows errors, so a defaults bug can never
break repository creation or transfer.

- models/git/org_repo_defaults.go: OrgRepoDefaults model + CRUD + migration 365.
- API: GET/PATCH/DELETE /orgs/{org}/repo_defaults.
- services/org/notifier.go: CreateRepository/TransferRepository -> apply defaults;
  registered from routers/init.go (org_service.Init()).

Stacked on #730/#729/#728 for migration ordering (this = 365). Swagger omitted.

Note: no Go toolchain available locally, so not compiled/gofmt'd/tested here.
Hand-verified: gofmt (tabs, no blank-in-block, struct/DTO alignment), imports
used, no Init() collision in services/org, migration contiguous (365), notifier
signatures match the Notifier interface.

Claude-Session: https://claude.ai/code/session_01Wsno14cxE49MstXFs9G5KT

feat(org): org-level email domain policy for members (#727) ... 6a3db171c1

Restricts which email domains an organization's members may have. When a policy
is configured, a user can only be added to the org (via any team) if their
primary email matches one of the allowed domain globs.

Enforced at the single membership choke point services/org.AddTeamMember, which
every add path (API, web, group-sync) funnels through — so one check covers them
all. On violation it returns a typed ErrEmailDomainNotAllowed; the API team-add
handler maps it to 422.

- models/git/org_email_domain.go: OrgEmailDomainPolicy model + EmailAllowed
  (domain glob match) + OrgEmailDomainAllowed + typed error + CRUD. Migration 366.
- API: GET/PATCH/DELETE /orgs/{org}/email_domain_policy.
- Enforcement in services/org/team.go; 422 mapping in routers/api/v1/org/team.go.

An empty policy imposes no restriction. This is the one bounded piece of the
"access/security" tier; org 2FA-required and IP allowlists were deliberately NOT
built here — they are cross-cutting enforcement (auth gating / request
middleware) that needs a compiler + tests, not a blind stacked PR.

Stacked on #731/#730/#729/#728 for migration ordering (this = 366). Swagger
omitted.

Note: no Go toolchain available locally, so not compiled/gofmt'd/tested here.
Hand-verified: gofmt (tabs, no blank-in-block), imports (git_model added to the
api team handler, gci order), typed-error detection, migration contiguous (366).

Claude-Session: https://claude.ai/code/session_01Wsno14cxE49MstXFs9G5KT

jmiller force-pushed feat/org-email-domain from f32fe74b12 to 6a3db171c1 2026-07-05 04:23:17 +00:00 Compare

jmiller merged commit aeed197ea5 into dev 2026-07-05 04:34:26 +00:00

jmiller deleted branch feat/org-email-domain 2026-07-05 04:34:28 +00:00

jmiller referenced this pull request 2026-07-05 04:37:45 +00:00

Release: org-wide governance series (#727) — dev → main #733

jmiller referenced this pull request 2026-07-05 06:23:58 +00:00

Expand OpenAPI spec + MCP tooling for org-governance endpoints (#727 series) #738

jmiller referenced this pull request 2026-07-05 21:13:24 +00:00

Auto-add the actions bot to the CI/CD team on org creation (#513) #746

jmiller referenced this pull request 2026-07-05 21:23:49 +00:00

Add a dedicated system API/automation bot account (mokogitea-api) #747

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

Clear labels

breaking-change

Breaking API or behavior change

ci-cd

CI/CD pipeline changes

config

Configuration changes

dependencies

Dependency updates

deploy-failure

Deployment failed

docker

Docker/container changes

documentation

Documentation changes

feature: wiki

Wiki system enhancements

good first issue

Good for newcomers

health-check

Repo health check result

help wanted

Extra attention needed

mokostandards

Related to MokoStandards framework

push-failure

Git push operation failed

security

Security vulnerability or hardening

size/l

200-500 lines changed

size/m

50-200 lines changed

size/s

10-50 lines changed

size/xl

500+ lines changed

size/xs

< 10 lines changed

standards-drift

Deviates from MokoStandards

standards-update

MokoStandards compliance update

sync-failure

Sync or mirror failed

tech-debt

Technical debt and TODO/FIXME items

upstream

upstream

Inherited from upstream Gitea

work-in-progress

Draft or incomplete work

bug

Something is not working

duplicate

This issue or pull request already exists

enhancement

New feature

help wanted

Need some help

invalid

Something is wrong

question

More information is needed

wontfix

This won't be fixed

No labels

Priority -

Type -

Milestone

No items

No Milestone

Assignees

Clear assignees

jmiller (Jonathan Miller) moko-deploy (Moko Deploy Bot)

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: MokoConsulting/MokoGitea-Fork#732