v0.6.2-stable

What's Changed

Read the last PR for more details : [Improvements] Refactor the unset abilities by @AlexzPurewoko in #3

Summary :

• Improving the algorithm when dealing with unset ability. Previously, the algorithm can remove only the specific rule. For now, it can remove multiple rules specified by the 'star' (whole) parameters on action, resource and field.
  Example Rule :

   #ID. RULE
     1. scope:resource/666:*
     2. scope:resource2/7:read
     3. scope:resource2/*:update
     4. scope2:resource/*:read
  

  We can delete the multiple rule by input the asterisk on resource, field and action.

  • Delete the whole resource and whole action in one scope. Just pass -> unsetAbility('*', '*', 'scope');. All rule except rule with ID 4 will be deleted.
  • Delete the whole resource but specific action. Just pass -> unsetAbility('update', '*', 'scope');. This will delete the rule with ID 3.
  • Delete the whole action in specific resource. Just pass -> unsetAbility('*', 'resource2', 'scope');. This will delete the rule with ID 3 and 4.
  • And more... (read on the last pull requests).

• Unset ability can remove specific field from arrayable fields. Take an example for this rule -> scope:resource/[5,6,7,8]:read. We can remove the rule/item's field by :

  • Using specific field -> unsetAbility('read', 'resource', 'scope', 5);. So, the item 5 will be removed from existing rule, and for the item field (except 5) will be remain (exist). Result : scope:resource/[6,7,8]:read
  • Multiple specific field -> unsetAbility('read', 'resource', 'scope', [5, 7]);. So, the item 5 and 7 will be removed from existing rule, and for the item field (except 5 and 7) will be remain (exist). Result : scope:resource/[6,8]:read
  • Remove the corresponding rule -> unsetAbility('read', 'resource', 'scope', [5, 7, 6, 8]);. This will remove the rule from the list/storage.

Compare : v0.6.1-stable...v0.6.2-stable

v0.6.1-stable

Fix bug related with can() ability checking. The bug occurs when dealing with this rule (example with User A)

!scope:resourceA/*:review
scope:resourceA/{"author": 'A'}:*

It means that the User A :

1. Cannot do review on all field of resourceA
2. Can do anything (except review) on resourceA authored by User A (specific author field)

From the previous version, the user cannot do action described in number 2 above. But it already fixed on this release version

v0.6.0

• Fix the bug related to can() algorithm, specifically for dealing with inversion rules.
  Before: Only specific inverted rule that returns false when checking using can() method
  Now: Whole and specific inverted rule returning false when check using can() method

v0.5.9-stable

• Fix the bugs related to passing invalid strings on scope, resource, or action
• Fix RuleCompiler case when compiling inverted rules. The '!' negation still being passed on Scope name
• Revamp the API for create, update, and delete ability rule into API setAbility() and unsetAbility()
• Change hasRule to hasExactRule
• Some bugfix to the algorithm and test

v0.5.8

Changes :

• Update on logic when finding the existing rule (getRuleOf())
• Remove some unused code
• Modify some names (enum names, method names)

v0.5.7-stable

Minor changes for StorageInterface. Add the reference for current user id

v0.5.6-stable

Tidying up the implementation and fix some concerns :

• Disallow setUserId directly from repository, as we need to prohibit changes during the active session. Instead of set on demand, we provide the user id on the repository creation.
• Split the focus of repository from mutable and readonly repository.
• Pulling back the minimum support of PHP (8.1.0 minimal)

v0.5.0-stable

Initial stable for abilities permission checker