Skip to content

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

Open
wants to merge 22 commits into
base: major-next
Choose a base branch
from

Conversation

Dhaiven
Copy link
Contributor

@Dhaiven Dhaiven commented Feb 20, 2025

Related issues & PRs

Fix #6536

Changes

API changes

  • All functions thath use Permission now just accept Permission instead of Permission|string
  • Remove DefaultPermissionNames (use DefaultPermissions)
  • Now DefaultPermissions use RegisteryTrait -> contains all permissions added by pocketmine

Behavioural changes

Backwards compatibility

BC Break (see API changes)

Follow-up

Tests

Test Ingame with vanilla commands but without commands added by plugins

@Dhaiven Dhaiven requested a review from a team as a code owner February 20, 2025 18:38
@Dhaiven Dhaiven changed the title Permission Always use Permission objects instead of string Feb 20, 2025
Copy link
Member

@dktapps dktapps left a 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.

@dktapps dktapps added Category: API Related to the plugin API BC break Breaks API compatibility Type: Enhancement Contributes features or other improvements to PocketMine-MP Status: Waiting on Author labels Feb 23, 2025
Copy link
Member

@ShockedPlot7560 ShockedPlot7560 left a 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.

@Dhaiven
Copy link
Contributor Author

Dhaiven commented Feb 28, 2025

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:

  • create Permission::create function with same parameters thath the constructor and put the constructor private. It's like the constructor but register automaticly the Permission to PermissionManager (Big BC-Break)
  • In Permission constructor, registery automaticly the permission to PermissionManager (No BC-Brreak for this but it's less logic)

@ShockedPlot7560
Copy link
Member

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

@dktapps
Copy link
Member

dktapps commented Feb 28, 2025

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 new Permission and not registering it

@Dhaiven
Copy link
Contributor Author

Dhaiven commented Mar 5, 2025

How do you want me to solve this problem ? I see solutions but it's horible solutions

@dktapps
Copy link
Member

dktapps commented Mar 8, 2025

Without breaking BC, the only way I see is to have Permission::__construct() call PermissionManager::addPermission(). I can't think of a use-case for constructing an unregistered permission anyway.

dktapps added 2 commits March 8, 2025 23:50
perhaps we should have checkInit() public by default?

I'm not sure that explicitly initializing this registry is the proper solution, though...
Comment on lines +114 to 116
public function unsetPermission(Permission $permission) : void{
$name = $permission->getName();
if(isset($this->permissions[$name])){
Copy link
Member

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.

Comment on lines +178 to +181
$permission = PermissionManager::getInstance()->getPermission($data->getPermission());
if ($permission !== null) {
$newCmd->setPermission($permission);
}
Copy link
Member

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 ?

Copy link

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.

@github-actions github-actions bot added the Stale label Apr 26, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
BC break Breaks API compatibility Category: API Related to the plugin API Stale Status: Waiting on Author Type: Enhancement Contributes features or other improvements to PocketMine-MP
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants