couchbase · ibsoln · Feb 11, 2022 · Feb 11, 2022
diff --git a/modules/ROOT/assets/attachments/configuration-properties-legacy.yaml b/modules/ROOT/assets/attachments/configuration-properties-legacy.yaml
@@ -7,7 +7,7 @@ properties:
     type: boolean
     default: 'true'
     description: |+
-      Use `admin_interface_authentication=false` to turn of the secure remote administration feature introduced in 3.0 BETA.
+      Use `admin_interface_authentication=false` to turn of the secure remote administration feature introduced in 3.0.
 
       This is on by default and requires Couchbase Server RBAC-users to authenticate Admin API access.
   adminUI:
@@ -30,7 +30,7 @@ properties:
     type: boolean
     default: 'true'
     description: |+
-      Use `metrics_interface_authentication=false` to turn of the secure remote administration feature introduced in 3.0 BETA.
+      Use `metrics_interface_authentication=false` to turn of the secure remote administration feature introduced in 3.0.
 
       This is on by default and requires Couchbase Server RBAC-users to authenticate Metrics API access.
 
@@ -893,7 +893,7 @@ properties:
 
               **Options**
 
-              Your replications can be one of two available types -- see [replication types](./../learn/icr-replication-types.html) (not available in beta)
+              Your replications can be one of two available types -- see [replication types](./../learn/icr-replication-types.html
 
               - Persistent -- the replication survives node restarts. These replications can also be launched dynamically using the Rest API `_replication` endpoint (see -- [Admin Rest API](./../refer/rest-api-admin.html))
 
@@ -1340,7 +1340,7 @@ properties:
     type: boolean
     default: 'false'
     description: |+
-      Set to true to disable the persistent configuration handling introduced in 3.0 BETA
+      Set to true to disable the persistent configuration handling introduced in 3.0
   facebook:
     description: Configuration for Facebook Login authentication.
     type: object

diff --git a/modules/ROOT/pages/_partials/_page-index.adoc b/modules/ROOT/pages/_partials/_page-index.adoc
@@ -445,7 +445,7 @@ endif::xref--pfx-sgw[]
 :configuration-schema-database--pfx--oidc: {configuration-schema-database--pfx--db}-oidc
 :configuration-schema-database--pfx--eventhandlers-doc-changed: {configuration-schema-database--pfx--eventhandlers}-document_changed
 
-// :configuration-schema-database--xref: {configuration-schema-database--pfx}[Legacy Pre-3.0 BETA Configuration]
+// :configuration-schema-database--xref: {configuration-schema-database--pfx}[Legacy Pre-3.0 Configuration]
 
 :configuration-schema-database--xref--allow-conflicts: {configuration-schema-database--pfx--db}-allow_conflicts[allow_conflicts]
 :configuration-schema-database--xref--bucket: {configuration-schema-database--pfx--db}-bucket[database_bucket]
@@ -520,7 +520,7 @@ endif::xref--pfx-sgw[]
 :configuration-properties-legacy--pfx--databases-oidc: {configuration-properties-legacy--pfx--db}-this_db-oidc
 :configuration-properties-legacy--pfx--eventhandlers-doc-changed: {configuration-properties-legacy--pfx--eventhandlers}-document_changed
 
-:configuration-properties-legacy--xref: {configuration-properties-legacy--pfx}[Legacy Pre-3.0 BETA Configuration]
+:configuration-properties-legacy--xref: {configuration-properties-legacy--pfx}[Legacy Pre-3.0 Configuration]
 
 // :configuration-properties-legacy--xref-use_tls_sever: {configuration-properties-legacy--pfx}#use_tls_sever[use_tls_sever]
 :configuration-properties-legacy--xref-disable-persistent-config: {configuration-properties-legacy--pfx}#disable_persistent_config[disable-persistent-config]

diff --git a/modules/ROOT/pages/_partials/_related-content.adoc b/modules/ROOT/pages/_partials/_related-content.adoc
@@ -53,7 +53,7 @@
   * xref:configuration-schema-access-control.adoc[Access Control]
   * xref:configuration-schema-import-filter.adoc[Import Filter]
   * xref:configuration-schema-isgr.adoc[Inter-Sync{nbsp}Gateway Replication]
-  * xref:configuration-properties-legacy.adoc[Legacy Pre-3.0 BETA Configuration]
+  * xref:configuration-properties-legacy.adoc[Legacy Pre-3.0 Configuration]
 
 // end::reference-config[]
 

diff --git a/modules/ROOT/pages/_partials/_stats-item-names.adoc b/modules/ROOT/pages/_partials/_stats-item-names.adoc
@@ -151,7 +151,7 @@
 :sgr_docs_checked_sent: {xref-cb-config}sgr_docs_checked_sent[sgr_docs_checked_sent]
 // end::sgr1-replication-stats[]
 
-// Pre beta values, no longer included in sgr2 and-or renamed
+// Pre values, no longer included in sgr2 and-or renamed
 
 :sgr_num_attachment_bytes_transferred: {xref-cb-config}sgr_num_attachment_bytes_transferred[sgr_num_attachment_bytes_transferred]
 :sgr_num_attachments_transferred: {xref-cb-config}sgr_num_attachments_transferred[sgr_num_attachments_transferred]

diff --git a/modules/ROOT/pages/_partials/block-caveats.adoc b/modules/ROOT/pages/_partials/block-caveats.adoc
@@ -137,10 +137,10 @@ Do not use the `logs` directory as a storage location for files that should not
 ifndef::no-admonition[]
 [{caveat-level}]
 --
-Persistent Configuration is enabled by default from 3.0 BETA.
+Persistent Configuration is enabled by default from 3.0.
 
 endif::no-admonition[]
-To continue using legacy Pre-3.0 BETA configuration you should start {sgw} with {configuration-properties-legacy--xref-disable-persistent-config} set `true` either in the configuration file or in {command-line-options--xref}.
+To continue using legacy Pre-3.0 configuration you should start {sgw} with {configuration-properties-legacy--xref-disable-persistent-config} set `true` either in the configuration file or in {command-line-options--xref}.
 
 ifndef::no-admonition[]
 --

diff --git a/modules/ROOT/pages/_partials/common-cfg-ext-javascript.adoc b/modules/ROOT/pages/_partials/common-cfg-ext-javascript.adoc
@@ -8,7 +8,7 @@
 //    Requires -- partial$_page-index.adoc attributes
 //  End -- Inclusion Definition
 //  Begin -- Inclusion Content
-:fn-3x0: footnote:fn30[Commencing with release 3.0 BETA]
+:fn-3x0: footnote:fn30[Commencing with release 3.0]
 :fnref-3x0: footnote:fn30:[]
 
 == Introduction
@@ -43,7 +43,7 @@ Inline or external Javascript functions can be provided for any or all of the fo
 // tag::config-full[]
 NOTE: {sgw-s} 3.+ configuration of Javascript functions is done using the {rest-api-admin--xref}; specifically the {rest-api-admin--xref--access-control} and {rest-api-admin--xref--import-filter} endpoints.
 
-Before 3.0 BETA, configuration was done within the database configuration -- see: <<ex-jsfunc-opts>>
+Before 3.0, configuration was done within the database configuration -- see: <<ex-jsfunc-opts>>
 
 * Inline Javascript functions provided within the database configuration must be enclosed by a backtick pair (``).
 

diff --git a/modules/ROOT/pages/_partials/common-releasenotes.adoc b/modules/ROOT/pages/_partials/common-releasenotes.adoc
@@ -61,7 +61,7 @@ Additional Detail::
 * The ability to securely administer the Sync Gateway cluster using the admin REST endpoint enables programmatic control and simplifies remote administration in cloud deployments without relying on options like SSH-tunneling.
 * Maintaining a monolithic file is difficult especially if the configuration is complex. Multiple sync gateway databases may be defined in a single config file. This has potentially undesirable consequences in multi-tenant applications where database changes made for one tenant would require a restart of the node impacting all tenants.
 * A simple migration path ensures that existing JSON configurations are automatically converted to the new persistent modular configuration format on start-up.
-Users can opt-out of this should they wish to continue working in legacy Pre-3.0 BETA configuration mode.
+Users can opt-out of this should they wish to continue working in legacy Pre-3.0 configuration mode.
 // end::new-300-centralized-cfg-extended[]
 // tag::new-300-centralized-cfg[]
 

diff --git a/modules/ROOT/pages/_partials/compatibility-cbl-sgw.adoc b/modules/ROOT/pages/_partials/compatibility-cbl-sgw.adoc
@@ -36,7 +36,7 @@ The table below summarizes the compatible versions of Couchbase Lite with Sync G
 | 2.0
 | 2.1
 | 2.5 - 2.8
-|  3.0.0 (beta)
+|  3.0.0 ()
 
 | 1.4 *{fn-eos-sgw}* and 1.5 *{fn-eol-sgw}*
 | ✔
@@ -68,7 +68,7 @@ with delta sync enabled
 | ✔
 | ✔
 
-|  3.0.0 (beta)
+|  3.0.0
 | ✖
 | ✔
 | ✔

diff --git a/modules/ROOT/pages/_partials/concepts/sync-function.adoc b/modules/ROOT/pages/_partials/concepts/sync-function.adoc
@@ -112,7 +112,7 @@ If the document is being deleted, it will have  a `_deleted` property with the v
 Your implementation of the sync function can omit the oldDoc parameter if you do not need it (JavaScript ignores extra parameters passed to a function).
 
 |Meta (optional)
-|From 3.0 BETA the Sync Function includes support for a new `meta` argument.
+|From 3.0 the Sync Function includes support for a new `meta` argument.
 
 This argument references the user defined XATTR that you are using to hold access grant data.
 

diff --git a/...OOT/pages/_partials/configuration/definitions/database_configuration_model.adoc b/...OOT/pages/_partials/configuration/definitions/database_configuration_model.adoc
@@ -155,7 +155,7 @@ This property is intended to minimize accumulation of obsolete replication check
 
 The default is `7776000` seconds (90 days).|integer
 |**enable_shared_bucket_access** +
-__optional__|*Deprecated at 3.0 BETA*
+__optional__|*Deprecated at 3.0*
 
 use the `enable_shared_bucket_access` property to define whether to use extended attributes to store sync metadata; this is required to enable mobile-to-server data sync (_mobile convergence_).
 
@@ -216,7 +216,7 @@ document.cookie = cookie1String;
 __optional__|This flag disallows cookies from being used by Javascript; by default javascript CAN use them +
 **Default** : `false`|boolean
 |**allow_conflicts** +
-__optional__|**Deprecated at 3.0 * BETA*
+__optional__|**Deprecated at 3.0 **
 
 Use `allow_conflict` to define whether Sync Gateway will handle conflicts.
 

diff --git a/modules/ROOT/pages/_partials/howto/how-to-assign-users-to-roles.adoc b/modules/ROOT/pages/_partials/howto/how-to-assign-users-to-roles.adoc
@@ -32,7 +32,7 @@ Admin REST API::
 +
 --
 
-NOTE: The recommended method from 3.0 BETA
+NOTE: The recommended method from 3.0
 
 Assign a user to a role by sending a PUT request to the Admin REST API `_user` endpoint ({rest-api-admin-user-put--xref} ).
 

diff --git a/modules/ROOT/pages/_partials/howto/how-to-control-document-access.adoc b/modules/ROOT/pages/_partials/howto/how-to-control-document-access.adoc
@@ -25,9 +25,9 @@ You grant roles and-or users access to channels using:
  Using admin_channels property using the admin REST API endpoint -- see {rest-api-admin-user-put--xref}
 * Dynamically via Sync Function  +
  Programmatically within the sync function using the exposed helper function access() — see {sync-function-api--xref}
-* Configuration File (pre 3.0 BETA) +
+* Configuration File (pre 3.0) +
 Using the appropriate `admin_channels` property in the {configuration-properties-legacy--xref}. +
-*Note:* This option is disabled by default in 3.0 BETA; to use it, set the `disable_persistent_config` CLI or configuration file property flag to `true` and provide a full configuration
+*Note:* This option is disabled by default in 3.0; to use it, set the `disable_persistent_config` CLI or configuration file property flag to `true` and provide a full configuration
 
 [#ex-read-access]
 .Allow Access
@@ -66,7 +66,7 @@ In the case where channel assignment is done dynamically via the sync function,
 * The user/role can be derived or specified as a property within the document body.
 In this case, the document content itself is used to govern access and routing
 
-* From 3.0 BETA, the role can be specified within a special user-defined XATTR associated with the document -- see: {access-control-how-use-xattrs-for-access-grants--xref}.
+* From 3.0, the role can be specified within a special user-defined XATTR associated with the document -- see: {access-control-how-use-xattrs-for-access-grants--xref}.
 
 
 [{tabs}]
@@ -186,7 +186,7 @@ It does so by requiring that the current user is the one recorded as an owner on
 Version 3.x::
 +
 --
-This example makes use of channel data stored in XATTRS, an option introduced in 3.0 BETA -- see {access-control-how-use-xattrs-for-access-grants--xref} for more on this topic.
+This example makes use of channel data stored in XATTRS, an option introduced in 3.0 -- see {access-control-how-use-xattrs-for-access-grants--xref} for more on this topic.
 
 [source, javascript]
 ----

diff --git a/modules/ROOT/pages/_partials/howto/how-to-create-roles.adoc b/modules/ROOT/pages/_partials/howto/how-to-create-roles.adoc
@@ -17,7 +17,7 @@ You can create and-or manage roles using the following options
 * Admin REST API: +
 Roles are created via the Sync Gateway Admin REST API -- see: {rest-api-admin--xref}.
 
-* File-based Configuration Properties ( PRE 3.0 BETA) +
+* File-based Configuration Properties ( PRE 3.0) +
 Configure roles in the xref:configuration-properties-legacy.adoc[Legacy Configuration Properties] file.
 +
 include::partial$block-caveats.adoc[tags=disable-persistent-config]

diff --git a/modules/ROOT/pages/_partials/howto/how-to-create-users.adoc b/modules/ROOT/pages/_partials/howto/how-to-create-users.adoc
@@ -16,7 +16,7 @@ You create and-or manage users using the following options -- as shown in <<ex-c
 Users are created via the Sync Gateway {rest-api-admin--xref}.
 * OIDC +
 Configure _OIDC_ authentication to auto-register a user following successful validation of an ID Token -- {authentication-users--xref}.
-* Static Configuration (Pre 3.0 BETA): +
+* Static Configuration (Pre 3.0): +
 Users can be statically configured within the Sync Gateway Configuration File -- see: {configuration-properties-legacy--xref}. +
 *Note*, to use this option in version 3.x users must run Sync Gateway with the `disable_persistent_config` flag set to `true`.
 

diff --git a/modules/ROOT/pages/_partials/howto/how-to-use-xattrs-for-access-grants.adoc b/modules/ROOT/pages/_partials/howto/how-to-use-xattrs-for-access-grants.adoc
@@ -6,7 +6,7 @@ _Related Concepts_: {access-control-model--xref} |  {access-control-how-control-
 // == Use Extended Attributes (XATTRS)
 
 :sgw: pass:q[_Sync Gateway_]
-:fn-3x0: footnote:fn-3x0[From release 3.0 BETA]
+:fn-3x0: footnote:fn-3x0[From release 3.0]
 :fnref-3x0: footnote:fn-3x0[]
 
 

diff --git a/modules/ROOT/pages/_partials/sgw-svr-compatibility.adoc b/modules/ROOT/pages/_partials/sgw-svr-compatibility.adoc
@@ -48,9 +48,9 @@ ifndef::fnref-eos-sgw[]
 endif::[]
 
 
-:fn3-0: pass:q,a[footnote:3-0beta[The 3.0 Beta is compatible with these versions but its use is not recommended]]
+:fn3-0: pass:q,a[footnote:3-0[The 3.0 is compatible with these versions but its use is not recommended]]
 
-:fnref3-0: footnote:3-0beta[]
+:fnref3-0: footnote:3-0[]
 
 
 include::partial$block-caveats.adoc[tags="cbs6.0ke-xattrs"]
@@ -144,7 +144,7 @@ Compatibility Matrix
 | ✔
 | ✔
 
-| 3.0.0 (beta)
+| 3.0.0
 |
 | ✔
 | ✔

diff --git a/modules/ROOT/pages/_partials/sync-function-ovw.adoc b/modules/ROOT/pages/_partials/sync-function-ovw.adoc
@@ -1,6 +1,6 @@
 // Inclusion for use in master topics
 
-:fn-3x0: footnote:fn30[Commencing with release 3.0 BETA]
+:fn-3x0: footnote:fn30[Commencing with release 3.0]
 
 The Sync Function is executed every time a new revision/update is made to a document.
 The changes to channels and access made by the sync function are _tied to that revision_.

diff --git a/modules/ROOT/pages/access-control-how-use-xattrs-for-access-grants.adoc b/modules/ROOT/pages/access-control-how-use-xattrs-for-access-grants.adoc
@@ -10,7 +10,7 @@ include::partial$_std-hdr-sgw.adoc[]
 
 //  BEGIN -- Local Attributes
 :sgw: pass:q[_Sync Gateway_]
-:fn-3x0: footnote:fn-3x0[From release 3.0 BETA]
+:fn-3x0: footnote:fn-3x0[From release 3.0]
 :fnref-3x0: footnote:fn-3x0[]
 // END -- Page Attributes
 

diff --git a/modules/ROOT/pages/access-control-how.adoc b/modules/ROOT/pages/access-control-how.adoc
@@ -54,7 +54,7 @@ There are a number of ways in which you can control document distribution and us
 
 [#lst1]
 .Ways to configure access
-* Legacy Pre 3.0 Beta: Use the xref:configuration-properties-legacy.adoc[Legacy Configuration Properties] file's xref:configuration-properties-legacy.adoc#databases-user-admin-channels[admin_user_channels]
+* Legacy Pre 3.0: Use the xref:configuration-properties-legacy.adoc[Legacy Configuration Properties] file's xref:configuration-properties-legacy.adoc#databases-user-admin-channels[admin_user_channels]
 * Dynamically
 ** At the time of user creation with Admin REST Endpoint  {rest-api-admin-user-post--xref} using `admin_channel`
 ** Using the Sync Function's {sync-function-api-access-cmd--xref}.
@@ -109,7 +109,7 @@ include::{howto}verify-access.adoc[leveloffset={our-offset}]
 == Use Extended Attributes (XATTRS)
 
 :sgw: pass:q[_Sync Gateway_]
-:fn-3x0: footnote:fn-3x0[From release 3.0 BETA]
+:fn-3x0: footnote:fn-3x0[From release 3.0]
 :fnref-3x0: footnote:fn-3x0[]
 
 === Why use XATTRS

diff --git a/modules/ROOT/pages/configuration-overview.adoc b/modules/ROOT/pages/configuration-overview.adoc
@@ -26,7 +26,7 @@ include::partial$block-abstract.adoc[]
 
 == Introduction
 
-{sgw-te} 3.0 BETA introduces {ec-te}, to better suit its use in increasingly prevalent multi-node, multi-cluster deployments.
+{sgw-te} 3.0 introduces {ec-te}, to better suit its use in increasingly prevalent multi-node, multi-cluster deployments.
 {ec-s} replaces the established, file-based configuration method {fnfbc}, supporting the move away from a reliance on increasingly monolithic central configuration files.
 It enables simpler, more agile configuration updates and encompasses:
 
@@ -47,7 +47,7 @@ by default the REST API requires authentication and authorization using Couchbas
 This can be disabled for test purposes only.
 
 * *Automatic upgrade path* +
-Your existing legacy Pre-3.0 BETA configuration files will (optionally) be automatically converted, on start-up, to the new format for {ec}.
+Your existing legacy Pre-3.0 configuration files will (optionally) be automatically converted, on start-up, to the new format for {ec}.
 
 
 == Workflow

diff --git a/modules/ROOT/pages/configuration-properties-legacy.adoc b/modules/ROOT/pages/configuration-properties-legacy.adoc
@@ -1,11 +1,11 @@
-= Legacy Pre-3.0 BETA Configuration
+= Legacy Pre-3.0 Configuration
 :page-aliases: configuration-properties.adoc, refer/config-properties.adoc, config-properties.adoc
 ifdef::show_edition[:page-edition: {release}]
 ifdef::prerelease[:page-status: {prerelease}]
 :page-status: Legacy Content
 :page-role:
 :page-content: reference
-:description: pass:q[Configuring _Sync Gateway_ Pre-3.0 BETA to provide secure cloud-to-edge synchronization of enterprise data using the standard, static, configuration file.]
+:description: pass:q[Configuring _Sync Gateway_ Pre-3.0 to provide secure cloud-to-edge synchronization of enterprise data using the standard, static, configuration file.]
 :keywords:
 
 
@@ -22,11 +22,11 @@ include::partial$block-abstract.adoc[]
 // END -- DO NOT EDIT
 
 .Legacy Configuration
-IMPORTANT: This page describes Sync Gateway's legacy Pre-3.0 BETA configuration method -- for current configuration details -- see: {configuration-overview--xref} and-or {configuration-schema-bootstrap--xref}.
+IMPORTANT: This page describes Sync Gateway's legacy Pre-3.0 configuration method -- for current configuration details -- see: {configuration-overview--xref} and-or {configuration-schema-bootstrap--xref}.
 
 == Introduction
 
-This page describes Sync Gateway's legacy Pre-3.0 BETA configuration method.
+This page describes Sync Gateway's legacy Pre-3.0 configuration method.
 It uses a centralized configuration file to hold all configuration settings in JSON form -- see:<<lbl-schema,the schema>> for the file contents.
 
 include::partial$block-caveats.adoc[tags=disable-persistent-config]

diff --git a/modules/ROOT/pages/configuration-schema-database.adoc b/modules/ROOT/pages/configuration-schema-database.adoc
@@ -20,7 +20,7 @@ include::partial$block-caveats.adoc[tags="legacy-config-equivalents"]
 
 == Introduction
 
-From {sgw-te} 3.0 BETA you can use the Admin REST API to provision persistent configuration changes.
+From {sgw-te} 3.0 you can use the Admin REST API to provision persistent configuration changes.
 This content introduces the <<lbl-create-db>> and <<lbl-configure-db>> endpoints for convenience -- see {rest-api-admin--xref--database-configuration} for a full description of the endpoints available.
 
 

diff --git a/modules/ROOT/pages/configuration-schema-db-security.adoc b/modules/ROOT/pages/configuration-schema-db-security.adoc
@@ -21,7 +21,7 @@ include::partial$block-caveats.adoc[tags="legacy-config-equivalents"]
 
 == Introduction
 
-In 3.0 BETA we use the Admin REST API `_user` and `_role` endpoints to provision and manage {sgw} users through persistent configuration changes.
+In 3.0 we use the Admin REST API `_user` and `_role` endpoints to provision and manage {sgw} users through persistent configuration changes.
 
 This content introduces the <<lbl-upsert-role>> and <<lbl-upsert-user>> endpoints for convenience -- see {rest-api-admin--xref--database-security} for a full description of the endpoints available.
 

diff --git a/modules/ROOT/pages/configuration-schema-isgr.adoc b/modules/ROOT/pages/configuration-schema-isgr.adoc
@@ -21,7 +21,7 @@ include::partial$block-caveats.adoc[tags="legacy-config-equivalents"]
 
 == Introduction
 
-In 3.0 BETA we use the Admin REST API to provision persistent configuration changes.
+In 3.0 we use the Admin REST API to provision persistent configuration changes.
 This content introduces the <<lbl-upsert-replication>> endpoint for convenience -- see {rest-api-admin--xref--replication} for a full description of the endpoints available.
 
 

diff --git a/modules/ROOT/pages/get-started-install.adoc b/modules/ROOT/pages/get-started-install.adoc
@@ -63,12 +63,9 @@ NOTE: Ensure you have read -- and acted-upon -- the information in {get-started-
 include::partial$_get-started-topic-group.adoc[]
 
 
-== Beta Release Only
-{sgw-te} 3.0.0 (beta)01 is available for all xref:supported-environments.adoc[supported operating systems] as a direct download from here -- {downloads-mobile--xref}.
+== Installation Process
 
-Unpack the download to an appropriate location and install from there.
 
-== Installation Process
 You can install Sync Gateway on any of the xref:supported-environments.adoc[supported operating systems].
 On completion of this topic you should have a working Sync Gateway that you can extend and configure to meet your business needs.
 
@@ -82,6 +79,7 @@ It is intended primarily to verify the success of the installation by proving a
 
 == Configuration
 
+
 Sync Gateway's initial setup uses configuration details from a file its install script creates (`sync_gateway.json`, or `serviceconfig.json` on Windows).
 
 To provide your own configuration to Sync Gateway, you can either:
-Original file line number
+Diff line change
@@ Expand Up / @@ -32,7 +32,7 @@ Admin REST API:: @@
     +
     --
-    NOTE: The recommended method from 3.0 BETA
+    NOTE: The recommended method from 3.0
     Assign a user to a role by sending a PUT request to the Admin REST API `_user` endpoint ({rest-api-admin-user-put--xref} ).
@@ Expand Down @@