arnaud4d · Oct 30, 2026 · Oct 20, 2026 · Oct 27, 2026
diff --git a/docs/4DQodlyPro/force-login.md b/docs/4DQodlyPro/force-login.md
@@ -15,7 +15,6 @@ Make sure the ["force login" mode](https://developer.4d.com/docs/REST/authUsers#
 
 You can also set this option directly in the [**roles.json** file](https://developer.4d.com/docs/ORDA/privileges#rolesjson-file).
 
-You just need then to implemented the [`authentify()`](https://developer.4d.com/docs/REST/authUsers#function-authentify) function in the datastore class and call it from the Qodly page. A licence will be consumed only when the user is actually logged.
 
 
 :::note Compatibility
@@ -28,8 +27,6 @@ When the legacy login mode ([deprecated as of 4D 20 R6](https://blog.4d.com/forc
 
 In a simple Qodly page with login/password inputs, a "Submit" button calls the following `authentify()` function we have implemented in the DataStore class:
 
-<Tabs>
-  <TabItem value="4D" label="4D" default>
     ```4d
 	exposed Function authentify($credentials : Object) : Text
 		var $salesPersons : cs.SalesPersonsSelection
@@ -51,31 +48,6 @@ In a simple Qodly page with login/password inputs, a "Submit" button calls the f
 			return "Wrong user"
 		End if
 	```
-  </TabItem>
-  <TabItem value="qs" label="QodlyScript">
-    ```qs
-    exposed function authentify(credentials : Object) : string
-		var salesPersons : cs.SalesPersonsSelection
-		var sp : cs.SalesPersonsEntity
-
-		salesPersons=ds.SalesPersons.query("identifier = :1", credentials.identifier)
-		sp = salesPersons.first()
-
-		if (sp!=Null)
-			if (verifyPasswordHash(credentials.password, sp.password))
-				session.clearPrivileges()
-				session.setPrivileges("") //guest session
-
-				return "Authentication successful"
-			else
-				return "Wrong password"
-			end
-		else
-			return "Wrong user"
-		end
-    ```
-  </TabItem>
-</Tabs>
 
 This call is accepted and as long as the authentication is not successful, `Session.setPrivileges()` is not called, thus no license is consumed. Once `Session.setPrivileges()` is called, a 4D client licence is used and any REST request is then accepted.
 

diff --git a/docs/4DQodlyPro/img/add-privilege.png b/docs/4DQodlyPro/img/add-privilege.png
diff --git a/docs/4DQodlyPro/roles/attributesPermissions.md b/docs/4DQodlyPro/roles/attributesPermissions.md
@@ -40,6 +40,3 @@ To address this issue, refine the attribute permissions to restrict access to se
 
 By setting attribute permissions in the `ManageFinancials` privilege, you allow users with the `ManageReports` privilege to access the Reporting dataclass while restricting access to confidential attributes like `netProfitMargin` and `totalExpenses`.
 
-<img src={require('./img/attributePermissions2.png').default} style={{borderRadius: '6px'}} />
-
-In the response, the presence of `__INVALID: 1` indicates that the attribute is marked as invalid, signaling that the user lacks the necessary permissions to access or modify it.
diff --git a/docs/4DQodlyPro/roles/dataClassPermissions.md b/docs/4DQodlyPro/roles/dataClassPermissions.md
@@ -6,13 +6,12 @@ title: DataClass Permissions
 import Column from '@site/src/components/Column'
 
 
-## Purpose and Scope
-
-**DataClass** Permissions empower you to shape and control access to specific DataClasses within your datastore. These permissions dictate what actions users are allowed to perform on individual DataClasses, enabling fine-grained access control over your data.
 
 ## Configuring DataClass Permissions 
 
-DataClass-level permissions can override or supplement those set at the datastore level. To set DataClass permissions for a specific privilege:
+[Refer to the 4D documentation](https://developer.4d.com/docs/ORDA/privileges#inherited-permissions) to see how DataClass permissions interact with other permissions. 
+
+To set DataClass permissions for a specific privilege:
 
 - Select the resource name, like the `Employee` dataclass, from the dropdown list.
 - Or, type the resource name directly into the search bar.
@@ -23,7 +22,7 @@ The <img src={require('./img/dataclass.png').default} style={{borderRadius: '6px
 
 ## Example: DataClass-Level Access Control
 
-Building on the approach where the [Guest privilege is granted initial read access to the entire datastore](datastorePermissions.md#full-access-to-gradual-restriction), you can gradually restrict access to specific resources by configuring **DataClass** permissions. This involves excluding the `Guest` privilege from certain DataClasses.
+Building on the approach where the [Guest privilege is granted initial read access to the entire datastore](datastorePermissions.md#full-access-to-gradual-restriction), you can gradually restrict access to specific resources by configuring **DataClass** permissions. This involves excluding the `guest` privilege from certain DataClasses.
 
 :::tip
 While datastore permissions cascade down to DataClasses, they remain adaptable. DataClass permissions allow you to override or supplement the broader settings as needed.
@@ -33,8 +32,7 @@ While datastore permissions cascade down to DataClasses, they remain adaptable.
 
 <br/><br/>
 
-By setting specific permissions in the `Restricted` privilege for the `Employee` DataClass, you prevent users with the `Guest` privilege from accessing sensitive employee data.
+1. Create a `Restricted` privilege for the `Employee` DataClass
+2. Set all permissions to the `Restricted` privilege. 
 
-:::info 
-In this context, the permissions set at the datastore level for the Guest privilege are overridden by the Restricted privilege at the DataClass level. As a result, users with the Guest role no longer have access to the Employee DataClass.
-:::
+In this context, the permissions set at the datastore level for the guest privilege are overridden by the Restricted privilege at the DataClass level. As a result, users with the guest role no longer have access to the Employee DataClass.
diff --git a/docs/4DQodlyPro/roles/datastorePermissions.md b/docs/4DQodlyPro/roles/datastorePermissions.md
@@ -5,17 +5,9 @@ title: Datastore Permissions
 
 import Column from '@site/src/components/Column'   
 
-## Purpose and Scope
+## Overview
 
-Datastore permissions are essential for controlling access to your entire **Datastore**. By configuring these permissions, you establish a primary defense mechanism against unauthorized access and alterations to critical mission data.
-
-## Risk of Unrestricted Access
-
-Without proper setup, your application is vulnerable to unregulated access. In such scenarios, every user gains unrestricted access to all **datastore resources**, posing significant risks.
-
-To illustrate, imagine an unauthorized user attempting an HTTP request to the **Package dataclass** REST API endpoint. This unchecked data access allows unauthorized actions, including accessing confidential user information, and poses a uniform risk across all dataclasses.
-
-<img src={require('./img/unrestrictedAccess.png').default} style={{borderRadius: '6px'}} />
+Datastore permissions are essential for controlling access to your entire **Datastore**. 4D offers several strategies to [ensure the security of the data in your datastore](https://developer.4d.com/docs/ORDA/privileges#restriction-modes). 
 
 ## Configuring Datastore Permissions 
 
@@ -32,59 +24,53 @@ The <img src={require('./img/datastore.png').default} style={{borderRadius: '6px
 
 To address the risks of unrestricted access, an approach called `All Data Inaccessible by Default` is employed. This strategy restricts access to the entire datastore by default, gradually expanding access to specific dataclasses through other privileges achieved by applying [Dataclasses Permissions](dataClassPermissions.md).
 
-### Introducing Restricted Privilege  
 
-At the core of the datastore lockdown strategy lies the concept of the `Restricted` privilege. This privilege acts as a safeguard, restricting all actions on the datastore and rendering it inaccessible until specific permissions are meticulously set up.
+You have two ways to lock everything: 
 
-:::info
-This ensures that users, even without defined roles or privileges, cannot access any resources within the datastore.
-:::
+1. Turn on **Restrict Access By Default**, or
+2. Create a privilege (e.g. "none"), create a permission "ds", check every action, and never add this privilege to any role (the administration role included). 
+
+Then open gradually with permissions on dataclasses and functions; login function is granted to `guest`. 
+
+These strategies are [discussed in the 4D documentation](https://developer.4d.com/docs/ORDA/privileges#restriction-modes). 
 
-### Configuring Permissions  
 
 After establishing a privilege like `Restricted`, you assign permissions to the datastore, covering a range of actions from `Read` to `Execute`.
 
 <img src={require('./img/restrictedPrivilege.png').default} style={{borderRadius: '6px'}} />
 
 <br/><br/>
 
-:::info
-By applying all permissions to the `ds` resource within the Restricted privilege and not assigning it to any role, you prevent malicious access attempts. This safeguard transforms the application into a secure vault.
-:::
-
-Attempting to access the REST API endpoints will result in a `No permission to read for the Package dataclass` response, a rule that extends across all dataclasses.
-
-<img src={require('./img/restrictedAccess.png').default} style={{borderRadius: '6px'}} />
 
 ## Full Access to Gradual Restriction
 
-Alternatively, the `Guest` privilege provides another strategy for managing unauthorized users. This privilege allows full access to the entire datastore by default, with specific resources being restricted through other privileges achieved by applying [Dataclasses Permissions](dataClassPermissions.md).
+Alternatively, the `guest` privilege provides another strategy for managing unauthorized users. This privilege allows full access to the entire datastore by default, with specific resources being restricted through other privileges achieved by applying [Dataclasses Permissions](dataClassPermissions.md).
 
 
 ### Introducing the Guest Privilege  
 
-When a role lacks specific privileges, the `Guest` privilege is assigned to that `Session`. This allows users without defined privileges to access non-restricted resources while preventing potentially harmful activities with other resources, ensuring that users interact within well-defined boundaries.
+When a role lacks specific privileges, the `guest` privilege is assigned to that `Session`. This allows users without defined privileges to access non-restricted resources while preventing potentially harmful activities with other resources, ensuring that users interact within well-defined boundaries.
 
 :::info
-The `Guest` privilege grants access to all resources if no explicit permissions are in place.
+The `guest` privilege grants access to all resources if no explicit permissions are in place.
 :::
 
 ### Configuring the Guest Privilege  
 
-The `Guest` privilege is established in the `Privileges` tab by default, ready to welcome users who have not yet established a formal identity.
+The `guest` privilege is established in the `Privileges` tab by default, ready to welcome users who have not yet established a formal identity.
 
 <img src={require('./img/guestPrivilege.png').default} style={{borderRadius: '6px'}} />
 
 ### Configuring Read Access
 
-To grant read access to the `Guest` privilege, follow these steps:
+To grant read access to the `guest` privilege, follow these steps:
 
 1. Remove complete permissions control over the Datastore from the `Restricted` privilege. 
-2. Assign the Read permission specifically to the datastore within the `Guest` privilege, thereby endowing it with the capability of read-only access.
+2. Assign the Read permission specifically to the datastore within the `guest` privilege, thereby endowing it with the capability of read-only access.
 
 <img src={require('./img/readAccessGuestPrivilege.png').default} style={{borderRadius: '6px'}} />
 
-By making this change, the `Guest` privilege now allows users to access a wealth of data, including details about flights, hotels, and activities, while ensuring that critical information remains safeguarded against unauthorized modifications.
+By making this change, the `guest` privilege now allows users to access a wealth of data, including details about flights, hotels, and activities, while ensuring that critical information remains safeguarded against unauthorized modifications.
 
 <img src={require('./img/packages.png').default} style={{borderRadius: '6px'}} />
 
@@ -100,7 +86,7 @@ To balance data accessibility and security, the next crucial step is to utilize
 
 ## Guest Inherited Permission
 
-Permissions of the `Guest` privilege are automatically inherited across various privileges. This parallels the behavior observed in the `Restricted` privilege, where the capability of reading from the **Datastore** is evident.
+`guest` permissions are [granted to every session](https://developer.4d.com/docs/ORDA/privileges#guest-privilege). 
 
 <img src={require('./img/inheritedPermissions.png').default} style={{borderRadius: '6px'}} />
Original file line number	Diff line number	Diff line change
Expand Up		@@ -40,6 +40,3 @@ To address this issue, refine the attribute permissions to restrict access to se

		By setting attribute permissions in the `ManageFinancials` privilege, you allow users with the `ManageReports` privilege to access the Reporting dataclass while restricting access to confidential attributes like `netProfitMargin` and `totalExpenses`.

		<img src={require('./img/attributePermissions2.png').default} style={{borderRadius: '6px'}} />

		In the response, the presence of `__INVALID: 1` indicates that the attribute is marked as invalid, signaling that the user lacks the necessary permissions to access or modify it.