Skip to content
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

Always use Permission objects instead of string #6638

Open
wants to merge 13 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.

Comment on lines +30 to +35
/**
* @method static Permission BROADCAST_ADMIN()
* @method static Permission BROADCAST_USER()
* @method static Permission COMMAND_BAN_IP()
* @method static Permission COMMAND_BAN_LIST()
* @method static Permission COMMAND_BAN_PLAYER()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This does not appear to be self-generating

@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

@@ -1007,8 +1007,6 @@ public function __construct(
)));
$this->logger->info($this->language->translate(KnownTranslationFactory::pocketmine_server_license($this->getName())));

DefaultPermissions::registerCorePermissions();

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only just caught this, but this could be problematic if plugins register permissions that conflict with the built-in ones. RegistryTrait will only register the permissions when the first permission is accessed. Sure, technically SimpleCommandMap should trigger it but I don't feel happy about relying on that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Protecting the namespace pocketmine. for registering permission could be a solution. I don't really like it but I don't see another way to do it atm

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure how that would work without pre-registering the permissions somehow. Maybe PermissionManager::make() should do it similar to how we setup states for RuntimeBlockStateRegistry.

public function __construct(array $basePermissions){
$this->permissibleBase = new PermissibleInternal($basePermissions);
public function __construct(){
$this->permissibleBase = new PermissibleInternal();
Copy link
Contributor Author

@Dhaiven Dhaiven Feb 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure of this change. What's the utility of permissibleBase ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's for getting rid of cyclic references. Not related to the PR topic.

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 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