@wix/agent-skills 1.24.0 → 1.26.0

package/skills/wix-app/references/dashboard-page/DRAFT_TEMPLATE_ROUTER.md

@@ -1,203 +0,0 @@
-# Draft Template — Cases A, B and D (router-wired)
-
-**Applies to [DRAFT_TEMPLATE.md](DRAFT_TEMPLATE.md)'s Cases A, B and D.** All three need `PatternsReactRouter`, because in all three a row opens a page of its own — a panel is not the drill-in ([UX_SUCCESS_MODEL.md](UX_SUCCESS_MODEL.md)). Case A's detail route is read-only (§4); B and D route to a full `EntityPage`. The collection and settings components live in [DRAFT_TEMPLATE.md](DRAFT_TEMPLATE.md); this file covers only what a router adds — the entry file, the app shell, and the detail/entity page.
-
-Every snippet below is copied from the installed `dist/docs/*.md` this session read, not from memory.
-
-## 1. Entry — `location` is manual in a Wix CLI app, and only because the router needs it
-
-`PatternsReactRouter` reads the page location through `container.usePageLocation()`, which only `withDashboard`'s `location` prop feeds — nothing supplies it automatically in a Wix CLI app the way Yoshi BM flow does:
-
-```tsx
-// {feature}.tsx — Case A, B or D
-import { useEffect, useState, type FC } from 'react';
-import { dashboard } from '@wix/dashboard';
-import { WixDesignSystemProvider } from '@wix/design-system';
-import '@wix/design-system/styles.global.css';
-import { {Feature}App } from './{Feature}App';
-
-type PageLocation = Parameters<Parameters<typeof dashboard.observeState>[0]>[1]['pageLocation'];
-
-const Page: FC = () => {
-  const [location, setLocation] = useState<PageLocation | undefined>();
-
-  useEffect(() => {
-    const subscription = dashboard.observeState((_pageParams, environment) => {
-      setLocation(environment.pageLocation);
-    });
-    return () => subscription.disconnect();
-  }, []);
-
-  return (
-    <WixDesignSystemProvider>
-      {location ? <{Feature}App location={location} /> : null}
-    </WixDesignSystemProvider>
-  );
-};
-
-export default Page;
-```
-
-**Skipping this is a runtime-only failure.** Per `PatternsReactRouter`'s own docs: "Nothing catches this before runtime — type checking and bundling both pass, because neither renders the page." `tsc` and `wix build` will not catch a missing `location` — only opening the page in a browser will. This is exactly why [Step 5's Preview](../../SKILL.md#validation) is not optional for Case B/D.
-
-## 2. App shell — provider, router, routes
-
-```tsx
-// {Feature}App.tsx — Case A, B or D
-import { withDashboard } from '@wix/patterns';
-import { WixPatternsProvider } from '@wix/patterns/provider';
-import { PatternsReactRouter, PatternsReactRoute } from '@wix/patterns/router';
-import { {Feature}CollectionPage } from './{Feature}CollectionPage';
-import { {Feature}EntityPage } from './{Feature}EntityPage';
-// Case D only:
-import { {Feature}SettingsPage } from './{Feature}SettingsPage';
-
-export const {Feature}App = withDashboard(() => (
-  <WixPatternsProvider>
-    <PatternsReactRouter>
-      <PatternsReactRoute type="collection" path="/" element={<{Feature}CollectionPage />} />
-      {/* Case B/D — editable record. Case A registers this ONE route instead, with
-          {Feature}DetailPage as the element and no /new route (§4). Either way the
-          type is `editEntity`: it wires back-navigation to the collection. */}
-      <PatternsReactRoute type="editEntity" path="/:id" element={<{Feature}EntityPage />} />
-      {/* Case B/D only — Case A has nothing to create: */}
-      <PatternsReactRoute type="createEntity" path="/new" element={<{Feature}EntityPage />} />
-      {/* Case D only: */}
-      <PatternsReactRoute type="other" path="/settings" element={<{Feature}SettingsPage />} />
-    </PatternsReactRouter>
-  </WixPatternsProvider>
-));
-```
-
-`PatternsReactRoute`'s `type` is one of exactly `"collection" | "createEntity" | "editEntity" | "other"` — no dedicated settings value, so a settings route is `"other"`. Case B: delete the `/settings` route and the import above it — nothing else changes.
-
-`{Feature}CollectionPage` is [DRAFT_TEMPLATE_COLLECTION.md](DRAFT_TEMPLATE_COLLECTION.md)'s component, unchanged; `{Feature}SettingsPage` (Case D) is [DRAFT_TEMPLATE_SETTINGS.md](DRAFT_TEMPLATE_SETTINGS.md).
-
-## 2b. The collection side of the handoff
-
-The router file above registers `/new`; something has to navigate there. All three of these live on
-the collection page, and `usePatternsNavigate` comes from **`@wix/patterns/router`** — not the root
-export, which is where it is easy to reach for it:
-
-```tsx
-import { PrimaryPageButton } from '@wix/patterns';
-import { usePatternsNavigate } from '@wix/patterns/router';
-
-const { navigateToEntityPage } = usePatternsNavigate<{Entity}>();
-const openNew = () => navigateToEntityPage({ path: '/new' }); // no record yet — omit `entity`
-
-// CollectionPage.Header — primaryAction takes an ELEMENT, not a { text, onClick } config:
-<CollectionPage.Header
-  title={{ text: '{Page Title}' }}
-  primaryAction={<PrimaryPageButton text="Add {entity}" onClick={openNew} />}
-/>
-
-// the empty state should offer the same action, and this one IS a config object:
-<CollectionEmptyState title="No {feature} yet" addNewCta={{ text: 'Add {entity}', onClick: openNew }} />
-
-// and a row opens the edit route:
-onRowClick={(item) => navigateToEntityPage({ path: `/${item.id}`, entity: item })}
-```
-
-The two shapes differ on purpose — `primaryAction` is an element, `addNewCta` is `{ text, onClick }`.
-Guessing either costs a compile round.
-
-## 3. Entity page — one component for both `/new` and `/:id`
-
-Full call details (both generics, what `onSave` receives, the `UseEntityPageParams` pick list) are in `<pkgRoot>/dist/docs/useEntityPage.md` — read it before filling in fields. The part specific to this router-based shape:
-
-```tsx
-// {Feature}EntityPage.tsx — Case B or D (sketch — see dist/docs/useEntityPage.md for the full call)
-import { useParams } from 'react-router-dom'; // NOT @wix/patterns/router — PatternsReactRoute wraps react-router-dom's Route, but only exports PatternsReactRoute/PatternsReactRouter/usePatternsNavigate itself
-import { useEntityPage, EntityPage } from '@wix/patterns';
-import { useForm } from '@wix/patterns/form';
-import { fetch{Entity}, save{Entity}, type {Entity} } from './{feature}-api';
-
-// The form's shape is yours to declare, and need not match the saved entity type.
-type {Entity}FormFields = { name: string };
-
-export const {Feature}EntityPage = () => {
-  const { id } = useParams<{ id?: string }>();
-  const form = useForm<{Entity}FormFields>();
-
-  const state = useEntityPage<{Entity}, {Entity}FormFields>({
-    parentPath: '/', // NOT parentPageId — this shape always uses Patterns Router
-    isNewEntity: () => !id, // a getter: the route can change (/new -> /:id after save) while this stays mounted
-    form,
-    fetch: () => (id ? fetch{Entity}(id).then((entity) => ({ entity })) : Promise.resolve({ entity: undefined })),
-    onSave: ({ widgetsFormData }) =>
-      save{Entity}({ id, ...form.getValues(), ...widgetsFormData }).then((updatedEntity) => ({ updatedEntity })),
-  });
-
-  return (
-    <EntityPage state={state}>
-      <EntityPage.Header title={{ text: id ? 'Edit {Entity}' : 'New {Entity}' }} />
-      <EntityPage.Content>
-        <EntityPage.MainContent>{/* form cards — see dist/docs/EntityPage.md */}</EntityPage.MainContent>
-      </EntityPage.Content>
-    </EntityPage>
-  );
-};
-```
-
-`useEntityPage`'s own docs are explicit about both details above: `parentPath` "Must be passed if using Patterns Router" (`parentPageId` is the non-router alternative — irrelevant here, since Case B/D always uses the router), and `isNewEntity` should be "a getter when the route can change while the page stays mounted" — exactly this component's case, since a successful create typically navigates `/new` → `/:newId`.
-
-**`UseEntityPageParams` is a `Pick<>`, so a param missing from it is a compile error, not an ignored prop.** `isNewEntity` is in that list at 1.470.0 and absent before ~1.46x. If it doesn't compile, read the pick list in your installed `dist/types/hooks/useEntityPage.d.ts` and upgrade — deleting the line makes a create route behave as an edit.
-
-## 4. Read-only detail route — Case A
-
-A display-only collection still routes its rows to a page — but not an `EntityPage`, which has no
-read-only mode and still has none at **1.471.0**: `fetch` and `onSave` are both required, and
-`actionsBarConfig` (`saveCta.text`, `cancelCta`) can retext Save but not remove it. It would ship
-two buttons that either do nothing or save a form nobody was offered.
-
-Use a WDS `Page` — what Cairo does itself: `example-bm`'s `DataExtensionEntityViewPage` and
-auto-patterns' `ViewModeEntityPage` are both plain WDS `Page`s, the latter unexported.
-
-```tsx
-// {Feature}DetailPage.tsx — Case A
-import { useEffect, useState } from 'react';
-import { useParams } from 'react-router-dom';
-import { Card, Loader, Page, Text } from '@wix/design-system';
-import { usePatternsNavigate } from '@wix/patterns/router';
-import { fetch{Entity}, type {Entity} } from './{feature}-api';
-
-export const {Feature}DetailPage = () => {
-  const { id } = useParams<{ id: string }>();
-  const { navigateToCollectionPage } = usePatternsNavigate();
-  const [entity, setEntity] = useState<{Entity} | undefined>();
-
-  useEffect(() => {
-    if (id) {
-      fetch{Entity}(id).then(setEntity);
-    }
-  }, [id]);
-
-  return (
-    <Page>
-      {/* The way back is the header's back button — a read-only page has no Cancel. */}
-      <Page.Header
-        title={entity?.name ?? '{Entity}'}
-        showBackButton
-        onBackClicked={() => navigateToCollectionPage({ path: '/' })}
-      />
-      <Page.Content>
-        {entity ? (
-          <Card>
-            <Card.Header title="Details" />
-            <Card.Divider />
-            <Card.Content>
-              <Text>{entity.name}</Text>
-            </Card.Content>
-          </Card>
-        ) : (
-          <Loader />
-        )}
-      </Page.Content>
-    </Page>
-  );
-};
-```
-
-If the request later grows an edit form this becomes §3's `EntityPage`, route type and `onRowClick`
-unchanged — which is why Case A registers `editEntity`, not `other`.

package/skills/wix-app/references/dashboard-page/DRAFT_TEMPLATE_SETTINGS.md

@@ -1,44 +0,0 @@
-# Draft Template — Settings page (Cases C and D)
-
-> Pick your case in [DRAFT_TEMPLATE.md](DRAFT_TEMPLATE.md) first; this page covers Case C or D.
-
-## The settings page
-
-No dedicated toolkit file exists for this yet (unlike Entity/Collection) — the shape, verified against `useSettingsPage.md`:
-
-```tsx
-// {Feature}SettingsPage.tsx — Case C or D
-import { SettingsPage, useSettingsPage, useSettings } from '@wix/patterns';
-import { useForm } from '@wix/patterns/form';
-import { fetch{Feature}Settings, save{Feature}Settings, type {Feature}Settings } from './{feature}-api';
-
-// The form's shape is yours to declare, and need not match the saved settings type —
-// one field per control on the page.
-type {Feature}SettingsFormFields = { reminderHours: number; notifyStaff: boolean };
-
-export const {Feature}SettingsPage = () => {
-  const form = useForm<{Feature}SettingsFormFields>();
-
-  const state = useSettingsPage<{Feature}Settings, {Feature}SettingsFormFields>({
-    form,
-    fetch: () => fetch{Feature}Settings().then((settings) => ({ settings })),
-    onSave: () => save{Feature}Settings(form.getValues()),
-    onCancel: async () => form.reset(),
-    saveSuccessToast: 'Settings saved',
-    saveErrorToast: (err, { retry }) => ({ message: 'Failed to save settings', action: { text: 'Retry', onClick: retry } }),
-  });
-
-  const settings = useSettings<{Feature}Settings, {Feature}SettingsFormFields>(state);
-
-  return (
-    <SettingsPage state={state}>
-      <SettingsPage.Header title={{ text: '{Settings Page Title}' }} />
-      <SettingsPage.Content>
-        <SettingsPage.MainContent>{/* form cards — same field-controller patterns as EntityPage */}</SettingsPage.MainContent>
-      </SettingsPage.Content>
-    </SettingsPage>
-  );
-};
-```
-
-`useSettingsPage`'s params are all required except `saveSuccessToast`/`saveErrorToast`: `form`, `fetch`, `onSave`, `onCancel`. There is no `parentPath`/`parentPageId` — a settings page isn't reached by drilling into a row, so it carries no back-navigation contract, and Case C needs no router at all to reach it (Section 1's entry renders it directly).

package/skills/wix-manage/references/cms/cms-data-operations-extended.md

@@ -1,263 +0,0 @@
----
-name: "CMS Data Operations Extended"
-description: Additional CMS data operations including count, upsert (bulk save), and update by filter patterns.
----
-# CMS Data Operations Extended
-
-This recipe covers additional CMS data operations not included in the basic CRUD recipe.
-
-## Prerequisites
-
-1. Wix CMS enabled on the site
-2. Collections created with data
-3. API access with CMS permissions
-
-## Required APIs
-
-- **Data Items API**: [REST](https://dev.wix.com/docs/api-reference/business-solutions/cms/data-items/introduction)
-
-## Count Data Items
-
-Count items in a collection, optionally with filters.
-
-**Endpoint**: `POST /wix-data/v2/items/count`
-
-**Count All Items**:
-```bash
-curl -X POST \
-'https://www.wixapis.com/wix-data/v2/items/count' \
--H 'Content-Type: application/json' \
--H 'Authorization: <AUTH>' \
--d '{
-  "dataCollectionId": "Products"
-}'
-```
-
-**Response**:
-```json
-{
-  "totalCount": 42
-}
-```
-
-**Count with Filter**:
-```bash
-curl -X POST \
-'https://www.wixapis.com/wix-data/v2/items/count' \
--H 'Content-Type: application/json' \
--H 'Authorization: <AUTH>' \
--d '{
-  "dataCollectionId": "Products",
-  "filter": {
-    "inStock": true
-  }
-}'
-```
-
-**Count with Complex Filter**:
-```json
-{
-  "dataCollectionId": "Products",
-  "filter": {
-    "$and": [
-      { "inStock": true },
-      { "price": { "$gte": 50 } }
-    ]
-  }
-}
-```
-
-## Bulk Save (Upsert)
-
-Insert new items or update existing items in a single operation. This is useful for syncing data.
-
-**Endpoint**: `POST /wix-data/v2/bulk/items/save`
-
-**Request Body**:
-```json
-{
-  "dataCollectionId": "Products",
-  "dataItems": [
-    {
-      "id": "existing-item-id",
-      "data": {
-        "title": "Updated Product",
-        "price": 199.99,
-        "inStock": true
-      }
-    },
-    {
-      "data": {
-        "title": "New Product",
-        "price": 79.99,
-        "inStock": true
-      }
-    }
-  ],
-  "returnEntity": true
-}
-```
-
-### Bulk Save Behavior
-
-| Scenario | Action |
-|----------|--------|
-| No `id` provided | INSERT - Creates new item with generated ID |
-| `id` provided, doesn't exist | INSERT - Creates new item with provided ID |
-| `id` provided, exists | UPDATE - Replaces existing item |
-
-> **Warning**: When updating, the entire item is replaced. Include all fields you want to keep.
-
-## Update by Filter Pattern
-
-Wix CMS doesn't have a direct "update by filter" API. Use this two-step pattern:
-
-### 3.1: Query Items to Update
-
-```bash
-curl -X POST \
-'https://www.wixapis.com/wix-data/v2/items/query' \
--H 'Content-Type: application/json' \
--H 'Authorization: <AUTH>' \
--d '{
-  "dataCollectionId": "Products",
-  "query": {
-    "filter": {
-      "category": "electronics"
-    }
-  }
-}'
-```
-
-### 3.2: Bulk Update Those Items
-
-> **Important**: Use `id` (not `_id`) at the element level. The `data` object should NOT contain `_id`.
-
-```bash
-curl -X POST \
-'https://www.wixapis.com/wix-data/v2/bulk/items/update' \
--H 'Content-Type: application/json' \
--H 'Authorization: <AUTH>' \
--d '{
-  "dataCollectionId": "Products",
-  "dataItems": [
-    {
-      "id": "item-1-from-query",
-      "data": {
-        "title": "Updated Title 1",
-        "price": 99.99,
-        "onSale": true
-      }
-    },
-    {
-      "id": "item-2-from-query",
-      "data": {
-        "title": "Updated Title 2",
-        "price": 149.99,
-        "onSale": true
-      }
-    }
-  ]
-}'
-```
-
-### Alternative: Bulk Patch (Partial Update)
-
-If you only want to update specific fields without replacing the entire item, use Bulk Patch:
-
-**Endpoint**: `POST /wix-data/v2/bulk/items/patch`
-
-> **Important**: This endpoint uses `patches` array with `fieldModifications`, NOT `dataItems`. Do not confuse with bulk update.
-
-```bash
-curl -X POST \
-'https://www.wixapis.com/wix-data/v2/bulk/items/patch' \
--H 'Content-Type: application/json' \
--H 'Authorization: <AUTH>' \
--d '{
-  "dataCollectionId": "Products",
-  "patches": [
-    {
-      "dataItemId": "item-1",
-      "fieldModifications": [
-        {
-          "fieldPath": "onSale",
-          "action": "SET_FIELD",
-          "setFieldOptions": {
-            "value": true
-          }
-        }
-      ]
-    }
-  ]
-}'
-```
-
-> **Common error**: If you get `WDE0080: patches must not be empty`, you sent `dataItems` instead of `patches`. Use the format above.
-
-## Truncate Collection
-
-Remove all items from a collection (dangerous operation).
-
-**Endpoint**: `POST /wix-data/v2/items/truncate`
-
-```bash
-curl -X POST \
-'https://www.wixapis.com/wix-data/v2/items/truncate' \
--H 'Content-Type: application/json' \
--H 'Authorization: <AUTH>' \
--d '{
-  "dataCollectionId": "TestCollection"
-}'
-```
-
-> **Warning**: This permanently deletes ALL items in the collection. Use with extreme caution.
-
-## Aggregate Data
-
-Perform calculations on collection data using a pipeline of sequential stages.
-
-**Endpoint**: `POST /wix-data/v2/items/aggregate-pipeline`
-
-**Count by Category**:
-```bash
-curl -X POST \
-'https://www.wixapis.com/wix-data/v2/items/aggregate-pipeline' \
--H 'Content-Type: application/json' \
--H 'Authorization: <AUTH>' \
--d '{
-  "dataCollectionId": "Products",
-  "pipeline": {
-    "stages": [
-      {
-        "group": {
-          "groupIds": [
-            {"key": "category", "expression": {"fieldPath": "category"}}
-          ],
-          "accumulators": [
-            {
-              "resultFieldName": "count",
-              "sum": {"expression": {"numeric": 1}}
-            }
-          ]
-        }
-      }
-    ]
-  }
-}'
-```
-
-## Operation Comparison
-
-| Operation | Use Case | Behavior |
-|-----------|----------|----------|
-| **Bulk Insert** | Add new items only | Fails if ID exists |
-| **Bulk Update** | Update existing items | Fails if ID doesn't exist, replaces entire item |
-| **Bulk Save** | Upsert (insert or update) | Creates or updates based on ID |
-| **Bulk Patch** | Partial update | Only modifies specified fields |
-
-## Related Documentation
-
-- [Data Items API Reference](https://dev.wix.com/docs/api-reference/business-solutions/cms/data-items/introduction)
-- [CMS Operations Best Practices](cms-data-items-crud.md)
-- [CMS Schema Management](cms-schema-management.md)

package/skills/wix-manage/references/cms/cms-references-and-relationships.md

@@ -1,162 +0,0 @@
----
-name: "CMS References And Relationships"
-description: "Add, replace, or remove items from MULTI_REFERENCE fields. Use insert-references, replace-references, remove-references endpoints. Required for managing multi-reference relationships - these CANNOT be set via regular insert/update/patch operations. Also covers single references and querying with expanded references."
----
-# CMS References & Relationships
-
-> **Standard call shape (every curl below).** The `<AUTH>` placeholder is shorthand for `Authorization: Bearer <TOKEN>` only. Body-bearing requests also need `Content-Type: application/json`.
-
-This recipe covers linking CMS collections together using reference fields.
-
-## Prerequisites
-
-1. Wix CMS enabled on the site
-2. At least two collections to link together
-3. API access with CMS permissions
-
-## Required APIs
-
-- **Collections API**: [REST](https://dev.wix.com/docs/api-reference/business-solutions/cms/collection-management/data-collections/introduction)
-- **Data Items API**: [REST](https://dev.wix.com/docs/api-reference/business-solutions/cms/data-items/introduction)
-
-## Reference Types
-
-| Type | Field Type | Relationship | Example |
-|------|------------|--------------|---------|
-| Single Reference | `REFERENCE` | One-to-one, Many-to-one | Product → Category |
-| Multi-Reference | `MULTI_REFERENCE` | One-to-many, Many-to-many | Product → Tags |
-
-## Add a Single Reference Field
-
-**Endpoint**: `POST /wix-data/v2/collections/create-field`
-
-```bash
-curl -X POST \
-'https://www.wixapis.com/wix-data/v2/collections/create-field' \
--H 'Content-Type: application/json' \
--H 'Authorization: <AUTH>' \
--d '{
-  "dataCollectionId": "Products",
-  "field": {
-    "key": "category",
-    "displayName": "Category",
-    "type": "REFERENCE",
-    "typeMetadata": {
-      "reference": {
-        "referencedCollectionId": "Categories"
-      }
-    }
-  }
-}'
-```
-
-## Add a Multi-Reference Field
-
-**Endpoint**: `POST /wix-data/v2/collections/create-field`
-
-```bash
-curl -X POST \
-'https://www.wixapis.com/wix-data/v2/collections/create-field' \
--H 'Content-Type: application/json' \
--H 'Authorization: <AUTH>' \
--d '{
-  "dataCollectionId": "Products",
-  "field": {
-    "key": "tags",
-    "displayName": "Tags",
-    "type": "MULTI_REFERENCE",
-    "typeMetadata": {
-      "multiReference": {
-        "referencedCollectionId": "Tags",
-        "referencingFieldKey": "products",
-        "referencingDisplayName": "Products"
-      }
-    }
-  }
-}'
-```
-
-## Insert Multi-Reference Links
-
-**Endpoint**: `POST /wix-data/v2/bulk/items/insert-references`
-
-```json
-{
-  "dataCollectionId": "Products",
-  "dataItemReferences": [
-    {
-      "referringItemId": "product-item-id",
-      "referringItemFieldName": "tags",
-      "referencedItemId": "tag-1-item-id"
-    },
-    {
-      "referringItemId": "product-item-id",
-      "referringItemFieldName": "tags",
-      "referencedItemId": "tag-2-item-id"
-    }
-  ],
-  "returnEntity": true
-}
-```
-
-## Replace All References
-
-**Endpoint**: `POST /wix-data/v2/items/replace-references`
-
-```json
-{
-  "dataCollectionId": "Products",
-  "referringItemId": "product-item-id",
-  "referringItemFieldName": "tags",
-  "newReferencedItemIds": ["new-tag-1-id", "new-tag-2-id", "new-tag-3-id"]
-}
-```
-
-> **Note**: To remove all references, pass an empty array for `newReferencedItemIds`.
-
-## Remove References (Bulk)
-
-**Endpoint**: `POST /wix-data/v2/bulk/items/remove-references`
-
-```json
-{
-  "dataCollectionId": "Products",
-  "dataItemReferences": [
-    {
-      "referringItemId": "product-id-1",
-      "referringItemFieldName": "tags",
-      "referencedItemId": "tag-to-remove-id"
-    }
-  ]
-}
-```
-
-## Query with Referenced Items Expanded
-
-**Endpoint**: `POST /wix-data/v2/items/query`
-
-```json
-{
-  "dataCollectionId": "Products",
-  "query": {
-    "filter": {
-      "inStock": true
-    }
-  },
-  "includeReferencedItems": ["category", "tags"]
-}
-```
-
-## Reference Query Operators
-
-| Operator | Description | Example |
-|----------|-------------|---------|
-| `$eq` | Exact match (single reference) | `{ "category": "id" }` |
-| `$hasSome` | Has at least one of | `{ "tags": { "$hasSome": ["id1", "id2"] } }` |
-| `$hasAll` | Has all of | `{ "tags": { "$hasAll": ["id1", "id2"] } }` |
-
-## Related Documentation
-
-- [Data Items API Reference](https://dev.wix.com/docs/api-reference/business-solutions/cms/data-items/introduction)
-- [Collections API Reference](https://dev.wix.com/docs/api-reference/business-solutions/cms/collection-management/data-collections/introduction)
-- [CMS Schema Management Recipe](cms-schema-management.md)