shadcn.io is not affiliated with official shadcn/ui
Workspace Invites Settings Block for Svelte
Join rules for a workspace: a domain rules table with a role menu and approval switch, a form that checks a domain before adding it, a field that tries an email address against the rules, and a queue of join requests to approve or decline.
Installation
Overview
Let admins decide who can walk in and who waits with this workspace invites panel for Svelte with Ark UI. A native table lists the domain rules: for each domain the role people from it join as, in a Native Select, and an approval Switch that says At once or Asks first. A form adds a rule only after checking the domain: it must be a plain domain, not already covered, and the table holds at most six rules, and the one Shine Button adds it. A field tries an email address against the rules and answers in one sentence: casey@example.com would join as Member at once. Below it a queue of join requests shows who is waiting, the role they asked for and the rule that holds them, with Approve and Decline in each row, and Undo once a request is answered. Changes apply on the spot and one status line says what changed and that nobody was emailed. On a phone the rules are cards. It's built from Native Select, Switch, Input, Avatar, Button, Shine Button and Guides, with a CSS entrance only. For a community, a client portal or any product people join from a company address.
FAQ
How do I fill it with my own rules and requests?
Edit RULES (a domain, the role it joins as and whether it asks for approval), REQUESTS (a name, an address, the role they asked for and their state) and JOBS (the roles a rule can give). The sentence under the rules table, the counts, the try-an-address answer and the line under each request are all worked out from those lists, and MAX_RULES is the limit the add form enforces.
How does an address match a rule?
By the domain after the last at sign, compared exactly and without regard to capitals. A rule for example.com does not cover mail.example.com; add that domain as its own rule if you want it. An address with no rule says No rule covers it and needs an invite, and an address that isn't complete yet says so instead of guessing. Requests show the same logic as a line under the name: the rule that holds them, or that no rule covers their domain.
What does the add form refuse?
An empty domain, an address with an at sign in it, anything that isn't a plain domain (spaces, slashes, wildcards or a missing dot), a domain that already has a rule and a seventh rule. Each refusal is a one-line reason under the field, the status line says the rule was not added and focus stays on the field. New rules ask for approval until you turn that off, which is the safe default.
What stays local, and how do I make it real?
Everything. Rules and answers only change the lists in the page; an approved person is not emailed and nobody joins. To make it real, send each change from addRule, changeJob, changeAsk, removeRule and answer to your server, let it send the invitation or the decline, and replace the lists with its answer. Keep the same rules there, since a form in a page can be bypassed.
How does it work with a keyboard and a screen reader?
Tab runs through each rule's role menu, approval switch and Remove, the add form, the try field and each request's buttons. Every control is named for its domain or person ("Joins as, example.com", "Approve Zainab Quartey"). When a button is replaced, as Remove or Approve is, focus moves to the next rule's Remove or to the answer's Undo. A reason under a field is tied to it with aria-describedby, and the status line is the one live region.