feat(build): migrate from Prettier to Oxfmt for performant code formatting (#42434)

docs/admin_docs_versioned_docs/version-6.1.0/security/security.mdx

@@ -24,13 +24,13 @@ A table with the permissions for these roles can be found at [/RESOURCES/STANDAR
 Admins have all possible rights, including granting or revoking rights from other
 users and altering other people’s slices and dashboards.
 
->#### Threat Model and Privilege Boundaries: The Admin Role
+> #### Threat Model and Privilege Boundaries: The Admin Role
 >
->Apache Superset is built with a granular permission model where users assigned the Admin role are considered fully trusted. Admins possess complete control over the application's configuration, UI rendering, and access controls.
+> Apache Superset is built with a granular permission model where users assigned the Admin role are considered fully trusted. Admins possess complete control over the application's configuration, UI rendering, and access controls.
 >
->Consequently, actions performed by an Admin that alter the application's behavior or presentation—such as injecting custom CSS, modifying Jinja templates, or altering security flags—are intended administrative capabilities by design.
+> Consequently, actions performed by an Admin that alter the application's behavior or presentation—such as injecting custom CSS, modifying Jinja templates, or altering security flags—are intended administrative capabilities by design.
 >
->In accordance with MITRE CNA Rule 4.1, a vulnerability must represent a violation of an explicit security policy. Because the Admin role is defined as a trusted operational boundary, actions executed with Admin privileges do not cross a security perimeter. Therefore, exploit vectors that strictly require Admin access are not classified as security vulnerabilities and are ineligible for CVE assignment.
+> In accordance with MITRE CNA Rule 4.1, a vulnerability must represent a violation of an explicit security policy. Because the Admin role is defined as a trusted operational boundary, actions executed with Admin privileges do not cross a security perimeter. Therefore, exploit vectors that strictly require Admin access are not classified as security vulnerabilities and are ineligible for CVE assignment.
 
 ### Alpha
 
@@ -54,10 +54,10 @@ to all databases by default, both **Alpha** and **Gamma** users need to be given
 
 Beyond the base `sql_lab` role, two additional SQL Lab permissions must be explicitly granted for users who need these capabilities:
 
-| Permission | Feature |
-|------------|---------|
-| `can_estimate_query_cost` on `SQLLab` | Estimate query cost before running |
-| `can_format_sql` on `SQLLab` | Format SQL using the database's dialect |
+| Permission                            | Feature                                 |
+| ------------------------------------- | --------------------------------------- |
+| `can_estimate_query_cost` on `SQLLab` | Estimate query cost before running      |
+| `can_format_sql` on `SQLLab`          | Format SQL using the database's dialect |
 
 Grant these in **Security → List Roles** by adding the permissions to the relevant role.
 
@@ -73,6 +73,7 @@ users who need to view dashboards. It provides minimal read-only access for:
 - Viewing annotations on charts
 
 The Public role explicitly excludes:
+
 - Any write permissions on dashboards, charts, or datasets
 - SQL Lab access
 - Share functionality
@@ -161,12 +162,14 @@ With this enabled, you can assign specific roles to each dashboard in its proper
 will only see dashboards where their role is explicitly added.
 
 **Important considerations:**
+
 - Dashboard access **bypasses** dataset-level checks—granting a role access to a dashboard
   implicitly grants read access to all charts and datasets in that dashboard
 - Dashboards without any assigned roles fall back to dataset-based access
 - The dashboard must still be published to be visible
 
 This feature is particularly useful for:
+
 - Making specific dashboards public while keeping others private
 - Granting access to dashboards without exposing the underlying datasets for other uses
 - Creating dashboard-specific access patterns that don't align with dataset ownership
@@ -184,10 +187,11 @@ However, it is crucial to understand the following:
 **Database Security is Paramount**: The ultimate responsibility for securing database access, controlling permissions, and preventing unauthorized function execution lies with the database administrators (DBAs) and security teams managing the underlying database instance.
 
 **Recommended Database Practices**: We strongly recommend implementing security best practices at the database level, including:
-* **Least Privilege**: Connecting Superset using dedicated database user accounts with the minimum permissions required for Superset's operation (typically read-only access to necessary schemas/tables).
-* **Database Roles & Permissions**: Utilizing database-native roles and permissions to restrict access to sensitive functions, system variables (like `@@hostname`), schemas, or tables.
-* **Network Security**: Employing network-level controls like database firewalls or proxies to restrict connections.
-* **Auditing**: Enabling database-level auditing to monitor executed queries and access patterns.
+
+- **Least Privilege**: Connecting Superset using dedicated database user accounts with the minimum permissions required for Superset's operation (typically read-only access to necessary schemas/tables).
+- **Database Roles & Permissions**: Utilizing database-native roles and permissions to restrict access to sensitive functions, system variables (like `@@hostname`), schemas, or tables.
+- **Network Security**: Employing network-level controls like database firewalls or proxies to restrict connections.
+- **Auditing**: Enabling database-level auditing to monitor executed queries and access patterns.
 
 By combining Superset's configurable safeguards with strong database-level security practices, you can achieve a more robust and layered security posture.
 
@@ -341,11 +345,11 @@ rules are:
 
 For example, if a dataset has three filters:
 
-| Filter | Clause | Group Key |
-|--------|--------|-----------|
-| F1 | `department = 'Finance'` | `department` |
-| F2 | `department = 'Marketing'` | `department` |
-| F3 | `region = 'Europe'` | `region` |
+| Filter | Clause                     | Group Key    |
+| ------ | -------------------------- | ------------ |
+| F1     | `department = 'Finance'`   | `department` |
+| F2     | `department = 'Marketing'` | `department` |
+| F3     | `region = 'Europe'`        | `region`     |
 
 The resulting WHERE clause would be:
 
@@ -429,7 +433,7 @@ GET /api/v1/rowlevelsecurity/<id>
 ```
 
 The response includes the filter's `name`, `filter_type` (Regular or Base), `clause`,
-`group_key`, assigned `tables` (with id, schema, and table\_name), and assigned `roles`
+`group_key`, assigned `tables` (with id, schema, and table_name), and assigned `roles`
 (with id and name).
 
 :::tip Auditing RLS for virtual datasets
@@ -476,13 +480,13 @@ This reduces the risk for replay attacks and session hijacking.
 Superset uses [Flask-Session](https://flask-session.readthedocs.io/en/latest/) to manage server side sessions.
 To enable this extension you have to set:
 
-``` python
+```python
 SESSION_SERVER_SIDE = True
 ```
 
 Flask-Session offers multiple backend session interfaces for Flask, here's an example for Redis:
 
-``` python
+```python
 from redis import Redis
 
 SESSION_TYPE = "redis"
@@ -511,8 +515,8 @@ It's extremely important to correctly configure a Content Security Policy when d
 prevent many types of attacks. Superset provides two variables in `config.py` for deploying a CSP:
 
 - `TALISMAN_ENABLED` defaults to `True`; set this to `False` in order to disable CSP
-- `TALISMAN_CONFIG` holds the actual the policy definition (*see example below*) as well as any
-other arguments to be passed to Talisman.
+- `TALISMAN_CONFIG` holds the actual the policy definition (_see example below_) as well as any
+  other arguments to be passed to Talisman.
 
 When running in production mode, Superset will check at startup for the presence
 of a CSP. If one is not found, it will issue a warning with the security risks. For environments
@@ -528,12 +532,12 @@ this warning using the `CONTENT_SECURITY_POLICY_WARNING` key in `config.py`.
   ```
 
 - Only scripts marked with a [nonce](https://content-security-policy.com/nonce/) can be loaded and executed.
-Nonce is a random string automatically generated by Talisman on each page load.
-You can get current nonce value by calling jinja macro `csp_nonce()`.
+  Nonce is a random string automatically generated by Talisman on each page load.
+  You can get current nonce value by calling jinja macro `csp_nonce()`.
 
   ```html
   <script nonce="{{ csp_nonce() }}">
-  /* my script */
+    /* my script */
   </script>
   ```
 
@@ -551,7 +555,7 @@ You can get current nonce value by calling jinja macro `csp_nonce()`.
   ```
 
 - Cartodiagram charts request map data (image and json) from external resources that can be edited by users,
-and therefore either require a list of allowed domains to request from or a wildcard (`'*'`) for `img-src` and `connect-src`.
+  and therefore either require a list of allowed domains to request from or a wildcard (`'*'`) for `img-src` and `connect-src`.
 
 - Other CSP directives default to `'self'` to limit content to the same origin as the Superset server.
 
@@ -562,12 +566,12 @@ In order to adjust provided CSP configuration to your needs, follow the instruct
 
 Setting `TALISMAN_ENABLED = True` will invoke Talisman's protection with its default arguments,
 of which `content_security_policy` is only one. Those can be found in the
-[Talisman documentation](https://pypi.org/project/flask-talisman/) under *Options*.
+[Talisman documentation](https://pypi.org/project/flask-talisman/) under _Options_.
 These generally improve security, but administrators should be aware of their existence.
 
 In particular, the option of `force_https = True` (`False` by default) may break Superset's Alerts & Reports
 if workers are configured to access charts via a `WEBDRIVER_BASEURL` beginning
-with `http://`.  As long as a Superset deployment enforces https upstream, e.g.,
+with `http://`. As long as a Superset deployment enforces https upstream, e.g.,
 through a load balancer or application gateway, it should be acceptable to keep this
 option disabled. Otherwise, you may want to enable `force_https` like this: