@rebasepro/types 0.10.0 → 0.10.1-canary.0a881d4

package/src/types/security_rules.ts

@@ -0,0 +1,344 @@
+/**
+ * Row-level security rules for a collection.
+ *
+ * 325 lines of RLS policy contract that used to sit in the middle of
+ * `collections.ts`, between the admin panel's table view-models and the auth
+ * collection config. It has no relationship to the shape of a collection — it is
+ * the most-read part of the BaaS surface, and it now reads on its own.
+ *
+ * A rule is compiled to Postgres `CREATE POLICY` DDL and, for the structured
+ * flavour, independently evaluated in JavaScript, so the admin UI's idea of what
+ * a user may do derives from the same expression the database enforces.
+ *
+ * Note that rule *names* are not what you write: an unnamed rule compiles to
+ * `<table>_<op>_<sha1[0:7]>`, plus an injected `default_admin` baseline. Derive
+ * them with `getPolicyNamesForRule`/`getEffectiveSecurityRules` rather than
+ * matching on `rule.name`.
+ */
+import type { PolicyExpression } from "./policy";
+
+/**
+ * SQL operation that a policy applies to.
+ * @group Models
+ */
+export type SecurityOperation = "select" | "insert" | "update" | "delete" | "all";
+
+/**
+ * Flexible Row Level Security rule for a collection.
+ *
+ * Built on PostgreSQL Row Level Security. Rules can range from
+ * simple convenience shortcuts to fully custom SQL expressions, giving you the
+ * full power of PostgreSQL Row Level Security.
+ *
+ * The authenticated user's identity is available in raw SQL via:
+ * - `auth.uid()`   — the user's ID
+ * - `auth.roles()` — comma-separated app role IDs
+ * - `auth.jwt()`   — full JWT claims as JSONB
+ *
+ * These are set automatically per-transaction by the backend.
+ *
+ * **How rules combine:** PostgreSQL evaluates all matching policies for an
+ * operation. Permissive rules are OR'd together (any one passing is enough).
+ * Restrictive rules are AND'd (all must pass). This is standard PostgreSQL RLS behavior.
+ *
+ * **Mutual exclusivity:** `ownerField`, `access`, structured `condition`, and
+ * raw SQL (`using`/`withCheck`) cannot be combined. The type system enforces
+ * this — attempting to set conflicting fields will produce a compile-time
+ * error.
+ *
+ * **Which form to reach for:** prefer the structured {@link StructuredSecurityRule}
+ * (`condition`/`check`) or the shortcuts (`ownerField`, `access`, `roles`). These
+ * are engine-agnostic and evaluated identically by the database and the admin UI,
+ * so the UI never shows an action the database will reject. Raw SQL
+ * ({@link RawSQLSecurityRule}) keeps full PostgreSQL power but is Postgres-only
+ * and server-authoritative (the UI cannot evaluate arbitrary SQL locally).
+ *
+ * @group Models
+ */
+export type SecurityRule =
+    | OwnerSecurityRule
+    | PublicSecurityRule
+    | StructuredSecurityRule
+    | RawSQLSecurityRule
+    | RolesOnlySecurityRule;
+
+/**
+ * Shared fields for all SecurityRule variants.
+ * @group Models
+ */
+export interface SecurityRuleBase {
+    /**
+     * Optional human-readable name for the policy.
+     * If not provided, one will be auto-generated from the table name and operation.
+     * Must be unique per table.
+     *
+     * When using `operations` (array), each generated policy will have the
+     * operation name appended, e.g. `"owner_access_select"`, `"owner_access_update"`.
+     */
+    name?: string;
+
+    /**
+     * Which SQL operation this policy applies to.
+     * Use this when the policy targets a single operation or all operations.
+     *
+     * For multiple specific operations, use `operations` (array) instead.
+     * If neither is specified, defaults to `"all"`.
+     *
+     * @default "all"
+     */
+    operation?: SecurityOperation;
+
+    /**
+     * Array of SQL operations this policy applies to.
+     * The compiler will generate one PostgreSQL policy per operation, sharing
+     * the same configuration.
+     *
+     * This reduces boilerplate when the same rule applies to multiple (but not all)
+     * operations.
+     *
+     * Takes precedence over `operation` (singular) if both are specified.
+     *
+     * @example
+     * // Same rule for select and update
+     * { operations: ["select", "update"], ownerField: "user_id" }
+     *
+     * @example
+     * // Equivalent to operation: "all"
+     * { operations: ["all"], ownerField: "user_id" }
+     */
+    operations?: readonly SecurityOperation[];
+
+    /**
+     * Whether this policy is `"permissive"` (default) or `"restrictive"`.
+     *
+     * - **permissive**: Multiple permissive policies for the same operation are
+     *   OR'd together — if *any* passes, access is granted.
+     * - **restrictive**: Restrictive policies are AND'd with all permissive
+     *   policies — they act as additional gates that *must* also pass.
+     *
+     * This is the standard PostgreSQL RLS model.
+     *
+     * @default "permissive"
+     */
+    mode?: "permissive" | "restrictive";
+
+    /**
+     * **Shortcut.** Restrict this rule to users that have one of these
+     * application-level roles.
+     *
+     * **Important:** These are NOT native PostgreSQL database roles — names
+     * like `public`, `anon` or `authenticated` belong to {@link pgRoles} and
+     * produce a condition no user can satisfy if used here. These are
+     * application roles managed by Rebase, stored as an inline `roles TEXT[]`
+     * column on the users table, and injected into each transaction as
+     * `app.user_roles` — which `auth.roles()` reads.
+     *
+     * There is no roles registry: a role exists once it is assigned to a user.
+     *
+     * Generates a safe array-overlap condition — the user passes if they hold
+     * *any* of the listed roles:
+     *   `string_to_array(auth.roles(), ',') && ARRAY['<role1>', '<role2>']`
+     *
+     * (Note: this is a true set intersection, NOT a regex/substring match, so
+     * a role named `admin` never matches `nonadmin` or `superadmin`.)
+     *
+     * Can be combined with `ownerField`, `access`, `condition`, or raw
+     * `using`/`withCheck`. When combined, the role check is AND'd with the
+     * other condition.
+     *
+     * @example
+     * // Only admins can delete
+     * { operation: "delete", roles: ["admin"] }
+     *
+     * @example
+     * // Admins have unfiltered read access to all rows
+     * { operation: "select", roles: ["admin"], using: "true" }
+     */
+    roles?: readonly string[];
+
+    // ── Advanced: native PostgreSQL role targeting ───────────────────────
+
+    /**
+     * **Advanced.** Native PostgreSQL database roles the policy applies to.
+     *
+     * By default, all generated policies target the `public` role (i.e.
+     * every database connection). This is correct for most setups where
+     * a single database role is used for all connections.
+     *
+     * **Important:** These are NOT the same as the application-level
+     * {@link roles} (admin, editor, viewer, etc.) — those are enforced in the
+     * USING/WITH CHECK clauses via `auth.roles()`. This field controls the
+     * PostgreSQL `TO` clause in `CREATE POLICY ... TO role_name`.
+     *
+     * Use this if you have dedicated PostgreSQL roles (e.g. `app_read`,
+     * `app_write`) and want policies to target specific ones.
+     *
+     * @default ["public"]
+     *
+     * @example
+     * // Only apply this policy when connected as `app_role`
+     * { operation: "select", access: "public", pgRoles: ["app_role"] }
+     */
+    pgRoles?: readonly string[];
+}
+
+/**
+ * Security rule that grants access based on row ownership.
+ * Generates a USING/WITH CHECK clause like: `<column> = auth.uid()`
+ *
+ * Cannot be combined with `using`, `withCheck`, or `access`.
+ *
+ * @example
+ * { operation: "all", ownerField: "user_id" }
+ *
+ * @group Models
+ */
+export interface OwnerSecurityRule extends SecurityRuleBase {
+    /** The property (column) that stores the owner's user ID. */
+    ownerField: string;
+    access?: never;
+    using?: never;
+    withCheck?: never;
+    condition?: never;
+    check?: never;
+}
+
+/**
+ * Security rule that grants unrestricted row access (no row filtering).
+ * Generates `USING (true)`.
+ *
+ * This means "no row-level filter", NOT "anonymous/unauthenticated access".
+ * Authentication is still enforced at the API layer — this only controls which
+ * *rows* authenticated users can see.
+ *
+ * Cannot be combined with `using`, `withCheck`, or `ownerField`.
+ *
+ * @example
+ * // Public read (any authenticated user sees all rows)
+ * { operation: "select", access: "public" }
+ *
+ * @group Models
+ */
+export interface PublicSecurityRule extends SecurityRuleBase {
+    /** Grant unrestricted row access for this operation. */
+    access: "public";
+    ownerField?: never;
+    using?: never;
+    withCheck?: never;
+    condition?: never;
+    check?: never;
+}
+
+/**
+ * Security rule expressed as a structured, engine-agnostic
+ * {@link PolicyExpression}. This is the **recommended** way to write a
+ * non-trivial condition: it compiles to PostgreSQL `USING`/`WITH CHECK` SQL
+ * *and* is evaluated identically by the admin UI, so the UI can never show an
+ * action the database will reject.
+ *
+ * Cannot be combined with `ownerField`, `access`, or raw `using`/`withCheck`.
+ *
+ * @example
+ * // Owner, or any user holding the `moderator` role
+ * {
+ *   operation: "update",
+ *   condition: policy.or(
+ *       policy.compare(policy.field("user_id"), "eq", policy.authUid()),
+ *       policy.rolesOverlap(["moderator"])
+ *   )
+ * }
+ *
+ * @group Models
+ */
+export interface StructuredSecurityRule extends SecurityRuleBase {
+    /**
+     * Structured condition for the `USING` clause — which *existing* rows are
+     * visible / can be modified / deleted (SELECT, UPDATE, DELETE).
+     */
+    condition: PolicyExpression;
+
+    /**
+     * Structured condition for the `WITH CHECK` clause — which *new/updated*
+     * row values are allowed (INSERT, UPDATE). Defaults to `condition` when
+     * omitted, mirroring PostgreSQL's own behavior.
+     */
+    check?: PolicyExpression;
+
+    ownerField?: never;
+    access?: never;
+    using?: never;
+    withCheck?: never;
+}
+
+/**
+ * Security rule using raw SQL expressions for full PostgreSQL RLS power.
+ *
+ * **Postgres-only and server-authoritative.** Arbitrary SQL cannot be
+ * evaluated by the admin UI, so a rule using this form is treated as *unknown*
+ * client-side (never silently allowed) and its effect on visible actions is
+ * reflected from the server. For conditions that should also drive the UI
+ * precisely, prefer the structured {@link StructuredSecurityRule}.
+ *
+ * Cannot be combined with `ownerField`, `access`, or structured `condition`.
+ *
+ * You can reference columns via `{column_name}` which will be resolved to
+ * `table.column_name` in the generated Drizzle code.
+ *
+ * @example
+ * // Rows published in the last 30 days are visible
+ * { operation: "select", using: "{published_at} > now() - interval '30 days'" }
+ *
+ * @example
+ * // Only the owner, or users with 'moderator' role
+ * {
+ *   operation: "select",
+ *   using: "{user_id} = auth.uid() OR auth.roles() ~ 'moderator'"
+ * }
+ *
+ * @group Models
+ */
+export interface RawSQLSecurityRule extends SecurityRuleBase {
+    /**
+     * Raw SQL expression for the `USING` clause.
+     * This controls which *existing* rows are visible / can be modified / deleted.
+     * Applied to SELECT, UPDATE, and DELETE.
+     */
+    using: string;
+
+    /**
+     * Raw SQL expression for the `WITH CHECK` clause.
+     * This controls which *new/updated* row values are allowed.
+     * Applied to INSERT and UPDATE.
+     *
+     * If not provided on INSERT/UPDATE policies, falls back to `using`
+     * (which matches PostgreSQL's own default behavior).
+     */
+    withCheck?: string;
+
+    ownerField?: never;
+    access?: never;
+    condition?: never;
+    check?: never;
+}
+
+/**
+ * Security rule that only filters by application roles, without any
+ * row-level condition (USING/WITH CHECK).
+ *
+ * Useful for simple "only admins can access this table" rules where
+ * no per-row filtering is needed.
+ *
+ * @example
+ * // Only admins can delete
+ * { operation: "delete", roles: ["admin"] }
+ *
+ * @group Models
+ */
+export interface RolesOnlySecurityRule extends SecurityRuleBase {
+    ownerField?: never;
+    access?: never;
+    using?: never;
+    withCheck?: never;
+    condition?: never;
+    check?: never;
+}

package/src/types/storage_authorize.ts

@@ -0,0 +1,77 @@
+/**
+ * The storage access-control contract.
+ *
+ * Lives here rather than in `@rebasepro/server` because a project declares its
+ * `storageAuthorize` hook from its **config package**, and a config package
+ * depends on `@rebasepro/types` alone. A type the contract requires but the
+ * contract's author cannot import is not much of a contract.
+ *
+ * `@rebasepro/server` re-exports all of this, so existing imports keep working.
+ */
+
+export type StorageOperation = "read" | "write" | "delete" | "list";
+
+/** The caller, as resolved by whichever auth middleware ran. */
+export interface StorageAuthorizeUser {
+    uid: string;
+    email?: string;
+    roles?: string[];
+}
+
+export interface StorageAuthorizeContext {
+    /** Object key, bucket prefix stripped and traversal already sanitized. */
+    key: string;
+    bucket: string;
+    operation: StorageOperation;
+    /** Null when the route allows unauthenticated access. */
+    user: StorageAuthorizeUser | null;
+    /** Named backend the request targeted, when one was given. */
+    storageId?: string;
+    /**
+     * Trusted, RLS-bypassing data access, so the hook can answer the question it
+     * actually has to answer: *who owns this object?*
+     *
+     * Without it the hook can only do prefix arithmetic on the key, which
+     * expresses no real multi-tenant rule — ownership lives in a row, not in a
+     * string. And it cannot simply import the server to get one: a project
+     * declares this hook from its **config** package, which depends on
+     * `@rebasepro/types` alone and cannot resolve `@rebasepro/server` at
+     * runtime. So the accessor is handed in.
+     *
+     * It bypasses row-level security on purpose. The hook IS the authorization
+     * decision; asking it to make that decision through a reader that has
+     * already been narrowed by the caller's own permissions is circular.
+     */
+    data?: StorageAuthorizeData;
+}
+
+/**
+ * The slice of the data API a storage hook needs: read a collection, in the
+ * trusted server context.
+ *
+ * Deliberately read-only and deliberately tiny. A hook that can write is a hook
+ * that can be tricked into writing, and an authorization check has no business
+ * mutating anything.
+ */
+export interface StorageAuthorizeData {
+    collection(slug: string): {
+        find(query?: Record<string, unknown>): Promise<{ data: Record<string, unknown>[] }>;
+        findById(id: string): Promise<Record<string, unknown> | null>;
+    };
+}
+
+/**
+ * Per-object access control for storage, the analogue of an RLS policy on a
+ * collection.
+ *
+ * Without it, storage routes authenticate but do not authorize: `requireAuth`
+ * and `publicRead` are global switches, so any signed-in user could read any
+ * key they could name. That is fine for a single-tenant app and useless for a
+ * multi-tenant one, where the only thing separating two tenants' files would be
+ * key unguessability — not an access-control model. Multi-tenant apps were
+ * left to route every byte through a custom function to get an ownership check
+ * in, and each of them had to invent it.
+ *
+ * Return false (or throw) to deny. Denials surface as 403.
+ */
+export type StorageAuthorize = (ctx: StorageAuthorizeContext) => boolean | Promise<boolean>;

package/dist/controllers/analytics_controller.d.ts

@@ -1,7 +0,0 @@
-export type AnalyticsController = {
-    /**
-     * Callback used to get analytics events from the CMS
-     */
-    onAnalyticsEvent?: (event: AnalyticsEvent, data?: object) => void;
-};
-export type AnalyticsEvent = "entity_click" | "entity_click_from_reference" | "reference_selection_clear" | "reference_selection_toggle" | "reference_selected_single" | "reference_selection_new_entity" | "edit_entity_clicked" | "entity_edited" | "new_entity_click" | "new_entity_saved" | "copy_entity_click" | "entity_copied" | "single_delete_dialog_open" | "multiple_delete_dialog_open" | "single_entity_deleted" | "multiple_entities_deleted" | "drawer_navigate_to_home" | "drawer_navigate_to_collection" | "drawer_navigate_to_view" | "home_navigate_to_collection" | "home_favorite_navigate_to_collection" | "home_navigate_to_view" | "home_navigate_to_admin_view" | "home_favorite_navigate_to_view" | "home_move_card" | "home_move_group" | "home_drop_new_group" | "collection_inline_editing" | "view_mode_changed" | "kanban_card_moved" | "kanban_column_reorder" | "kanban_property_changed" | "kanban_new_entity_in_column" | "kanban_backfill_order" | "card_view_entity_click" | "unmapped_event";

package/dist/controllers/auth.d.ts

@@ -1,110 +0,0 @@
-import type { User } from "../users";
-/**
- * Capabilities advertised by an auth provider.
- * UI components use this to show/hide features dynamically
- * (e.g. password reset, registration, session management).
- * @group Hooks and utilities
- */
-export interface AuthCapabilities {
-    emailPasswordLogin?: boolean;
-    googleLogin?: boolean;
-    registration?: boolean;
-    /** Self-service password reset (emailing a reset link) is available. */
-    passwordReset?: boolean;
-    /**
-     * An admin can reset another user's password. Gates the "Reset Password"
-     * entity action in the admin UI. See `AuthAdapterCapabilities`.
-     */
-    adminPasswordReset?: boolean;
-    sessionManagement?: boolean;
-    profileUpdate?: boolean;
-    emailVerification?: boolean;
-    /** List of enabled OAuth provider IDs (e.g. ["google", "github", "discord"]) */
-    enabledProviders?: string[];
-}
-/**
- * Controller for retrieving the logged user or performing auth related operations.
- * Note that if you are implementing your AuthController, you probably will want
- * to do it as the result of a hook.
- * @group Hooks and utilities
- */
-export type AuthController<USER extends User = User, ExtraData = unknown> = {
-    /**
-     * The user currently logged in
-     * The values can be: the user object, null if they skipped login
-     */
-    user: USER | null;
-    /**
-     * Initial loading flag. It is used not to display the login screen
-     * when the app first loads, and it has not been checked whether the user
-     * is logged in or not.
-     */
-    initialLoading?: boolean;
-    /**
-     * Loading flag. It is used to display a loading screen when the user is
-     * logging in or out.
-     */
-    authLoading: boolean;
-    /**
-     * Sign out
-     */
-    signOut: () => Promise<void>;
-    /**
-     * Error initializing the authentication
-     */
-    authError?: unknown;
-    /**
-     * Error dispatched by the auth provider
-     */
-    authProviderError?: unknown;
-    /**
-     * You can use this method to retrieve the auth token for the current user.
-     */
-    getAuthToken: () => Promise<string>;
-    /**
-     * Has the user skipped the login process
-     */
-    loginSkipped: boolean;
-    extra: ExtraData;
-    setExtra: (extra: ExtraData) => void;
-    setUser?(user: USER | null): void;
-    setUserRoles?(roles: string[]): void;
-    /**
-     * Capabilities advertised by the auth provider.
-     * UI components use this to feature-detect what the backend supports.
-     */
-    capabilities?: AuthCapabilities;
-};
-/**
- * Extended auth controller with common optional auth methods.
- * Backend implementations (Rebase backend, Firebase, etc.)
- * extend this with their own backend-specific extras.
- * @group Hooks and utilities
- */
-export interface AuthControllerExtended<USER extends User = User, ExtraData = unknown> extends AuthController<USER, ExtraData> {
-    /** Login with email and password */
-    emailPasswordLogin?(email: string, password: string): Promise<void>;
-    /** Login with Google — accepts an ID token, access token, or authorization code payload */
-    googleLogin?: (payload: {
-        idToken: string;
-    } | {
-        accessToken: string;
-    } | {
-        code: string;
-        redirectUri: string;
-    }) => Promise<void>;
-    /** Generic OAuth login — works with any provider. Posts payload to /auth/{providerId}. */
-    oauthLogin?: (providerId: string, payload: Record<string, unknown>) => Promise<void>;
-    /** Register a new user */
-    register?(email: string, password: string, displayName?: string): Promise<void>;
-    /** Skip login (for anonymous access if enabled) */
-    skipLogin?(): void;
-    /** Request password reset email */
-    forgotPassword?(email: string): Promise<void>;
-    /** Reset password using a token */
-    resetPassword?(token: string, password: string): Promise<void>;
-    /** Change password for the authenticated user */
-    changePassword?(oldPassword: string, newPassword: string): Promise<void>;
-    /** Update user profile */
-    updateProfile?(displayName?: string, photoURL?: string): Promise<USER>;
-}

package/dist/controllers/customization_controller.d.ts

@@ -1,61 +0,0 @@
-import type { EntityLinkBuilder } from "../types/entity_link_builder";
-import type { Locale } from "../types/locales";
-import type { EntityAction } from "../types/entity_actions";
-import type { EntityCustomView } from "../types/entity_views";
-import type { RebasePlugin } from "../types/plugins";
-import type { PropertyConfig } from "../types/property_config";
-import type { SlotContribution } from "../types/slots";
-import type { ComponentOverrideMap } from "../types/component_overrides";
-export type CustomizationController = {
-    /**
-     * Builder for generating utility links for entities
-     */
-    entityLinkBuilder?: EntityLinkBuilder;
-    /**
-     * Use plugins to modify the behaviour of the CMS.
-     */
-    plugins?: RebasePlugin[];
-    /**
-     * Pre-merged slots from plugins + direct slot contributions.
-     */
-    resolvedSlots: SlotContribution[];
-    /**
-     * List of additional custom views for entities.
-     * You can use the key to reference the custom view in
-     * the `entityViews` prop of a collection.
-     *
-     * You can also define a entity view from the UI.
-     */
-    entityViews?: EntityCustomView[];
-    /**
-     * List of actions that can be performed on entities.
-     * These actions are displayed in the entity view and in the collection view.
-     * You can later reuse these actions in the `entityActions` prop of a collection,
-     * by specifying the `key` of the action.
-     */
-    entityActions?: EntityAction[];
-    /**
-     * Format of the dates in the CMS.
-     * Defaults to 'MMMM dd, yyyy, HH:mm:ss'
-     */
-    dateTimeFormat?: string;
-    /**
-     * Locale of the CMS, currently only affecting dates
-     */
-    locale?: Locale;
-    /**
-     * Record of custom form fields to be used in the CMS.
-     * You can use the key to reference the custom field in
-     * the `propertyConfig` prop of a property in a collection.
-     */
-    propertyConfigs: Record<string, PropertyConfig>;
-    /**
-     * Global component overrides. Keys are component names from
-     * {@link OverridableComponentName}. Values replace the default
-     * implementation everywhere in the app.
-     *
-     * Collection-scoped overrides (set on individual collections)
-     * take precedence over global overrides.
-     */
-    components?: ComponentOverrideMap;
-};

package/dist/controllers/dialogs_controller.d.ts

@@ -1,36 +0,0 @@
-import React from "react";
-/**
- * Controller to open the side dialog
- * @group Hooks and utilities
- */
-export interface DialogsController {
-    /**
-     * Close the last dialog
-     */
-    close: () => void;
-    /**
-     * Open a dialog
-     * @param props
-     */
-    open: <T extends object = object>(props: DialogControllerEntryProps<T>) => {
-        closeDialog: () => void;
-    };
-}
-/**
- * Props used to open a side dialog
- * @group Hooks and utilities
- */
-export interface DialogControllerEntryProps<T extends object = object> {
-    key: string;
-    /**
-     * The component type that will be rendered
-     */
-    Component: React.ComponentType<{
-        open: boolean;
-        closeDialog: () => void;
-    } & T>;
-    /**
-     * Props to pass to the dialog component
-     */
-    props?: T;
-}

package/dist/controllers/local_config_persistence.d.ts

@@ -1,20 +0,0 @@
-import type { CollectionConfig } from "../types/collections";
-/**
- * @group Models
- */
-export type PartialCollectionConfig<M extends Record<string, unknown> = Record<string, unknown>> = Partial<CollectionConfig<M>>;
-/**
- * This interface is in charge of defining the controller that persists
- * modifications to a collection or collection, and retrieves them back from
- * a data source, such as local storage or Firestore.
- */
-export interface UserConfigurationPersistence {
-    onCollectionModified: <M extends Record<string, unknown> = Record<string, unknown>>(path: string, partialCollection: PartialCollectionConfig<M>) => void;
-    getCollectionConfig: <M extends Record<string, unknown> = Record<string, unknown>>(path: string) => PartialCollectionConfig<M>;
-    recentlyVisitedPaths: string[];
-    setRecentlyVisitedPaths: (paths: string[]) => void;
-    favouritePaths: string[];
-    setFavouritePaths: (paths: string[]) => void;
-    collapsedGroups: string[];
-    setCollapsedGroups: (paths: string[]) => void;
-}