Basic CRUD Operations and Public Groups (Phase 1)

[keithmanville]

The first phase implements minimal functionality in order to enable basic “namespacing” within Dioptra. It would allow us to benefit in multi-user deployments so users can avoid conflicting resources with other users. At this point no permissions are enabled and users will have access to all groups that are created.

REST API:

Enable basic CRUD operations on groups
POST /groups/
PUT /groups/{id}
DELETE /groups/{id}
What should this mean? All resources inaccessible? Cascading locks?
When a user is created, they are added to all groups
When a group is created, all members are added
The creator is added as the GroupManager Owner role
This is done for tracking purposes only, so that groups can be managed once additional features are added
When a group is created, the basic parameter types are added
The public group that is created by default is special and cannot be deleted or modified
Consider implementing this with a “public” boolean on the group instead of managing users.
Constrain group names by “user id” + “name” which can be displayed as “username:groupname”

Frontend:

The frontend will be updated to include filtering by group by default. The user will have a current “group context” under which all of their actions will take place. This will be selected using the existing Groups dropdown in the top right. The current group context should be saved as a cookie.
All forms will be updated to remove group drop down selectors.
The Groups page will allow users to create groups.
There should be a warning stating that all future users have access to the group.

Blockers:

None

[keithmanville]

Phase 1 Groups Implementation Plan:

• Define scope and invariants

  • Introduce a public flag on groups.
  • Enforce public-only creation for this phase (reject public=false).
  • Preserve one protected default public group identified by group_id == 1.
  • Use creator-scoped group-name uniqueness: (user_id, group_name).
  • Keep /groups global (not filtered by selected frontend group context).
  • Make selected frontend group drive groupId for most other read/list APIs.

• Database + model changes

  • Add groups.public column with default true.
  • Add migration to:
    • create public column,
    • backfill existing groups as public,
    • enforce unique index on (groups.user_id, groups.name).
  • Update ORM model so public is constructor-provided (public=True/False accepted), while still defaulting to true.

• Repository-layer changes

  • Move uniqueness checks to creator-scoped lookup (renamed to get_by_name_and_user).
  • Add accessible-groups lookup get_all_for_user(user_id) returning:
    • groups where user is member or
    • groups with public=true,
    • deduped and ordered.
  • Add centralized child-association ownership guard:
    • prevent linking parent/child resources across different owner groups.
  • Apply this guard in shared resource operations:
    • create/create-snapshot checks,
    • set_resource_children,
    • append_resource_children.

• Service/controller changes for Groups

  • Ensure group create uses current_user from controller, not caller-provided creator.
  • Enforce public-only create in service:
    • if public=false, raise validation error,
    • persist as public=true.
  • Protect default group (group_id == 1) from modify/delete.
  • On group create:
    • auto-create creator membership with full perms,
    • auto-create creator manager role with owner/admin perms,
    • create builtin plugin parameter types for new group.
  • On group delete:
    • soft-delete group,
    • also soft-delete owned resources by adding delete locks in same transaction.

• User/current behavior changes

  • Redefine /users/current.groups semantics from “membership only” to “accessible groups”.
  • Build response groups from group_repo.get_all_for_user(...).
  • Keep schema shape unchanged; update schema wording to reflect accessible groups.

• Authorization policy update for public groups

  • Introduce centralized “member OR public” write-access check in repository utils.
  • Use it for:
    • resource create,
    • resource snapshot create,
    • draft resource create,
    • draft modification create.
  • Keep strict membership-only where required by invariant:
    • group_repo.add_manager still requires user is already a member.

• Cross-group association hardening

  • Add dedicated exception: CrossGroupResourceAssociationError.
  • Enforce same-owner-group constraint for resource associations at repository utility layer.
  • Block cases like:
    • experiment linked to entrypoint in another group,
    • similar parent/child cross-group links in repo-backed paths.

• Frontend group context + UX updates

  • Add persisted selected group state in LoginStore with dioptra_group_id.
  • Add setGroups and setLoggedInGroup, and navbar dropdown switching.
  • Add dedicated Groups create page (/groups/new) and route from Groups list.
  • Create form includes disabled checked Public checkbox and submits public.
  • Remove most manual group selectors from forms; use selected logged-in group context.
  • Add first-pass centralized groupId propagation in dataApi.getData(...) for non-groups item types.
  • Keep /groups requests intentionally global.
  • Update Groups page display logic to show public groups broadly (and public-permissions presentation behavior).

• Tests and validation strategy

  • Update/expand repository and v1 tests to match new behavior:
    • group public field expectations,
    • protected default-group behavior,
    • creator-scoped uniqueness,
    • non-public create rejection,
    • membership-or-public create/draft behavior,
    • cross-group association rejection.
  • Remove outdated @pytest.mark.v1_test tags where requested.
  • Keep status code assertions aligned (409 for duplicate conflicts).
  • Run focused suites repeatedly during each change wave:
    • group repository + v1 group,
    • user current-group behavior,
    • queue/type/experiment/drafts/group repositories,
    • frontend npm run type-check.

• Key design decisions captured

  • Protected default group is hard-identified by group_id == 1.
  • Public-group write access is allowed for create/snapshot/draft operations.
  • Manager assignment remains strict membership invariant.
  • Cross-group parent/child associations are disallowed centrally at repository utils.
  • /users/current.groups returns accessible groups to power frontend group dropdown and context.