Remove all introduced in 5.x mentions from the dev branch (#2022)

Co-authored-by: NataliaIvakina <[email protected]>

Author: renetapopova

modules/ROOT/pages/authentication-authorization/auth-providers.adoc

@@ -1,5 +1,5 @@
 :description: This section explains how to use Cypher to manage authentication and authorization at the user level using Cypher.
-:page-role: enterprise-edition new-5.24
+:page-role: enterprise-edition
 
 [[access-control-auth-providers]]
 = User auth providers

modules/ROOT/pages/authentication-authorization/dbms-administration.adoc

@@ -469,7 +469,7 @@ GRANT [IMMUTABLE] SET PASSWORD[S]
 GRANT [IMMUTABLE] SET AUTH
   ON DBMS
   TO role[, ...]
-| label:new[Introduced in 5.24] Enables the specified roles to `SET` or `REMOVE` users' xref:authentication-authorization/auth-providers.adoc[auth providers].
+| Enables the specified roles to `SET` or `REMOVE` users' xref:authentication-authorization/auth-providers.adoc[auth providers].
 
 | [source, syntax, role=noheader]
 GRANT [IMMUTABLE] SET USER HOME DATABASE
@@ -614,7 +614,7 @@ A user that is granted the `SET PASSWORDS` privilege is allowed to run the `ALTE
 ALTER USER jake SET PASSWORD 'abcd5678' CHANGE NOT REQUIRED
 ----
 
-label:new[Introduced in 5.24] A user that is granted the `SET AUTH` privilege is allowed to run the `ALTER USER` administration command with one or both of the `SET AUTH` and `REMOVE AUTH` parts:
+A user that is granted the `SET AUTH` privilege is allowed to run the `ALTER USER` administration command with one or both of the `SET AUTH` and `REMOVE AUTH` parts:
 
 [source, cypher, role=noplay]
 ----
@@ -1574,13 +1574,7 @@ The ability to use elevated privileges when executing a procedure can be granted
 A user with this privilege will not be restricted to their other privileges when executing the procedures matched by the <<access-control-name-globbing, name-globbing>>.
 The `EXECUTE BOOSTED PROCEDURE` privilege only affects the elevation, and not the execution of the procedure.
 Therefore, it is needed to grant `EXECUTE PROCEDURE` privilege for the procedures as well.
-
-
-[NOTE]
-====
-Since Neo4j 5.0, both `EXECUTE PROCEDURE` and `EXECUTE BOOSTED PROCEDURE` are needed to execute a procedure with elevated privileges.
-This differs from Neo4j 4.x, when only the `EXECUTE BOOSTED PROCEDURE` is required.
-====
+Both `EXECUTE PROCEDURE` and `EXECUTE BOOSTED PROCEDURE` are needed to execute a procedure with elevated privileges.
 
 [source, cypher, role=noplay]
 ----
@@ -1873,13 +1867,7 @@ The ability to use elevated privileges when executing a user-defined function (U
 A user with this privilege will not be restricted to their other privileges when executing the UDFs matched by the <<access-control-name-globbing, name-globbing>>.
 The `EXECUTE BOOSTED USER DEFINED FUNCTION` privilege only affects the elevation and not the execution of the function.
 Therefore, it is needed to grant `EXECUTE USER DEFINED FUNCTION` privilege for the functions as well.
-
-
-[NOTE]
-====
-Since Neo4j 5.0, both `EXECUTE USER DEFINED FUNCTION` and `EXECUTE BOOSTED USER DEFINED FUNCTION` are needed to execute a function with elevated privileges.
-This differs from Neo4j 4.x, when only the `EXECUTE BOOSTED USER DEFINED FUNCTION` is required.
-====
+Both `EXECUTE USER DEFINED FUNCTION` and `EXECUTE BOOSTED USER DEFINED FUNCTION` are needed to execute a function with elevated privileges.
 
 [IMPORTANT]
 ====
@@ -1926,7 +1914,7 @@ a|Rows: 2
 ======
 
 
-[role=label--new-5.6]
+
 [[access-control-dbms-administration-setting]]
 == The DBMS `SETTING` privileges
 

modules/ROOT/pages/authentication-authorization/immutable-roles-privileges.adoc

@@ -4,8 +4,7 @@
 :description: This section explains how to use Cypher to manage immutable roles and privileges.
 
 
-Immutable privileges are useful for restricting the actions of users who can themselves administer xref:authentication-authorization/dbms-administration.adoc#access-control-dbms-administration-privilege-management[privileges]. 
-Starting with Neo4j 5.26, Neo4j also introduces immutable roles.
+Immutable privileges are useful for restricting the actions of users who can themselves administer xref:authentication-authorization/dbms-administration.adoc#access-control-dbms-administration-privilege-management[privileges].
 Immutable roles are useful for providing _system roles_, which appear as permanent parts of the DBMS.
 
 
@@ -38,8 +37,8 @@ The following examples demonstrate how to use Cypher to manage immutable roles a
 
 === Restricting the actions of users who can manage privileges
 
-To prevent all users (including those with `PRIVILEGE MANAGEMENT` privileges) from performing *database management*, attach an immutable privilege to the `PUBLIC` role. 
-The `PUBLIC` role implicitly and irrevocably applies to all users. 
+To prevent all users (including those with `PRIVILEGE MANAGEMENT` privileges) from performing *database management*, attach an immutable privilege to the `PUBLIC` role.
+The `PUBLIC` role implicitly and irrevocably applies to all users.
 
 . Ensure that you have completed steps 1 and 2 from <<administer-immutable-roles-and-privileges>>.
 . Run the following command to deny the `IMMUTABLE DATABASE MANAGEMENT` privilege to the `PUBLIC` role:

modules/ROOT/pages/authentication-authorization/ldap-integration.adoc

@@ -334,7 +334,6 @@ dbms.security.ldap.authorization.access_permitted_group=501
 . Map the groups in the LDAP system to the Neo4j built-in and custom roles.
 For more information, see xref:authentication-authorization/ldap-integration.adoc#auth-ldap-map-ldap-roles[Map the LDAP groups to the Neo4j roles].
 
-[role=label--new-5.24]
 [[auth-ldap-auth-providers]]
 == Configure authentication/authorization at the user level using auth providers
 xref:authentication-authorization/auth-providers.adoc[User auth providers] can be used to determine which users can authenticate and authorize using the configured providers, including LDAP.

modules/ROOT/pages/authentication-authorization/load-privileges.adoc

@@ -11,8 +11,6 @@ CREATE ROLE roleLoadCidr
 [[access-control-load-privileges]]
 = Load privileges
 
-_This feature is available from Neo4j 5.13._
-
 This section explains how to use Cypher to manage load privileges.
 All load privileges apply to the whole system.
 Like DBMS privileges, they do not belong to one specific database or graph.
@@ -46,8 +44,7 @@ GRANT [IMMUTABLE] LOAD
 GRANT [IMMUTABLE] LOAD
   ON CIDR cidr
   TO role[, ...]
-| Enables the specified roles to load external data from the given CIDR range in queries.label:new[Introduced in 5.16]
-
+| Enables the specified roles to load external data from the given CIDR range in queries.
 |===
 
 [NOTE]
@@ -103,8 +100,6 @@ The `LOAD ON ALL DATA` privilege is granted to the `PUBLIC` role by default.
 [[access-control-load-cidr]]
 == The `CIDR` privilege
 
-_This feature is available from Neo4j 5.16._
-
 The load privilege on `CIDR cidr` enables or disables loading data from the given IPv4 or IPv6 CIDR range.
 If granted, the user can load data from sources in the given CIDR range.
 If missing or denied, no data can be loaded from sources in the given CIDR range.

modules/ROOT/pages/authentication-authorization/manage-privileges.adoc

@@ -48,7 +48,7 @@ The components of the graph privilege commands are:
 ** `IMMUTABLE` can optionally be specified when performing a `GRANT` or `DENY` to indicate that the privilege cannot be subsequently removed unless auth is disabled.
 Auth must also be disabled in order to `GRANT` or `DENY` an immutable privilege.
 Contrastingly, when `IMMUTABLE` is specified in conjunction with a `REVOKE` command, it will act as a filter and only remove matching _immutable_ privileges.
-Starting from Neo4j 5.26, immutable privileges can also be used together with immutable roles.
+Immutable privileges can also be used together with immutable roles.
 See xref:authentication-authorization/immutable-roles-privileges.adoc[] for more information.
 
 * _graph-privilege_:
@@ -203,7 +203,7 @@ The following image shows the hierarchy between different graph privileges:
 image::privileges_hierarchy.svg[title="Graph privileges hierarchy"]
 
 
-[role=label--new-5.9]
+
 [[access-control-list-supported-privileges]]
 == Listing supported privileges
 

modules/ROOT/pages/authentication-authorization/manage-roles.adoc

@@ -340,7 +340,7 @@ For more information, see xref:authentication-authorization/dbms-administration.
 
 
 You can view all available roles using the Cypher command `SHOW ROLES`, which returns a single column by default.
-Starting from 5.26, you can optionally use `SHOW ROLES YIELD *` to see if the role is immutable.
+Optionally, you can also use `SHOW ROLES YIELD *` to see if the role is immutable.
 See <<access-control-immutable-roles, Immutable roles>> for more information.
 
 .`SHOW ROLES` output
@@ -582,7 +582,6 @@ This is equivalent to running `DROP ROLE myrole IF EXISTS` followed by `CREATE R
 The `CREATE OR REPLACE ROLE` command does not allow you to use the `IF NOT EXISTS`.
 ====
 
-[role=new-in-5.26]
 [[access-control-immutable-roles]]
 == Immutable roles
 

modules/ROOT/pages/authentication-authorization/manage-users.adoc

@@ -152,7 +152,7 @@ CREATE USER name [IF NOT EXISTS]
   [[SET PASSWORD] CHANGE [NOT] REQUIRED]
   [SET STATUS {ACTIVE \| SUSPENDED}]
   [SET HOME DATABASE name]
-  [SET AUTH [PROVIDER] 'provider' "{"{SET <key> <value>}..."}"]... # Introduced in Neo4j 5.24
+  [SET AUTH [PROVIDER] 'provider' "{"{SET <key> <value>}..."}"]...
 ----
 
 `<key><value>` pairs for the `SET AUTH` clause could include:
@@ -203,7 +203,7 @@ CREATE OR REPLACE USER name
   [[SET PASSWORD] CHANGE [NOT] REQUIRED]
   [SET STATUS {ACTIVE \| SUSPENDED}]
   [SET HOME DATABASE name]
-  [SET AUTH [PROVIDER] 'provider' "{"{SET <key> <value>}..."}"]... # Introduced in Neo4j 5.24
+  [SET AUTH [PROVIDER] 'provider' "{"{SET <key> <value>}..."}"]...
 ----
 `<key><value>` pairs for the `SET AUTH` clause could include:
 [source, syntax, role="noheader"]
@@ -292,7 +292,7 @@ ALTER USER name [IF EXISTS]
   [[SET PASSWORD] CHANGE [NOT] REQUIRED]
   [SET STATUS {ACTIVE \| SUSPENDED} ]
   [SET HOME DATABASE name]
-  [SET AUTH [PROVIDER] 'provider' "{"{SET <key> <value>}..."}"]... # Introduced in Neo4j 5.24
+  [SET AUTH [PROVIDER] 'provider' "{"{SET <key> <value>}..."}"]...
 ----
 `<key><value>` pairs for the `SET AUTH` clause could include:
 [source, syntax, role="noheader"]
@@ -633,7 +633,6 @@ RETURN user AS adminUser
 |===
 ======
 
-[role=label--new-5.24]
 [[access-control-list-user-auth-providers]]
 == Listing user auth providers
 
@@ -753,7 +752,6 @@ You can create users using one of the following Cypher commands, depending on wh
 In both cases, you can specify the user's password, whether they must change it at the next login, their status, home database, and auth provider settings.
 The `SET` clauses can be applied in any order.
 It is mandatory to specify a `SET PASSWORD` and/or at least one `SET AUTH` clause because users must have at least one auth provider.
-`SET AUTH` is available from Neo4j 5.24 onwards.
 
 .`CREATE USER` syntax
 [source, syntax, role="noheader"]
@@ -801,7 +799,7 @@ If not set, the default is `ACTIVE`.
 A home database is resolved if it is pointing to a database or a database alias.
 If no home database is set, the DBMS default database is used as the home database for that user.
 
-<6> label:new[Introduced in 5.24] One or more `SET AUTH` clause can be used to configure external xref:authentication-authorization/auth-providers.adoc[auth providers], such as LDAP or OIDC, which define authentication/authorization providers for that user.
+<6> One or more `SET AUTH` clause can be used to configure external xref:authentication-authorization/auth-providers.adoc[auth providers], such as LDAP or OIDC, which define authentication/authorization providers for that user.
 `SET AUTH` can also be used as an alternative way to set the native (password-based) auth settings like `SET PASSWORD` and `SET PASSWORD CHANGE REQUIRED`.
 For further informations, see the examples in this section, as well as xref:authentication-authorization/sso-integration.adoc#auth-sso-auth-providers[Configure SSO at the user level using auth providers] for OIDC, and xref:authentication-authorization/ldap-integration.adoc#auth-ldap-auth-providers[Configure authentication/authorization at the user level using auth providers] for LDAP.
 +
@@ -838,7 +836,6 @@ SET STATUS SUSPENDED
 SET HOME DATABASE anotherDb
 ----
 
-[role=label--new-5.24]
 The equivalent command using the xref:authentication-authorization/auth-providers.adoc[auth providers] syntax would be:
 
 [source,cypher,role=noplay]
@@ -862,7 +859,6 @@ SET ENCRYPTED PASSWORD '1,6d57a5e0b3317055454e455f96c98c750c77fb371f3f0634a1b8ff
 SET STATUS ACTIVE
 ----
 
-[role=label--new-5.24]
 The equivalent command using the xref:authentication-authorization/auth-providers.adoc[auth providers] syntax would be:
 .
 [source,cypher,role=noplay]
@@ -896,7 +892,6 @@ CREATE USER jake IF NOT EXISTS
 SET PLAINTEXT PASSWORD 'abcd1234'
 ----
 
-[role=label--new-5.24]
 The equivalent command using the xref:authentication-authorization/auth-providers.adoc[auth providers] syntax would be:
 
 [source,cypher,role=noplay]
@@ -919,7 +914,6 @@ SET PLAINTEXT PASSWORD 'abcd1234'
 
 This is equivalent to running `DROP USER jake IF EXISTS` followed by `CREATE USER jake SET PASSWORD 'abcd1234'`.
 
-[role=label--new-5.24]
 The equivalent command using the xref:authentication-authorization/auth-providers.adoc[auth providers] syntax would be:
 
 [source,cypher,role=noplay]
@@ -1004,7 +998,7 @@ Where:
 <1> Specifies the command to alter a user.
 <2> Removes the home database for the user.
 As a result, the DBMS default database will be used as the home database for that user.
-<3> label:new[Introduced in 5.24] Removes one, several, or all existing xref:authentication-authorization/auth-providers.adoc[auth provider(s)] from a user.
+<3> Removes one, several, or all existing xref:authentication-authorization/auth-providers.adoc[auth provider(s)] from a user.
 However, a user must always have at least one auth provider.
 Therefore, `REMOVE ALL AUTH` must be used in conjunction with at least one `SET AUTH` clause in order to meet this requirement.
 <4> Specifies the password for the user.
@@ -1023,7 +1017,7 @@ The `SET PASSWORD` prefix of the `CHANGE [NOT] REQUIRED` clause is only optional
 <6> Specifies the user's status.
 <7> Specifies a home database for a user. A home database is resolved if it is pointing to a database or a database alias. If no home database is set, the DBMS default database is used as the home database for that user.
 
-<8> label:new[Introduced in 5.24] One or more `SET AUTH` clauses can be used to set xref:authentication-authorization/auth-providers.adoc[auth providers], which define authentication / authorization providers for that user.
+<8> One or more `SET AUTH` clauses can be used to set xref:authentication-authorization/auth-providers.adoc[auth providers], which define authentication / authorization providers for that user.
 This might be used to configure external auth providers like LDAP or OIDC, but can also be used as an alternative way to set the native (password-based) auth settings like `SET PASSWORD` and `SET PASSWORD CHANGE REQUIRED`.
 For further informations, see the examples in this section, as well as xref:authentication-authorization/sso-integration.adoc#auth-sso-auth-providers[Configure SSO at the user level using auth providers], and xref:authentication-authorization/ldap-integration.adoc#auth-ldap-auth-providers[Configure authentication/authorization at the user level using auth providers].
 +
@@ -1050,7 +1044,6 @@ SET PASSWORD 'abcd5678' CHANGE NOT REQUIRED
 SET STATUS ACTIVE
 ----
 
-[role=label--new-5.24]
 The equivalent command using the xref:authentication-authorization/auth-providers.adoc[auth providers] syntax would be:
 
 ----
@@ -1070,7 +1063,6 @@ ALTER USER bob
 SET PASSWORD CHANGE REQUIRED
 ----
 
-[role=label--new-5.24]
 The equivalent command using the xref:authentication-authorization/auth-providers.adoc[auth providers] syntax would be:
 
 ----
@@ -1079,7 +1071,7 @@ SET AUTH 'native' {SET PASSWORD CHANGE REQUIRED}
 ----
 ======
 
-[role=label--enterprise-edition label--new-5.24]
+[role=label--enterprise-edition]
 .Modify a user to use an external OIDC auth provider
 ======
 For example, you can modify the user `bob` by removing his native auth provider and adding an external OIDC auth provider:
@@ -1092,7 +1084,7 @@ SET AUTH 'oidc-mysso1' {SET ID 'bobsUniqueMySso1Id'}
 ----
 ======
 
-[role=label--enterprise-edition label--new-5.24]
+[role=label--enterprise-edition]
 .Modify a user to use multiple external OIDC auth providers
 ======
 For example, you can modify the user `bob` by removing all of his existing auth providers and adding two external OIDC auth providers:

modules/ROOT/pages/authentication-authorization/property-based-access-control.adoc

@@ -7,7 +7,7 @@ CREATE ROLE regularUsers;
 ----
 ////
 
-:page-role: enterprise-edition aura-db-business-critical aura-db-dedicated new-5.24
+:page-role: enterprise-edition aura-db-business-critical aura-db-dedicated
 [[property-based-access-control]]
 = Property-based access control
 
@@ -106,7 +106,7 @@ GRANT READ {*} ON GRAPH * FOR (n) WHERE n.createdAt > date() TO regularUsers
 ----
 [NOTE]
 ====
-The `date()` function is evaluated, and the value used to evaluate the privilege is the date when the property-based privilege is created. 
+The `date()` function is evaluated, and the value used to evaluate the privilege is the date when the property-based privilege is created.
 Keep this in mind when designing your property rules, and use the `SHOW PRIVILEGES AS COMMANDS` command to check the stored value.
 This is essential when revoking property-based privileges containing evaluated function values like `date()`.
 ====

modules/ROOT/pages/authentication-authorization/sso-integration.adoc

@@ -114,7 +114,7 @@ The default is `false`, to read the claim from the token.
 | xref:configuration/configuration-settings.adoc#config_dbms.security.oidc.-provider-.claims.groups[dbms.security.oidc.<provider>.claims.groups]
 |
 | true
-| The claim to use for the database roles. Neo4j expects to find a claim in the JWT or user_info response with this name. The claim may be a string claim representing a single role or a string array claim representing multiple roles. From Neo4j 5.4, the JWT claim may also contain a single group returned as a string as well as a list of groups as was previously required.
+| The claim to use for the database roles. Neo4j expects to find a claim in the JWT or user_info response with this name. The claim may be a string claim representing a single role or a string array claim representing multiple roles. The JWT claim may also contain a single group returned as a string as well as a list of groups as was previously required.
 
 | xref:configuration/configuration-settings.adoc#config_dbms.security.oidc.-provider-.authorization.group_to_role_mapping[dbms.security.oidc.<provider>.authorization.group_to_role_mapping]
 |
@@ -271,7 +271,7 @@ dbms.security.oidc.mysso.get_groups_from_user_info=true
 +
 It is possible to fetch just the username, just the groups, or both from the userinfo endpoint.
 
-[role=label--new-5.24]
+
 [[auth-sso-auth-providers]]
 === Configure SSO at the user level using auth providers
 xref:authentication-authorization/auth-providers.adoc[User auth providers] can be used to determine which users can authenticate and authorize using the configured providers.