Formatting

Author: Dan Costello

content/docs/data-access/definitions/access-policies.md

@@ -23,7 +23,7 @@ In addition, two special types of access policies are available:
 
 Access policies provide central, fine-grained control over sensitive data access. They can evaluate purpose, identity, authorization, location, , and more. They can range from simple "always allow resolution" policies to complex evaluations.
 
-![Access policies give you central, fine-grained control over sensitive data access. Policies can evaluate purpose, identity, permissions, location, expiration timelines, rate limits and more.](/assets/images/what-userclouds-does.webp)
+![Access policies give you central, fine-grained control over sensitive data access. Policies can evaluate purpose, identity, permissions, location, expiration timelines, rate limits and more.](/assets/images/flow-chart.webp)
 
 ## Example Use Cases
 
@@ -58,7 +58,7 @@ Access Policies are composed from Access Policy Templates. Templates are paramet
 
 ### Template function
 
-```
+```javascript
 function getAge(DOB) {  
     const today = new Date();  
     const birthDate = new Date(DOB);  
@@ -77,7 +77,7 @@ function policy(context, params) {
 
 ### Parameters to instantiate a policy
 
-```
+```javascript
 // Example Policy Parameters (not specified in the template function)
 const params = { expected_years_old: 16, column_name: "birthdate" };
 ```
@@ -88,7 +88,7 @@ Here is an example of how you can create a policy to check if the country claim
 
 ### Template function
 
-```
+```javascript
 function policy(context, params) {  
     const country = context.server.claims.country;  
     const specifiedCountry = params.specified_country;  
@@ -98,7 +98,7 @@ function policy(context, params) {
 
 ### Parameters to instantiate a policy
 
-```
+```javascript
 // Example Policy Parameters (not specified in the template function)
 const params = { specified_country: "USA" };
 ```
@@ -109,7 +109,7 @@ If the country information is not in the JWT but in the client context, the poli
 
 ### Template function
 
-```
+```javascript
 function policy(context, params) {  
     const country = context.client.country;  
     const specifiedCountry = params.specified_country;  
@@ -119,7 +119,7 @@ function policy(context, params) {
 
 ### Parameters to instantiate a policy
 
-```
+```javascript
 // Example Policy Parameters (not specified in the template function)
 const params = { specified_country: "USA" };
 ```
@@ -136,11 +136,11 @@ We provide a number of built-in functions available as global variables in your
 
 The built-in `networkRequest` function allows you to reach external services via HTTPS requests. You can pass headers in the network request, allowing you to authorize into third-party services, such as Zendesk via Basic Auth. This feature is useful for scenarios where your policy needs to check external data, e.g. for verifying if an employee has been assigned an open ticket for the user whose data they are trying to access.
 
-### Example:
+### Example
 
 This example shows how to make a network request to verify the user's country based on their IP address. Note that the interface for `networkRequest` is synchronous, as in the example below:
 
-```
+```javascript
 function policy(context, params) {  
   let countryCode = null;  
   const resp = networkRequest({url: `https://api.iplocation.net/?ip=${context.server.ip_address}`, method: 'GET' });  
@@ -151,13 +151,13 @@ function policy(context, params) {
 }
 ```
 
-### Example:
+### Example
 
-This example shows how to verify an employee is active in a private employee directory, using Basic Auth. 
+This example shows how to verify an employee is active in a private employee directory, using Basic Auth.
 
-#### Template Function:
+#### Template Function
 
-```
+```javascript
 function policy(context, params) {  
   let isActiveEmployee = false;
 
@@ -181,7 +181,7 @@ function policy(context, params) {
 
 #### Parameters to instantiate a policy
 
-```
+```javascript
 // Example Policy Parameters (not specified in the template function)
 const params = {};  // No specific parameters needed for this example
 ```
@@ -192,11 +192,11 @@ const params = {};  // No specific parameters needed for this example
 
 The `checkAttribute` function runs a permission check against the UserClouds authorization graph. If you are using UserClouds for authorization as a service, this can verify if a user has the necessary permissions. In short, it asks whether a given object (usually a user) has an attribute (e.g. "can-read" or "is-admin") on another object (which could be just about any entity in your system). You can read more about this in the [Authorization Documentation](https://docs.userclouds.com/reference/get_authz-checkattribute).
 
-### Example:
+### Example
 
 **Use Case: Does the calling user have view permission on the target user?**
 
-```
+```javascript
 function policy(context) {
     const callingUserId = context.user.id;
     const targetUserId = context.params.targetUserId;
@@ -217,7 +217,7 @@ function policy(context) {
 - `country_name`: the ISO 3166 country name, as defined [here](https://github.com/OpenStars/phonenumber/blob/8ad15782bef1/iso3166.go) ; and
 - `country_code`: the numeric telephone country code
 
-### Example:
+### Example
 
 ```javascript
 function policy(context, params) {  

content/docs/data-access/how-to-guides/create-an-access-policy.md

@@ -18,7 +18,6 @@ Access policies and templates are managed under the Access Rules element in the
 
 ![Policies and templates can be managed from the Policies page, accessible from the sidebar of UserClouds Console.](https://files.readme.io/184bfbc-image_4.png)
 
-
 ## Creating Policy Templates in the UI
 
 Policy templates are parametrizable functions that can be parametrized to create access policies. To create a policy template, go to the Policies page and click Create Policy Template. 
@@ -36,7 +35,6 @@ Use the "Test Your Draft" card at the bottom of the page to test your policy tem
 
 ![The "Test Your Draft" card allows you to parametrize your draft template (creating an access policy) and then test that access policy with test context.](https://files.readme.io/ef73d2e-spaces_66DzLwptb2SejhKV7Bhn_uploads_oGa62N4DTjIR8mFABEN5_image.webp)
 
-
 ## Creating Access Policies in the UI
 
 **1 Open the Create Access Policy Page**
@@ -83,7 +81,7 @@ The checkAttribute function runs a permission check against the UserClouds autho
 
 **Use Case: Does the calling user have view permission on the target user?**
 
-```
+```javascript
 function policy(context) {  
     const callingUserId = context.user.id;  
     const targetUserId = context.params.targetUserId;  
@@ -103,7 +101,7 @@ Parametrizable templates let you create flexible policies by adjusting parameter
 
 ### Example: User is N Years Old
 
-```
+```javascript
 function getAge(DOB) {  
     const today = new Date();  
     const birthDate = new Date(DOB);  

content/docs/data-access/how-to-guides/edit-existing-user-data/execute-a-mutator.md

@@ -6,14 +6,14 @@ hidden: false
 createdAt: "Fri Feb 09 2024 20:18:55 GMT+0000 (Coordinated Universal Time)"
 updatedAt: "Tue Jul 30 2024 18:09:50 GMT+0000 (Coordinated Universal Time)"
 ---
-Once you have configured a <<glossary:mutator>>, you are ready to edit the user data and consents in your store. This can be done by executing the mutator. 
+Once you have configured a <<glossary:mutator>>, you are ready to edit the user data and consents in your store. This can be done by executing the mutator.
 
 ## How to execute a mutator
 
-There are two ways to execute a mutator: 
+There are two ways to execute a mutator:
 
 - Download and deploy your tenant's code-generated UserClouds SDK, and call the mutator indirectly using its SDK function name
-- Call the [ExecuteMutator API](https://docs.userclouds.com/reference/post_userstore-api-mutators) 
+- Call the [ExecuteMutator API](https://docs.userclouds.com/reference/post_userstore-api-mutators)
 
 When calling the ExecuteMutator API directly you pass:
 
@@ -34,7 +34,7 @@ When you execute a mutator, the following steps happen in sequence:
 
 1. The mutator validates and normalizes the inbound data for each column associated with the mutator, using the configured <<glossary:data normalizer>> for that column.
 2. The mutator finds candidate user records to update based on the mutator <<glossary:selector>> clause and the passed in <<glossary:SelectorValues>>.
-3. Two access policies are applied to each selected user record: the global baseline policy for mutators (learn more [here](https://docs.userclouds.com/docs/apply-global-protection-policies)) and the mutator's own <<glossary:access policy>> composition. This step may involve evaluating the provided client context or any user-specific data already present in the User Store to determine if the write operation is permitted for each selector user record. 
+3. Two access policies are applied to each selected user record: the global baseline policy for mutators (learn more [here](https://docs.userclouds.com/docs/apply-global-protection-policies)) and the mutator's own <<glossary:access policy>> composition. This step may involve evaluating the provided client context or any user-specific data already present in the User Store to determine if the write operation is permitted for each selector user record.
 4. If the access policy passes for the user, the mutator reconciles the normalized changes for each mutator column against existing user data, utilizing full mutation or partial mutation rules according to the column's configuration (see below for more detail).
 5. Any resulting changes to the user's data and associated consents are saved to the store.
 
@@ -65,7 +65,7 @@ For this example, assume we are updating a column configured to be an array of s
 
 1. **insert value with operational and marketing consents**
 
-   ```
+   ```plaintext
    ValueAndPurposes = {  
    	Value: [“foo”, “bar”],  
    	PurposeAdditions: [“operational”, “marketing”],  
@@ -76,6 +76,7 @@ For this example, assume we are updating a column configured to be an array of s
    	("bar", ["operational", "marketing"]),  
    ]
    ```
+   
 2. **add data_science and remove marketing consents for existing values**
 
    ```
@@ -90,6 +91,7 @@ For this example, assume we are updating a column configured to be an array of s
    	("bar", ["operational", "data_science"]),  
    ]
    ```
+
 3. **update values, adding fraud_prevention consent**
 
    ```
@@ -103,6 +105,7 @@ For this example, assume we are updating a column configured to be an array of s
    	("baz", ["operational", “data_science”, "fraud_prevention"]),  
    ]
    ```
+   
 4. **delete all values**
 
    ```

content/docs/data-access/how-to-guides/enforce-rate-limiting.md

@@ -20,7 +20,7 @@ UserClouds applies rate limits to a given user based on the `sub` (subject) clai
 
 The `AccessPolicyThresholds` structure defines the parameters for rate limiting:
 
-```
+```javascript
 type AccessPolicyThresholds = {  
   announce_max_execution_failure: boolean;  
   announce_max_result_failure: boolean;  
@@ -39,7 +39,7 @@ Execution limits control how often an action can be performed within a specific
 
 Execution limits execute specially when a paginated accessor is called. The initial call is treated as one execution. Paging forward or backward from that initial call is not counted as another execution.
 
-### Behavior:
+### Behavior
 
 - If `announce_max_execution_failure` is true, a 429 (Too Many Requests) error is returned when the limit is exceeded for accessors and mutators. Failures for token resolution are always silent (i.e., the token is not resolved).
 - If `announce_max_execution_failure` is false, the request does not fail, but no actions will occur. That is, no results are returned (for accessors), modifications are not applied (for mutators), or tokens are not resolved (for token resolution).
@@ -50,13 +50,13 @@ Result limits control the number of results that can be returned or affected by
 
 - `max_results_per_execution`: Maximum number of results affected by a single execution. If this is 0, the limit is turned off.
 
-### Limit definition:
+### Limit definition
 
 - For accessors, this limit applies to the total number of results that could be returned, across all pages (if paginated). For example, an accessor that could return 6 different pages of 100 records each would exceed a 500 result limit, even though each individual page size is within the limit.
 - For mutators, it applies to the number of records modified.
 - For token resolution, it applies to the number of tokens resolved.
 
-### Behavior:
+### Behavior
 
 - If `announce_max_result_failure` is true, a 400 (Bad Request) error is returned when the limit is exceeded.
 - If `announce_max_result_failure` is false, the request does not fail, but no actions will occur. That is, no results are returned (for accessors), no modifications are applied (for mutators), or no tokens are resolved (for token resolution).
@@ -65,15 +65,15 @@ Result limits control the number of results that can be returned or affected by
 
 Rate limiting is enabled by associating an access policy with rate limits to a mutator, accessor, or token. For tokens, the access policy is specified at token creation time (e.g. via the token resolution policy on an accessor returning the token).
 
-### Token Resolution Note:
+### Token Resolution Note
 
 Failures are always silent (no error code is returned), as token resolution requests may involve multiple access policies, some of which may have rate limits and some may not.
 
 ## Example Usage
 
 To set rate limits for an access policy, configure the `AccessPolicyThresholds`:
 
-```
+```javascript
 const accessPolicy: AccessPolicy = {  
   thresholds: {  
     announce_max_execution_failure: true,  
@@ -86,7 +86,7 @@ const accessPolicy: AccessPolicy = {
 };
 ```
 
-The rate limit thresholds for an access policy may be changed after the access policy is created. 
+The rate limit thresholds for an access policy may be changed after the access policy is created.
 
 Note that we only consider the thresholds for the top level access policy for the accessor / mutator / token resolution. Since an access policy can be composed of multiple access policies, a sub-policy may have usage thresholds. Those thresholds would be ignored.
 

content/docs/data-access/proxy-and-plug-in-implementation/3-applying-access-policies-to-queries.md

@@ -14,16 +14,16 @@ Once you have re-pointed your application’s database queries, object store req
 
 Access policies are evaluated per row of returned data from the database. Therefore, if an access policy evaluates row-specific data returned from the database (such as a target user’s date of birth), it may return a subset of records.
 
-### To Apply an Access Policy to a Particular Query:
+### To Apply an Access Policy to a Particular Query
 
 1. **Trigger the Query, Request, or API Call**: Trigger the action in the application if you haven’t already (e.g., by loading a table of data, requesting an object from storage, or calling an API endpoint).
-2. **Select and Edit the Query, Blob Store, or API Call:** 
+2. **Select and Edit the Query, Blob Store, or API Call:**
    1. **For SQL Proxies:** In the UserClouds Console, go to Accessors (under Access Methods), find the relevant query in your list of data accessors, and click "Edit".
    2. **For NoSQL Proxies:** In the UserClouds Console, navigate to Object Stores under User Data Storage in the side navigation, select the object store, and click "Edit".
    3. **For API Proxies:** In the UserClouds Console, navigate to API connections under User Data Storage in the side navigation, select the API connection, and click "Edit".
 3. **Add Access Policies**: Scroll down to the access policy section and add one or more access policies.
-   1. **For SQL Proxies: **Apply policies at the query level.
-   2. **For NoSQL Proxies: **Apply policies at the object store level, but you can also consider the file path as context (e.g., a user ID in the file path) for finer-grained access control.
+   1. **For SQL Proxies:** Apply policies at the query level.
+   2. **For NoSQL Proxies:** Apply policies at the object store level, but you can also consider the file path as context (e.g., a user ID in the file path) for finer-grained access control.
    3. **For API Proxies**: Apply policies at the individual endpoint level.
 4. **Define Policy Logic**: If adding two or more access policies, define whether all policies or one policy must be true for the overall policy to pass, by ANDing or ORing the policies together.
 5. **Save**: Click "Save".
@@ -38,7 +38,7 @@ Access policies can evaluate context passed in the request. Context can be inclu
 
 This example shows how context is added to a query using comments:
 
-```
+```sql
 SELECT name, email, phone FROM users WHERE id = 1234 /*geo=’uk’ user=’albus-dumbledore’*/
 ```
 
@@ -48,7 +48,7 @@ SELECT name, email, phone FROM users WHERE id = 1234 /*geo=’uk’ user=’albu
 
 This example shows how an access policy might use the context to enforce access control:
 
-```
+```javascript
 function policy(context, params) {  
     // Allow access only if the calling user's geo is 'uk'  
     return context.client.geo === 'uk';