refactor: rename implicit_authorization to explicit_authorization (#300)

Author: Paul-Bob

docs/3.0/authorization.md

@@ -541,8 +541,13 @@ end
 ```
 </Option>
 
-## Implicit authorization
-<Option name="`implicit_authorization`">
+## Explicit authorization
+
+<Option name="`explicit_authorization`">
+
+:::warning Option Renamed
+In versions between <Version version="3.13.4" /> and <Version version="3.13.6" />, this option is named `implicit_authorization`.
+:::
 
 <VersionReq version="3.13.4" />
 
@@ -558,22 +563,22 @@ end
   - If a policy class or method is **missing**, the action will be considered **authorized** by default.
 
 **`Proc`**
-  - You can also set `implicit_authorization` as a `Proc` to apply custom logic. Within this block, you gain access to all attributes of [`Avo::ExecutionContext`](execution-context)
+  - You can also set `explicit_authorization` as a `Proc` to apply custom logic. Within this block, you gain access to all attributes of [`Avo::ExecutionContext`](execution-context)
 
     For example:
 
     ```ruby
-    config.implicit_authorization = -> {
+    config.explicit_authorization = -> {
       current_user.access_to_admin_panel? && !current_user.admin?
     }
     ```
 
-    In this case, missing policies will be handled based on the condition: if the user has access to the admin panel but isn't an admin, the `implicit_authorization` will be enabled. This option allows you to customize authorization decisions based on the context of the current user or other factors.
+    In this case, missing policies will be handled based on the condition: if the user has access to the admin panel but isn't an admin, the `explicit_authorization` will be enabled. This option allows you to customize authorization decisions based on the context of the current user or other factors.
 ### Default
 
-- For **new applications** (starting from Avo `3.13.4`) the default value for `implicit_authorization` is `true`. This provides a more secure out-of-the-box experience by ensuring actions without explicit authorization are denied.
+- For **new applications** (starting from Avo `3.13.4`) the default value for `explicit_authorization` is `true`. This provides a more secure out-of-the-box experience by ensuring actions without explicit authorization are denied.
 
-- For **existing applications** upgrading to `3.13.4` or later the default value for `implicit_authorization` remains `false` to preserve backward compatibility. Existing applications will retain the permissive behavior unless explicitly changed.
+- For **existing applications** upgrading to `3.13.4` or later the default value for `explicit_authorization` remains `false` to preserve backward compatibility. Existing applications will retain the permissive behavior unless explicitly changed.
 
 ### Configuration:
 
@@ -583,13 +588,13 @@ You can configure this setting in your `config/avo.rb` file:
 Avo.configure do |config|
   # Set to true to deny access when policies or methods are missing
   # Set to false to allow access when policies or methods are missing
-  config.implicit_authorization = true
+  config.explicit_authorization = true
 end
 ```
 
 ### Examples:
 
-1. **When `implicit_authorization` is `true`**
+1. **When `explicit_authorization` is `true`**
     - **Scenario**: You have a `Post` resource, but there is no policy class defined for it.
     - **Result**: All actions for the `Post` resource (index, show, create, etc.) will be **unauthorized** unless you explicitly define a policy class and methods for those actions.
 
@@ -605,7 +610,7 @@ end
     ```
     - **Result**: In this case, since the `PostPolicy` lacks an `index?` method, attempting to access the `index` action will be denied by default.
 
-2. **When `implicit_authorization: false`**
+2. **When `explicit_authorization: false`**
     - **Scenario**: Same `Post` resource without a policy class.
     - **Result**: All actions for the `Post` resource will be **authorized** even though there are no explicit policy methods. This could expose unintended behavior, as any unprotected action will be accessible.
 
@@ -626,13 +631,13 @@ end
 
 - **For applications after from Avo `3.13.4`**
 
-    It is recommended to leave `implicit_authorization` set to `true`, ensuring all actions must be explicitly authorized to prevent unintentional access.
+    It is recommended to leave `explicit_authorization` set to `true`, ensuring all actions must be explicitly authorized to prevent unintentional access.
 
 - **For applications before from Avo `3.13.4`**
 
-    - If upgrading from an earlier version, carefully review your policies before enabling `implicit_authorization`. Missing policy methods that were previously allowing access will now deny access unless explicitly defined.
+    - If upgrading from an earlier version, carefully review your policies before enabling `explicit_authorization`. Missing policy methods that were previously allowing access will now deny access unless explicitly defined.
 
-    - It’s recommended to disable [`raise_error_on_missing_policy`](authorization.html#raise-errors-when-policies-are-missing) in production, though it's not mandatory. When `implicit_authorization` is set to `true`, the default behavior is to deny access for actions without a defined policy. In this case, it’s often better to show an unauthorized message to users rather than raise an error. However, keeping [`raise_error_on_missing_policy`](authorization.html#raise-errors-when-policies-are-missing) enabled in development can be helpful for identifying missing policy classes.
+    - It’s recommended to disable [`raise_error_on_missing_policy`](authorization.html#raise-errors-when-policies-are-missing) in production, though it's not mandatory. When `explicit_authorization` is set to `true`, the default behavior is to deny access for actions without a defined policy. In this case, it’s often better to show an unauthorized message to users rather than raise an error. However, keeping [`raise_error_on_missing_policy`](authorization.html#raise-errors-when-policies-are-missing) enabled in development can be helpful for identifying missing policy classes.
 </Option>
 
 ## Rolify integration

docs/3.0/upgrade.md

@@ -3,16 +3,29 @@
 We'll update this page when we release new Avo 3 versions.
 
 If you're looking for the Avo 2 to Avo 3 upgrade guide, please visit [the dedicated page](./avo-2-avo-3-upgrade).
+## Upgrade from 3.13.6 to 3.13.7
+
+The `implicit_authorization` option has been renamed to `explicit_authorization` to better align with the feature's functionality. The underlying logic remains unchanged, so you only need to perform a rename if you're already using it.
+
+```ruby
+config.implicit_authorization = true # [!code --]
+config.explicit_authorization = true # [!code ++]
+```
+
 
 ## Upgrade from 3.13.3 to 3.13.4
 
 <Option name="`implicit_authorization`">
 
-We’ve introduced the [`implicit_authorization`](authorization.html#implicit_authorization) configuration option to enhance the security of your applications. This option allows you to define how missing policy classes or methods are handled. When set to `true`, any action without an explicitly defined policy will automatically be denied, ensuring that unprotected actions are not unintentionally accessible. This new behavior offers a more secure approach for authorization.
+:::warning Option Renamed
+<VersionReq version="3.13.7" /> this option was renamed to `explicit_authorization`.
+:::
+
+We’ve introduced the [`implicit_authorization`](authorization.html#explicit_authorization) configuration option to enhance the security of your applications. This option allows you to define how missing policy classes or methods are handled. When set to `true`, any action without an explicitly defined policy will automatically be denied, ensuring that unprotected actions are not unintentionally accessible. This new behavior offers a more secure approach for authorization.
 
-For new applications, [`implicit_authorization`](authorization.html#implicit_authorization) is enabled by default, but existing applications will retain the legacy behavior (`false`), allowing missing policies or methods to authorize actions. We encourage you to adopt this new setting by enabling [`implicit_authorization`](authorization.html#implicit_authorization), as it provides greater control over your authorization flow and reduces the risk of unauthorized access due to missing policies. Before enabling it, be sure to review your policy classes to ensure all necessary methods are defined, preventing any unintended access restrictions.
+For new applications, [`implicit_authorization`](authorization.html#explicit_authorization) is enabled by default, but existing applications will retain the legacy behavior (`false`), allowing missing policies or methods to authorize actions. We encourage you to adopt this new setting by enabling [`implicit_authorization`](authorization.html#explicit_authorization), as it provides greater control over your authorization flow and reduces the risk of unauthorized access due to missing policies. Before enabling it, be sure to review your policy classes to ensure all necessary methods are defined, preventing any unintended access restrictions.
 
-We highly recommend taking a moment to read through the entire [`implicit_authorization`](authorization.html#implicit_authorization) documentation section before making any changes. Understanding this feature is crucial to ensuring your application's security and functionality, so don’t skip it!
+We highly recommend taking a moment to read through the entire [`implicit_authorization`](authorization.html#explicit_authorization) documentation section before making any changes. Understanding this feature is crucial to ensuring your application's security and functionality, so don’t skip it!
 </Option>