feat: respect AutoSave flag for grouping policy operations #395
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Based on the documentation for
EnableAutoSave(), which states it "controls whether to save a policy rule automatically to the adapter when it is added or removed," we believe AutoSave should apply uniformly to all policy operations, including both regular policies and grouping policies.However, we discovered that grouping policy operations were not respecting the AutoSave flag. This PR addresses that inconsistency.
Note: This issue was discovered while working on adding support for multiple
CasbinDbContextinstances in the EFCore adapter (see casbin-net/EFCore-Adapter#125), where proper AutoSave behavior is essential for correct adapter operation.Problem
The
EnableAutoSave(false)setting was not being respected for RBAC/grouping policy operations:AddPolicy(),RemovePolicy(),UpdatePolicy()did not save to adapter when AutoSave was disabledAddGroupingPolicy(),RemoveGroupingPolicy(),UpdateGroupingPolicy()still saved to adapter even when AutoSave was disabledRoot Cause
The
SetAutoSave()method inCasbin/Extensions/Model/ModelExtension.csonly iterated through policy assertions (section "p") to set the AutoSave flag. It never set the flag for role assertions (section "g"), even thoughRoleAssertionhas its ownPolicyManagerwith anAutoSaveproperty.Solution
Modified
SetAutoSave()to configure the AutoSave flag for both policy and role/grouping assertions:The fix includes a safety check (
ContainsSection) to handle models without role definitions.Changes
Modified Files
Casbin/Extensions/Model/ModelExtension.cs
SetAutoSave()method to configure AutoSave for both policy and role assertionsCasbin.UnitTests/ModelTests/EnforcerTest.cs
TestAutoSaveGroupingPolicy()- Verifies synchronous grouping policy operations respect AutoSaveTestAutoSaveGroupingPolicyAsync()- Verifies asynchronous grouping policy operations respect AutoSaveCasbin.UnitTests/Mock/MockSingleAdapter.cs (new file)
ISingleAdapterTesting
Impact
Affected Methods (Now Fixed)
All grouping policy methods now properly respect the AutoSave flag:
AddGroupingPolicy()/AddGroupingPolicyAsync()AddGroupingPolicies()/AddGroupingPoliciesAsync()RemoveGroupingPolicy()/RemoveGroupingPolicyAsync()RemoveGroupingPolicies()/RemoveGroupingPoliciesAsync()UpdateGroupingPolicy()/UpdateGroupingPolicyAsync()UpdateGroupingPolicies()/UpdateGroupingPoliciesAsync()RemoveFilteredGroupingPolicy()/RemoveFilteredGroupingPolicyAsync()Backward Compatibility
We believe this fix aligns with the documented behavior and design intent of the AutoSave feature. However, if there was an intentional reason for the previous behavior, we're happy to discuss alternative approaches.