From 522423dc86dc94cd5df7a3218a9a23a215f3fc17 Mon Sep 17 00:00:00 2001 From: Andrew Donkin Date: Tue, 12 Mar 2024 15:12:46 +1300 Subject: [PATCH] 9.20: directDivision --- ref/cardholders.html | 200 +++++++++++++++++++++++++++-- ref/events.html | 32 +++-- ref/rest.html | 242 ++++++++++++++++++++++++++++++++++-- swagger/cardholdersApi.yaml | 33 ++++- swagger/eventsApi.yaml | 15 ++- swagger/restApi.yaml | 12 ++ 6 files changed, 495 insertions(+), 39 deletions(-) diff --git a/ref/cardholders.html b/ref/cardholders.html index 70bbf5d..69582a9 100644 --- a/ref/cardholders.html +++ b/ref/cardholders.html @@ -1090,7 +1090,7 @@

If you prefix id or name with a minus sign (ASCII 45), the sort order is reversed.

There are two very strong reasons to sort by ID:

    -
  1. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. Sorting by ID does not carry that risk.
    2. +
  2. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. This is known as "page drift." Sorting by ID does not carry that risk.
  3. Following a next link is dramatically quicker when sorting by ID.
@@ -1166,6 +1166,24 @@

Search parameters are ANDed together.

+
+
+
directDivision
+
in query
+
+ string[] + +
+
+
+

Restricts items to those whose division is in this list.

+

Unlike division=, it does not follow ancestry.

+

List the IDs of the divisions you are interested in separated by commas. Item IDs are short alphanumeric strings, not URLs.

+

Results are undefined if you provide an ID that is not in the form of a division ID.

+

Search parameters are ANDed together.

+

Added in 9.20.

+
+
description
@@ -3655,7 +3673,7 @@

If you prefix id or name with a minus sign (ASCII 45), the sort order is reversed.

There are two very strong reasons to sort by ID:

    -
  1. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. Sorting by ID does not carry that risk.
    2. +
  2. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. This is known as "page drift." Sorting by ID does not carry that risk.
  3. Following a next link is dramatically quicker when sorting by ID.
@@ -3709,6 +3727,24 @@

Search parameters are ANDed together.

+
+
+
directDivision
+
in query
+
+ string[] + +
+
+
+

Restricts items to those whose division is in this list.

+

Unlike division=, it does not follow ancestry.

+

List the IDs of the divisions you are interested in separated by commas. Item IDs are short alphanumeric strings, not URLs.

+

Results are undefined if you provide an ID that is not in the form of a division ID.

+

Search parameters are ANDed together.

+

Added in 9.20.

+
+
description
@@ -4402,7 +4438,7 @@

If you prefix id or name with a minus sign (ASCII 45), the sort order is reversed.

There are two very strong reasons to sort by ID:

    -
  1. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. Sorting by ID does not carry that risk.
    2. +
  2. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. This is known as "page drift." Sorting by ID does not carry that risk.
  3. Following a next link is dramatically quicker when sorting by ID.
@@ -4458,6 +4494,24 @@

Search parameters are ANDed together.

+
+
+
directDivision
+
in query
+
+ string[] + +
+
+
+

Restricts items to those whose division is in this list.

+

Unlike division=, it does not follow ancestry.

+

List the IDs of the divisions you are interested in separated by commas. Item IDs are short alphanumeric strings, not URLs.

+

Results are undefined if you provide an ID that is not in the form of a division ID.

+

Search parameters are ANDed together.

+

Added in 9.20.

+
+
description
@@ -5016,7 +5070,7 @@

If you prefix id or name with a minus sign (ASCII 45), the sort order is reversed.

There are two very strong reasons to sort by ID:

    -
  1. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. Sorting by ID does not carry that risk.
    2. +
  2. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. This is known as "page drift." Sorting by ID does not carry that risk.
  3. Following a next link is dramatically quicker when sorting by ID.
@@ -5072,6 +5126,24 @@

Search parameters are ANDed together.

+
+
+
directDivision
+
in query
+
+ string[] + +
+
+
+

Restricts items to those whose division is in this list.

+

Unlike division=, it does not follow ancestry.

+

List the IDs of the divisions you are interested in separated by commas. Item IDs are short alphanumeric strings, not URLs.

+

Results are undefined if you provide an ID that is not in the form of a division ID.

+

Search parameters are ANDed together.

+

Added in 9.20.

+
+
description
@@ -5351,7 +5423,7 @@

If you prefix id or name with a minus sign (ASCII 45), the sort order is reversed.

There are two very strong reasons to sort by ID:

    -
  1. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. Sorting by ID does not carry that risk.
    2. +
  2. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. This is known as "page drift." Sorting by ID does not carry that risk.
  3. Following a next link is dramatically quicker when sorting by ID.
@@ -5405,6 +5477,24 @@

Search parameters are ANDed together.

+
+
+
directDivision
+
in query
+
+ string[] + +
+
+
+

Restricts items to those whose division is in this list.

+

Unlike division=, it does not follow ancestry.

+

List the IDs of the divisions you are interested in separated by commas. Item IDs are short alphanumeric strings, not URLs.

+

Results are undefined if you provide an ID that is not in the form of a division ID.

+

Search parameters are ANDed together.

+

Added in 9.20.

+
+
description
@@ -6281,7 +6371,7 @@

If you prefix id or name with a minus sign (ASCII 45), the sort order is reversed.

There are two very strong reasons to sort by ID:

    -
  1. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. Sorting by ID does not carry that risk.
    2. +
  2. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. This is known as "page drift." Sorting by ID does not carry that risk.
  3. Following a next link is dramatically quicker when sorting by ID.
@@ -6335,6 +6425,24 @@

Search parameters are ANDed together.

+
+
+
directDivision
+
in query
+
+ string[] + +
+
+
+

Restricts items to those whose division is in this list.

+

Unlike division=, it does not follow ancestry.

+

List the IDs of the divisions you are interested in separated by commas. Item IDs are short alphanumeric strings, not URLs.

+

Results are undefined if you provide an ID that is not in the form of a division ID.

+

Search parameters are ANDed together.

+

Added in 9.20.

+
+
description
@@ -6815,7 +6923,7 @@

If you prefix id or name with a minus sign (ASCII 45), the sort order is reversed.

There are two very strong reasons to sort by ID:

    -
  1. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. Sorting by ID does not carry that risk.
    2. +
  2. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. This is known as "page drift." Sorting by ID does not carry that risk.
  3. Following a next link is dramatically quicker when sorting by ID.
@@ -6871,6 +6979,24 @@

Search parameters are ANDed together.

+
+
+
directDivision
+
in query
+
+ string[] + +
+
+
+

Restricts items to those whose division is in this list.

+

Unlike division=, it does not follow ancestry.

+

List the IDs of the divisions you are interested in separated by commas. Item IDs are short alphanumeric strings, not URLs.

+

Results are undefined if you provide an ID that is not in the form of a division ID.

+

Search parameters are ANDed together.

+

Added in 9.20.

+
+
description
@@ -7221,7 +7347,7 @@

If you prefix id or name with a minus sign (ASCII 45), the sort order is reversed.

There are two very strong reasons to sort by ID:

    -
  1. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. Sorting by ID does not carry that risk.
    2. +
  2. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. This is known as "page drift." Sorting by ID does not carry that risk.
  3. Following a next link is dramatically quicker when sorting by ID.
@@ -7277,6 +7403,24 @@

Search parameters are ANDed together.

+
+
+
directDivision
+
in query
+
+ string[] + +
+
+
+

Restricts items to those whose division is in this list.

+

Unlike division=, it does not follow ancestry.

+

List the IDs of the divisions you are interested in separated by commas. Item IDs are short alphanumeric strings, not URLs.

+

Results are undefined if you provide an ID that is not in the form of a division ID.

+

Search parameters are ANDed together.

+

Added in 9.20.

+
+
description
@@ -7985,7 +8129,7 @@

If you prefix id or name with a minus sign (ASCII 45), the sort order is reversed.

There are two very strong reasons to sort by ID:

    -
  1. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. Sorting by ID does not carry that risk.
    2. +
  2. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. This is known as "page drift." Sorting by ID does not carry that risk.
  3. Following a next link is dramatically quicker when sorting by ID.
@@ -8041,6 +8185,24 @@

Search parameters are ANDed together.

+
+
+
directDivision
+
in query
+
+ string[] + +
+
+
+

Restricts items to those whose division is in this list.

+

Unlike division=, it does not follow ancestry.

+

List the IDs of the divisions you are interested in separated by commas. Item IDs are short alphanumeric strings, not URLs.

+

Results are undefined if you provide an ID that is not in the form of a division ID.

+

Search parameters are ANDed together.

+

Added in 9.20.

+
+
description
@@ -8200,7 +8362,7 @@

If you prefix id or name with a minus sign (ASCII 45), the sort order is reversed.

There are two very strong reasons to sort by ID:

    -
  1. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. Sorting by ID does not carry that risk.
    2. +
  2. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. This is known as "page drift." Sorting by ID does not carry that risk.
  3. Following a next link is dramatically quicker when sorting by ID.
@@ -8256,6 +8418,24 @@

Search parameters are ANDed together.

+
+
+
directDivision
+
in query
+
+ string[] + +
+
+
+

Restricts items to those whose division is in this list.

+

Unlike division=, it does not follow ancestry.

+

List the IDs of the divisions you are interested in separated by commas. Item IDs are short alphanumeric strings, not URLs.

+

Results are undefined if you provide an ID that is not in the form of a division ID.

+

Search parameters are ANDed together.

+

Added in 9.20.

+
+
description
diff --git a/ref/events.html b/ref/events.html index 3646aa2..2ff1e1b 100644 --- a/ref/events.html +++ b/ref/events.html @@ -1743,7 +1743,7 @@

If you prefix id or name with a minus sign (ASCII 45), the sort order is reversed.

There are two very strong reasons to sort by ID:

    -
  1. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. Sorting by ID does not carry that risk.
    2. +
  2. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. This is known as "page drift." Sorting by ID does not carry that risk.
  3. Following a next link is dramatically quicker when sorting by ID.
@@ -2741,9 +2741,23 @@

-

Restricts events to those in this division (including its child divisions). Separate multiple IDs with commas.

-

Example: division=2,101

-

A more secure option is to set the operator's privileges so that it only has access to those divisions.

+

Restricts events to those in these divisions or their descendants. Separate IDs with commas.

+

Example: division=201,330

+

A more secure option for limiting your client's visibility is to set the operator's privileges so that it only has access to those divisions.

+
+ +
+
+
directDivision
+
in query
+
+ string + +
+
+
+

Restricts events to those whose division is in this list. Unlike division=, it does not follow ancestry. Separate IDs with commas.

+

Example: division=2,101.

@@ -3808,12 +3822,16 @@

division
in query
- string + string[]

-

Only returns items that are in these divisions or their subdivisions. Use the divisions' short alphanumeric IDs, separateed by commas.

+

Limits the returned items to those that are in these divisions.

+

That includes all the items in those divisions' child divisions, because Command Centre treats items as though they are also in their division's parent, and its parent, and so on up to the root division.

+

List the IDs of the divisions you are interested in separated by commas. Item IDs are short alphanumeric strings, not URLs.

+

Results are undefined if you provide an ID that is not in the form of a division ID.

+

Search parameters are ANDed together.

@@ -3863,7 +3881,7 @@

If you prefix id or name with a minus sign (ASCII 45), the sort order is reversed.

There are two very strong reasons to sort by ID:

    -
  1. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. Sorting by ID does not carry that risk.
    2. +
  2. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. This is known as "page drift." Sorting by ID does not carry that risk.
  3. Following a next link is dramatically quicker when sorting by ID.
diff --git a/ref/rest.html b/ref/rest.html index fc1ffe3..86ff6d6 100644 --- a/ref/rest.html +++ b/ref/rest.html @@ -897,7 +897,7 @@

If you prefix id or name with a minus sign (ASCII 45), the sort order is reversed.

There are two very strong reasons to sort by ID:

    -
  1. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. Sorting by ID does not carry that risk.
    2. +
  2. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. This is known as "page drift." Sorting by ID does not carry that risk.
  3. Following a next link is dramatically quicker when sorting by ID.
@@ -953,6 +953,24 @@

Search parameters are ANDed together.

+
+
+
directDivision
+
in query
+
+ string[] + +
+
+
+

Restricts items to those whose division is in this list.

+

Unlike division=, it does not follow ancestry.

+

List the IDs of the divisions you are interested in separated by commas. Item IDs are short alphanumeric strings, not URLs.

+

Results are undefined if you provide an ID that is not in the form of a division ID.

+

Search parameters are ANDed together.

+

Added in 9.20.

+
+
description
@@ -1114,7 +1132,7 @@

If you prefix id or name with a minus sign (ASCII 45), the sort order is reversed.

There are two very strong reasons to sort by ID:

    -
  1. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. Sorting by ID does not carry that risk.
    2. +
  2. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. This is known as "page drift." Sorting by ID does not carry that risk.
  3. Following a next link is dramatically quicker when sorting by ID.
@@ -1170,6 +1188,24 @@

Search parameters are ANDed together.

+
+
+
directDivision
+
in query
+
+ string[] + +
+
+
+

Restricts items to those whose division is in this list.

+

Unlike division=, it does not follow ancestry.

+

List the IDs of the divisions you are interested in separated by commas. Item IDs are short alphanumeric strings, not URLs.

+

Results are undefined if you provide an ID that is not in the form of a division ID.

+

Search parameters are ANDed together.

+

Added in 9.20.

+
+
description
@@ -2758,7 +2794,7 @@

If you prefix id or name with a minus sign (ASCII 45), the sort order is reversed.

There are two very strong reasons to sort by ID:

    -
  1. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. Sorting by ID does not carry that risk.
    2. +
  2. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. This is known as "page drift." Sorting by ID does not carry that risk.
  3. Following a next link is dramatically quicker when sorting by ID.
@@ -2814,6 +2850,24 @@

Search parameters are ANDed together.

+
+
+
directDivision
+
in query
+
+ string[] + +
+
+
+

Restricts items to those whose division is in this list.

+

Unlike division=, it does not follow ancestry.

+

List the IDs of the divisions you are interested in separated by commas. Item IDs are short alphanumeric strings, not URLs.

+

Results are undefined if you provide an ID that is not in the form of a division ID.

+

Search parameters are ANDed together.

+

Added in 9.20.

+
+
description
@@ -4150,7 +4204,7 @@

If you prefix id or name with a minus sign (ASCII 45), the sort order is reversed.

There are two very strong reasons to sort by ID:

    -
  1. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. Sorting by ID does not carry that risk.
    2. +
  2. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. This is known as "page drift." Sorting by ID does not carry that risk.
  3. Following a next link is dramatically quicker when sorting by ID.
@@ -4372,7 +4426,7 @@

If you prefix id or name with a minus sign (ASCII 45), the sort order is reversed.

There are two very strong reasons to sort by ID:

    -
  1. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. Sorting by ID does not carry that risk.
    2. +
  2. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. This is known as "page drift." Sorting by ID does not carry that risk.
  3. Following a next link is dramatically quicker when sorting by ID.
@@ -4428,6 +4482,24 @@

Search parameters are ANDed together.

+
+
+
directDivision
+
in query
+
+ string[] + +
+
+
+

Restricts items to those whose division is in this list.

+

Unlike division=, it does not follow ancestry.

+

List the IDs of the divisions you are interested in separated by commas. Item IDs are short alphanumeric strings, not URLs.

+

Results are undefined if you provide an ID that is not in the form of a division ID.

+

Search parameters are ANDed together.

+

Added in 9.20.

+
+
description
@@ -5004,7 +5076,7 @@

If you prefix id or name with a minus sign (ASCII 45), the sort order is reversed.

There are two very strong reasons to sort by ID:

    -
  1. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. Sorting by ID does not carry that risk.
    2. +
  2. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. This is known as "page drift." Sorting by ID does not carry that risk.
  3. Following a next link is dramatically quicker when sorting by ID.
@@ -5060,6 +5132,24 @@

Search parameters are ANDed together.

+
+
+
directDivision
+
in query
+
+ string[] + +
+
+
+

Restricts items to those whose division is in this list.

+

Unlike division=, it does not follow ancestry.

+

List the IDs of the divisions you are interested in separated by commas. Item IDs are short alphanumeric strings, not URLs.

+

Results are undefined if you provide an ID that is not in the form of a division ID.

+

Search parameters are ANDed together.

+

Added in 9.20.

+
+
description
@@ -5228,7 +5318,7 @@

If you prefix id or name with a minus sign (ASCII 45), the sort order is reversed.

There are two very strong reasons to sort by ID:

    -
  1. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. Sorting by ID does not carry that risk.
    2. +
  2. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. This is known as "page drift." Sorting by ID does not carry that risk.
  3. Following a next link is dramatically quicker when sorting by ID.
@@ -5284,6 +5374,24 @@

Search parameters are ANDed together.

+
+
+
directDivision
+
in query
+
+ string[] + +
+
+
+

Restricts items to those whose division is in this list.

+

Unlike division=, it does not follow ancestry.

+

List the IDs of the divisions you are interested in separated by commas. Item IDs are short alphanumeric strings, not URLs.

+

Results are undefined if you provide an ID that is not in the form of a division ID.

+

Search parameters are ANDed together.

+

Added in 9.20.

+
+
description
@@ -5637,7 +5745,7 @@

If you prefix id or name with a minus sign (ASCII 45), the sort order is reversed.

There are two very strong reasons to sort by ID:

    -
  1. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. Sorting by ID does not carry that risk.
    2. +
  2. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. This is known as "page drift." Sorting by ID does not carry that risk.
  3. Following a next link is dramatically quicker when sorting by ID.
@@ -5693,6 +5801,24 @@

Search parameters are ANDed together.

+
+
+
directDivision
+
in query
+
+ string[] + +
+
+
+

Restricts items to those whose division is in this list.

+

Unlike division=, it does not follow ancestry.

+

List the IDs of the divisions you are interested in separated by commas. Item IDs are short alphanumeric strings, not URLs.

+

Results are undefined if you provide an ID that is not in the form of a division ID.

+

Search parameters are ANDed together.

+

Added in 9.20.

+
+
description
@@ -6834,7 +6960,7 @@

If you prefix id or name with a minus sign (ASCII 45), the sort order is reversed.

There are two very strong reasons to sort by ID:

    -
  1. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. Sorting by ID does not carry that risk.
    2. +
  2. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. This is known as "page drift." Sorting by ID does not carry that risk.
  3. Following a next link is dramatically quicker when sorting by ID.
@@ -6890,6 +7016,24 @@

Search parameters are ANDed together.

+
+
+
directDivision
+
in query
+
+ string[] + +
+
+
+

Restricts items to those whose division is in this list.

+

Unlike division=, it does not follow ancestry.

+

List the IDs of the divisions you are interested in separated by commas. Item IDs are short alphanumeric strings, not URLs.

+

Results are undefined if you provide an ID that is not in the form of a division ID.

+

Search parameters are ANDed together.

+

Added in 9.20.

+
+
description
@@ -7751,7 +7895,7 @@

If you prefix id or name with a minus sign (ASCII 45), the sort order is reversed.

There are two very strong reasons to sort by ID:

    -
  1. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. Sorting by ID does not carry that risk.
    2. +
  2. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. This is known as "page drift." Sorting by ID does not carry that risk.
  3. Following a next link is dramatically quicker when sorting by ID.
@@ -7807,6 +7951,24 @@

Search parameters are ANDed together.

+
+
+
directDivision
+
in query
+
+ string[] + +
+
+
+

Restricts items to those whose division is in this list.

+

Unlike division=, it does not follow ancestry.

+

List the IDs of the divisions you are interested in separated by commas. Item IDs are short alphanumeric strings, not URLs.

+

Results are undefined if you provide an ID that is not in the form of a division ID.

+

Search parameters are ANDed together.

+

Added in 9.20.

+
+
description
@@ -8464,7 +8626,7 @@

If you prefix id or name with a minus sign (ASCII 45), the sort order is reversed.

There are two very strong reasons to sort by ID:

    -
  1. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. Sorting by ID does not carry that risk.
    2. +
  2. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. This is known as "page drift." Sorting by ID does not carry that risk.
  3. Following a next link is dramatically quicker when sorting by ID.
@@ -8520,6 +8682,24 @@

Search parameters are ANDed together.

+
+
+
directDivision
+
in query
+
+ string[] + +
+
+
+

Restricts items to those whose division is in this list.

+

Unlike division=, it does not follow ancestry.

+

List the IDs of the divisions you are interested in separated by commas. Item IDs are short alphanumeric strings, not URLs.

+

Results are undefined if you provide an ID that is not in the form of a division ID.

+

Search parameters are ANDed together.

+

Added in 9.20.

+
+
description
@@ -8967,7 +9147,7 @@

If you prefix id or name with a minus sign (ASCII 45), the sort order is reversed.

There are two very strong reasons to sort by ID:

    -
  1. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. Sorting by ID does not carry that risk.
    2. +
  2. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. This is known as "page drift." Sorting by ID does not carry that risk.
  3. Following a next link is dramatically quicker when sorting by ID.
@@ -9023,6 +9203,24 @@

Search parameters are ANDed together.

+
+
+
directDivision
+
in query
+
+ string[] + +
+
+
+

Restricts items to those whose division is in this list.

+

Unlike division=, it does not follow ancestry.

+

List the IDs of the divisions you are interested in separated by commas. Item IDs are short alphanumeric strings, not URLs.

+

Results are undefined if you provide an ID that is not in the form of a division ID.

+

Search parameters are ANDed together.

+

Added in 9.20.

+
+
description
@@ -9939,7 +10137,7 @@

If you prefix id or name with a minus sign (ASCII 45), the sort order is reversed.

There are two very strong reasons to sort by ID:

    -
  1. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. Sorting by ID does not carry that risk.
    2. +
  2. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is enumerating them. This is known as "page drift." Sorting by ID does not carry that risk.
  3. Following a next link is dramatically quicker when sorting by ID.
@@ -9995,6 +10193,24 @@

Search parameters are ANDed together.

+
+
+
directDivision
+
in query
+
+ string[] + +
+
+
+

Restricts items to those whose division is in this list.

+

Unlike division=, it does not follow ancestry.

+

List the IDs of the divisions you are interested in separated by commas. Item IDs are short alphanumeric strings, not URLs.

+

Results are undefined if you provide an ID that is not in the form of a division ID.

+

Search parameters are ANDed together.

+

Added in 9.20.

+
+
description
diff --git a/swagger/cardholdersApi.yaml b/swagger/cardholdersApi.yaml index dbfb29e..ff308e7 100644 --- a/swagger/cardholdersApi.yaml +++ b/swagger/cardholdersApi.yaml @@ -1473,7 +1473,7 @@ parameters: 1. Sorting by name carries a risk of missing or duplicating objects if your result set spans multiple pages and another operator is editing the database while your REST client is - enumerating them. Sorting by ID does not carry that risk. + enumerating them. This is known as "page drift." Sorting by ID does not carry that risk. 2. Following a `next` link is _dramatically_ quicker when sorting by ID. We _strongly_ recommend sorting by ID. In case you were still in doubt, we will do that by @@ -1555,6 +1555,27 @@ parameters: Search parameters are ANDed together. + directDivision: + name: "directDivision" + in: query + required: false + type: array + items: + type: string + description: | + Restricts items to those whose division is in this list. + + Unlike `division=`, it does not follow ancestry. + + List the IDs of the divisions you are interested in separated by commas. Item IDs are short + alphanumeric strings, not URLs. + + Results are undefined if you provide an ID that is not in the form of a division ID. + + Search parameters are ANDed together. + + Added in 9.20. + description: name: "description" in: query @@ -5685,6 +5706,7 @@ paths: cardholders whose PDF 1315 contains the strings 'nanny' and 'paratrooper'. - $ref: "#/parameters/division" + - $ref: "#/parameters/directDivision" - $ref: "#/parameters/description" - name: accessZone @@ -6459,6 +6481,7 @@ paths: server version; you should set it appropriately for your application. - $ref: "#/parameters/name" - $ref: "#/parameters/division" + - $ref: "#/parameters/directDivision" - $ref: "#/parameters/description" - name: "fields" in: query @@ -6667,6 +6690,7 @@ paths: - $ref: "#/parameters/top" - $ref: "#/parameters/name" - $ref: "#/parameters/division" + - $ref: "#/parameters/directDivision" - $ref: "#/parameters/description" - name: "fields" in: query @@ -6846,6 +6870,7 @@ paths: - $ref: "#/parameters/top" - $ref: "#/parameters/name" - $ref: "#/parameters/division" + - $ref: "#/parameters/directDivision" - $ref: "#/parameters/description" - name: "fields" in: query @@ -6908,6 +6933,7 @@ paths: server version; you should set it appropriately for your application. - $ref: "#/parameters/name" - $ref: "#/parameters/division" + - $ref: "#/parameters/directDivision" - $ref: "#/parameters/description" - name: "fields" in: query @@ -7157,6 +7183,7 @@ paths: server version; you should set it appropriately for your application. - $ref: "#/parameters/name" - $ref: "#/parameters/division" + - $ref: "#/parameters/directDivision" - $ref: "#/parameters/description" - name: "fields" in: query @@ -7320,6 +7347,7 @@ paths: - $ref: "#/parameters/top" - $ref: "#/parameters/name" - $ref: "#/parameters/division" + - $ref: "#/parameters/directDivision" - $ref: "#/parameters/description" - $ref: "#/parameters/pdf_fields" @@ -7380,6 +7408,7 @@ paths: - $ref: "#/parameters/top" - $ref: "#/parameters/name" - $ref: "#/parameters/division" + - $ref: "#/parameters/directDivision" - $ref: "#/parameters/description" - $ref: "#/parameters/reception_fields" @@ -7561,6 +7590,7 @@ paths: - $ref: "#/parameters/top" - $ref: "#/parameters/name" - $ref: "#/parameters/division" + - $ref: "#/parameters/directDivision" - $ref: "#/parameters/description" responses: @@ -7593,6 +7623,7 @@ paths: - $ref: "#/parameters/top" - $ref: "#/parameters/name" - $ref: "#/parameters/division" + - $ref: "#/parameters/directDivision" - $ref: "#/parameters/description" - $ref: "#/parameters/visit_fields" diff --git a/swagger/eventsApi.yaml b/swagger/eventsApi.yaml index 1610b58..477e5d2 100644 --- a/swagger/eventsApi.yaml +++ b/swagger/eventsApi.yaml @@ -1340,7 +1340,12 @@ paths: in: query required: false type: string - description: "Restricts events to those in this division (including its child divisions). Separate multiple IDs with commas.\n\nExample: `division=2,101`\n\nA more secure option is to set the operator's privileges so that it only has access to those divisions." + description: "Restricts events to those in these divisions or their descendants. Separate IDs with commas.\n\nExample: `division=201,330`\n\nA more secure option for limiting your client's visibility is to set the operator's privileges so that it only has access to those divisions." + - name: "directDivision" + in: query + required: false + type: string + description: "Restricts events to those whose division is in this list. Unlike `division=`, it does not follow ancestry. Separate IDs with commas.\n\nExample: `division=2,101`." - name: "relatedItem" in: query required: false @@ -1809,13 +1814,7 @@ paths: parameters: - $ref: "cardholdersApi.yaml#/parameters/name" - - name: "division" - in: query - required: false - type: string - description: | - Only returns items that are in these divisions or their subdivisions. Use the divisions' - short alphanumeric IDs, separateed by commas. + - $ref: "cardholdersApi.yaml#/parameters/division" - name: "type" in: query required: false diff --git a/swagger/restApi.yaml b/swagger/restApi.yaml index 5a4ae70..5222929 100644 --- a/swagger/restApi.yaml +++ b/swagger/restApi.yaml @@ -3043,6 +3043,7 @@ paths: - $ref: "cardholdersApi.yaml#/parameters/top" - $ref: "cardholdersApi.yaml#/parameters/name" - $ref: "cardholdersApi.yaml#/parameters/division" + - $ref: "cardholdersApi.yaml#/parameters/directDivision" - $ref: "cardholdersApi.yaml#/parameters/description" - name: "fields" <<: [*FIELDSDESC_SUM, *ACZFIELDS] @@ -3087,6 +3088,7 @@ paths: - $ref: "cardholdersApi.yaml#/parameters/top" - $ref: "cardholdersApi.yaml#/parameters/name" - $ref: "cardholdersApi.yaml#/parameters/division" + - $ref: "cardholdersApi.yaml#/parameters/directDivision" - $ref: "cardholdersApi.yaml#/parameters/description" - name: "fields" <<: [*FIELDSDESC_SUM, *ACZFIELDS] @@ -3394,6 +3396,7 @@ paths: - $ref: "cardholdersApi.yaml#/parameters/top" - $ref: "cardholdersApi.yaml#/parameters/name" - $ref: "cardholdersApi.yaml#/parameters/division" + - $ref: "cardholdersApi.yaml#/parameters/directDivision" - $ref: "cardholdersApi.yaml#/parameters/description" - name: "fields" <<: [*FIELDSDESC_SUM, *ALZFIELDS] @@ -3720,6 +3723,7 @@ paths: - $ref: "cardholdersApi.yaml#/parameters/top" - $ref: "cardholdersApi.yaml#/parameters/name" - $ref: "cardholdersApi.yaml#/parameters/division" + - $ref: "cardholdersApi.yaml#/parameters/directDivision" - $ref: "cardholdersApi.yaml#/parameters/description" - name: "fields" <<: [*FIELDSDESC_SUM, *DOORFIELDS] @@ -3851,6 +3855,7 @@ paths: - $ref: "cardholdersApi.yaml#/parameters/top" - $ref: "cardholdersApi.yaml#/parameters/name" - $ref: "cardholdersApi.yaml#/parameters/division" + - $ref: "cardholdersApi.yaml#/parameters/directDivision" - $ref: "cardholdersApi.yaml#/parameters/description" - name: "fields" <<: [*FIELDSDESC_SUM, *ELEVATORGROUPCARDHOLDERFIELDS] @@ -3907,6 +3912,7 @@ paths: - $ref: "cardholdersApi.yaml#/parameters/top" - $ref: "cardholdersApi.yaml#/parameters/name" - $ref: "cardholdersApi.yaml#/parameters/division" + - $ref: "cardholdersApi.yaml#/parameters/directDivision" - $ref: "cardholdersApi.yaml#/parameters/description" - name: "fields" <<: [*FIELDSDESC_SUM, *ELEVATORGROUPALLFIELDS] @@ -3995,6 +4001,7 @@ paths: - $ref: "cardholdersApi.yaml#/parameters/top" - $ref: "cardholdersApi.yaml#/parameters/name" - $ref: "cardholdersApi.yaml#/parameters/division" + - $ref: "cardholdersApi.yaml#/parameters/directDivision" - $ref: "cardholdersApi.yaml#/parameters/description" - name: "fields" <<: [*FIELDSDESC_SUM, *FZFIELDS] @@ -4208,6 +4215,7 @@ paths: - $ref: "cardholdersApi.yaml#/parameters/top" - $ref: "cardholdersApi.yaml#/parameters/name" - $ref: "cardholdersApi.yaml#/parameters/division" + - $ref: "cardholdersApi.yaml#/parameters/directDivision" - $ref: "cardholdersApi.yaml#/parameters/description" - name: "fields" <<: [*FIELDSDESC_SUM_810, @@ -4385,6 +4393,7 @@ paths: - $ref: "cardholdersApi.yaml#/parameters/top" - $ref: "cardholdersApi.yaml#/parameters/name" - $ref: "cardholdersApi.yaml#/parameters/division" + - $ref: "cardholdersApi.yaml#/parameters/directDivision" - $ref: "cardholdersApi.yaml#/parameters/description" - name: "fields" <<: [*FIELDSDESC_SUM_810, @@ -4540,6 +4549,7 @@ paths: - $ref: "cardholdersApi.yaml#/parameters/top" - $ref: "cardholdersApi.yaml#/parameters/name" - $ref: "cardholdersApi.yaml#/parameters/division" + - $ref: "cardholdersApi.yaml#/parameters/directDivision" - $ref: "cardholdersApi.yaml#/parameters/description" - name: "fields" <<: [*FIELDSDESC_SUM, *MACROFIELDS] @@ -4624,6 +4634,7 @@ paths: - $ref: "cardholdersApi.yaml#/parameters/top" - $ref: "cardholdersApi.yaml#/parameters/name" - $ref: "cardholdersApi.yaml#/parameters/division" + - $ref: "cardholdersApi.yaml#/parameters/directDivision" - $ref: "cardholdersApi.yaml#/parameters/description" - name: "fields" <<: [*FIELDSDESC_SUM, *OUTPUTFIELDS] @@ -4826,6 +4837,7 @@ paths: - $ref: "cardholdersApi.yaml#/parameters/top" - $ref: "cardholdersApi.yaml#/parameters/name" - $ref: "cardholdersApi.yaml#/parameters/division" + - $ref: "cardholdersApi.yaml#/parameters/directDivision" - $ref: "cardholdersApi.yaml#/parameters/description" - name: "fields" <<: [*FIELDSDESC_SUM_810,