Plans with supportsProjectSpecificRoles=true but supportsOrganizationRoles=false
would show project-role badges in the table but have no way to edit them.
Gate solely on supportsProjectSpecificRoles plan flag — no feature flag
needed. Also always fetch orgProjects in page load since it is no longer
conditionally needed.
supportsProjectSpecificRoles only controls the project-specific toggle inside
the edit modal. The Edit role button should show for any plan that supports
org-level roles — use a separate supportsOrgRoles derived from
supportsOrganizationRoles for that. Also add !! coercion for consistency.
Update SDK to @appwrite.io/console@82069e6 which exposes the new flag.
Replace supportsOrganizationRoles with supportsProjectSpecificRoles in
createMember, edit, and members page — org roles and project-specific
roles are now independently gated by their own plan flags.
Resolves critical advisory GHSA-5xrq-8626-4rwp. Updated store.test.ts
to use vi.useFakeTimers/vi.setSystemTime instead of the constructor spy
pattern that Vitest 4 no longer supports.
Keep Database, Storage, Auth, and Functions as nav tiles — icon + label
only. Stats were consistently reported as inaccurate; nav value is
preserved. Mobile layout uses a 2×2 grid instead of a vertical stack.
- New updateOAuth2Server.svelte card in project settings
- Enable/disable toggle, authorization URL, scopes, per-client token
durations with unit selectors, PKCE enforcement
- min={1} on all duration inputs, scopes sent directly to allow clearing
- Add ProjectUpdateOAuth2Server analytics event
Note: awaiting SDK with updateOAuth2Server method and correct enum names
The project list was only fetched after a row appeared, causing a
~1 second blank dropdown. Now the API call fires the instant the
ProjectAccessSelector mounts (when the user switches to "Specific
projects"), so data is ready or in-flight before any interaction.
All rows share a single Promise for unfiltered loads via prefetchPromise;
typed searches still hit the API individually. The generation-counter
race guard still applies so concurrent awaits can't overwrite each other.
Two bugs in the project access selector:
1. Race condition: loadProjects had no cancellation guard. Two in-flight
requests for the same row (e.g. rapid typing) could resolve out of
order, leaving stale results visible. Added a per-row generation
counter — responses are discarded if a newer request has been
dispatched since they were started.
2. Edit-mode UUIDs: when the edit modal opens with a member's existing
project-specific roles, rowOptions starts empty so Input.ComboBox
falls back to displaying the raw projectId. A $effect now eagerly
calls loadProjects for any row that has a projectId but no loaded
options, resolving the label as soon as the dropdown mounts.
When a project was selected in one row, other rows' cached option lists
still included it, allowing duplicate project assignments. Two places
needed cache busting:
- `onProjectSelected(i)`: clears options for all rows except the one
that just made a selection; they reload fresh (with takenIds applied)
on next focus.
- `removeRow(i)`: clears all sibling caches after removal so the
freed-up project reappears in other rows' dropdowns on next open.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Two root causes of the shift were identified and fixed:
1. Melt UI's `usePopper` applies `position: absolute` to the dropdown
via floating-ui after a `tick()` delay. During that one frame the
`ul` was briefly in normal document flow, momentarily growing the
`<dialog>` element and causing a reflow. Pre-setting
`[data-melt-combobox-menu] { position: absolute }` in base.css
removes the element from flow immediately at mount.
2. Melt UI's ComboBox has `preventScroll: true` by default. On open it
calls `removeScroll()` which sets `body.overflow: hidden` and adds
compensatory `padding-right` for the scrollbar width — a body
reflow that shifts the dialog. Pre-setting `data-melt-scroll-lock`
on the body in `modal.svelte` tells Melt UI the lock is already
active so it returns early without touching the body.
Also fix `on:search` on `Input.ComboBox` (which the component never
dispatches) by replacing it with native `oninput`/`onfocusin` handlers
on the wrapper `<div>`, so typed text actually triggers debounced
server-side project search. Projects are now ordered newest-first
(`Query.orderDesc('')`) matching the org projects page.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
The project selector previously loaded up to 100 projects upfront,
silently truncating orgs with more. Replace InputSelect with
Input.ComboBox per row — each row fetches the first 25 projects on
open, then debounces API search as the user types. Already-selected
projects are filtered from each row's results. Removes the orgProjects
prefetch from createMember entirely; edit modal no longer needs a
projects prop.
- Skip the extra listMemberships call for org owners (they always see
all projects), avoiding unnecessary latency on every org page load
- Simplify projectScopeQueries type from ReturnType<typeof Query.equal>[]
to string[]
- Track hasFetchedProjects in createMember to prevent Svelte 5 reactivity
from re-triggering the listProjects fetch when the org has zero projects
(assigning a new [] reference would re-run the effect indefinitely)
Apply BODY_TOOLTIP_MAX_WIDTH and BODY_TOOLTIP_WRAPPER_STYLE to the
+N project roles tooltip so content stays inside bounds and long
project names wrap instead of overflowing.
Members with multiple project-specific roles show the first role badge
inline. Hovering the '+N' badge reveals a tooltip listing all remaining
project roles, keeping the table clean while preserving discoverability.
Instead of wrapping all project-specific role badges in the members
table cell, show only the first badge and a compact '+N' badge for
the remainder — matching the overflow pattern used in tables DB.
When listProjects fails, orgProjects is null. The optional chain on
.projects alone leaves .find() called on undefined, crashing the
table render. Add ?. before .find() to handle this safely.
getScopes without projectId collapses project-specific roles to
org-level scopes, so we query the membership directly to get the real
roles (e.g. project-{id}-developer). Members with project-specific
roles only see the projects they have explicit access to.
Members with project-specific roles (project-{id}-{role}) now only see
the projects they have explicit access to on the org overview page.
Org-level roles (owner, developer, etc.) continue to see all projects.
Harsh Mahajan
harsh mahajan