-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Always use Permission
objects instead of string
#6638
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: major-next
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After seeing the changes I'm less convinced of the value of doing this. The issue is that using Permission
objects does not guarantee that the permission in question is actually registered.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm on the way of @dktapps for the real value of this. As Permission doesn't guarantee that the object itself is registered, I don't necessarily see the need to manipulate objects. After that, if you manage to find a system that permit it, why not, but I don't see any solution for the moment.
I thought at 2 solutions:
|
The best solution would be the PermissionManager returning the Permission object and you need to create it via PermissionManager to use them. But idk how this could be applied in a clean way |
This wouldn't prevent people from doing |
How do you want me to solve this problem ? I see solutions but it's horible solutions |
Without breaking BC, the only way I see is to have |
perhaps we should have checkInit() public by default? I'm not sure that explicitly initializing this registry is the proper solution, though...
public function unsetPermission(Permission $permission) : void{ | ||
$name = $permission->getName(); | ||
if(isset($this->permissions[$name])){ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be great to keep the ability to unset by the name.
$permission = PermissionManager::getInstance()->getPermission($data->getPermission()); | ||
if ($permission !== null) { | ||
$newCmd->setPermission($permission); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An exception should be raised in this case, no ?
This PR has been marked as "Waiting on Author", but we haven't seen any activity in 7 days. If there is no further activity, it will be closed in 28 days. Note for maintainers: Adding an assignee to the PR will prevent it from being marked as stale. |
Related issues & PRs
Fix #6536
Changes
API changes
Permission
instead ofPermission|string
DefaultPermissionNames
(useDefaultPermissions
)DefaultPermissions
useRegisteryTrait
-> contains all permissions added by pocketmineBehavioural changes
Backwards compatibility
BC Break (see API changes)
Follow-up
Tests
Test Ingame with vanilla commands but without commands added by plugins