• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

raystack / frontier / 30254086198
47%
main: 47%

Build:
Build:
LAST BUILD BRANCH: refactor/role-based-org-ownership
DEFAULT BRANCH: main
Ran 27 Jul 2026 09:33AM UTC
Jobs 1
Files 290
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

27 Jul 2026 09:26AM UTC coverage: 46.89% (-0.001%) from 46.891%
30254086198

Pull #1809

github

whoAbhishekSah
refactor(schema): grant org and group access through roles only

The base schema granted most org and group permissions directly through
the owner and member relations, outside roles. Because every membership
write pairs the role with a relation, narrowing a predefined role (e.g.
via the reconcile flow) never restricted real owners: the owner tuple
kept granting everything. The schema generator had the same bypass, so
custom permissions were affected too.

Remove the relation grants so roles become the only path to org and
group permissions:

- base_schema.zed: drop `+ owner` / `+ member` from every permission in
  app/organization and app/group, and delete the now-empty synthetic
  `membership` permission. The relation declarations stay: existing
  tuples still reference them, and membership writes are unchanged.
  Owners lose nothing because the Owner role carries
  app_organization_administer and every permission keeps
  granted->app_organization_administer.
- generator.go: stop adding the org-level owner userset to generated
  custom permissions. The resource-level owner (resource creator) is
  untouched.
- Remove the dead MembershipPermission constants (Go and JS SDK); the
  permission no longer exists in the schema and had no readers.

One behavior change: a principal whose role does not grant read access
no longer gets it for free through the member relation. Org-scoped
roles must list app_organization_get (group roles app_group_get) to see
the resource.

Stopping the relation writes and deleting the existing tuples is a
follow-up; SpiceDB cannot drop a relation while tuples reference it.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Pull Request #1809: refactor(schema): grant org and group access through roles only

18287 of 39000 relevant lines covered (46.89%)

14.33 hits per line

Jobs
ID Job ID Ran Files Coverage
1 30254086198.1 27 Jul 2026 09:33AM UTC 290
46.89
GitHub Action Run
Source Files on build 30254086198
  • Tree
  • List 290
  • Changed 2
  • Source Changed 0
  • Coverage Changed 2
Coverage ∆ File Lines Relevant Covered Missed Hits/Line
  • Back to Repo
  • Pull Request #1809
  • PR Base - main (#30250398128)
  • Delete
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE TRIAL · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc