XF 2.3 Generating phrases using an add-on

[QuackieMackie]

I'm thinking about adding dynamic permissions to the https://github.com/Sylphian-Network/Sylphian-Library I was working on, but I'm unsure if this would be possible / easy.

The goal would be to when my add-on gets installed sweep the other installed add-ons and create permissions based of the results. When other addons get installed / uninstalled it would also update the permissions based of the listener. This would mean admins can control who has permission to view each add-on logs rather than a single permission to view them all.

I believe it can be done, but if it would be done cleanly is another matter.

---

So permissions seems to be easy to handle, I don't believe it's that complicated, but it's the phrases that leave me a little stumped. I'd need to generate a phrase with each add-on permission created. From what I can see of the database phrases has xf_phrase, xf_phrase_compiled, and phrase_map. Is anyone able to explain what these do?

Also just to make sure theres not an easy method I missed for generating phrases in add-ons is there?

 

[Sim]

I think you're trying to solve a problem that doesn't really need to be solved - I don't understand your use-case.

Exactly who are you going to be giving permissions to?

Admin permissions are intended to be high-level rather than fine-grained (like moderator or user permissions). Are you filtering database query results based on permissions? That's not really how permissions are supposed to work - they work at the controller level.

Why would one admin be able to view some logs but not others?

 

[QuackieMackie]

I think you're trying to solve a problem that doesn't really need to be solved - I don't understand your use-case.

Exactly who are you going to be giving permissions to?

Admin permissions are intended to be high-level rather than fine-grained (like moderator or user permissions). Are you filtering database query results based on permissions? That's not really how permissions are supposed to work - they work at the controller level.

Why would one admin be able to view some logs but not others?

Okay, let me clarify with an example use case:

I have two add-ons:

• Backup solution – might contain sensitive logs that I might want to restrict to certain admins.
• Community map – logs that are generally fine for all admins to see.

Right now, if I wanted to block a specific admin from viewing backup logs, I’d either need to:

• Create a separate logging mechanism for restricted access (which I don't want, I already had this in place but the point of the library was for me not to need to do this.)
• Or manually set up a permission for that specific addon and hard code that into my library.

Dynamic admin permissions would let me automate this process, creating per-add-on permissions without having to manually configure each one.

 

[Sim]

You're already creating a dependency between the addons - so just create the permissions (normally) at the addon level rather than the library level.

Then create a code event in your library that addons can hook into (via a code event listener) to register the relevant permission key from the addon itself.

Then in your library you can filter results based on registered addons permissions for the current user.

No need to programmatically create permissions - they are defined in the addon that is creating the logs - and then you're just using query filters to determine what logs the user can see.

Something like:

// this array is built by the addons via the code event listener
$adminPermissions = [
    'someAdminPermissionKey' => 'MyAddonId',
    ...
]

// ... and our log entries have an addon_id column and index
   
// then we do something like:
$finder = \XF::finder(MyLogEntity::class);

$addons = [];
foreach ($adminPermissions as $permissionKey => $addonId)
{
    if (\XF::visitor()->hasAdminPermission($permissionKey))
    {
        $addons[] = $addonId;
    }
}

$finder->where('addon_id', $addons);
finder->fetch();

... or something like that to filter results based on which addons the user has permission to see logs for.

 

[QuackieMackie]

You're already creating a dependency between the addons - so just create the permissions (normally) at the addon level rather than the library level.

Then create a code event in your library that addons can hook into (via a code event listener) to register the relevant permission key from the addon itself.

Then in your library you can filter results based on registered addons permissions for the current user.

No need to programmatically create permissions - they are defined in the addon that is creating the logs - and then you're just using query filters to determine what logs the user can see.

Something like:

// this array is built by the addons via the code event listener
$adminPermissions = [
    'someAdminPermissionKey' => 'MyAddonId',
    ...
]

// ... and our log entries have an addon_id column and index
    
// then we do something like:
$finder = \XF::finder(MyEntity::class);

$addons = [];
foreach ($adminPermissions as $permissionKey => $addonId)
{
    if (\XF::visitor()->hasAdminPermission($permissionKey))
    {
        $addons[] = $addonId;
    }
}

$finder->where('addon_id', $addons);
finder->fetch();

... or something like that to filter results based on which addons the user has permission to see.

Thats a better solution, okay thank you, i'll look into this way of doing it instead.
So add-ons would need to create their own permission and pass that to the library, then the library would use that.

 

[Sim]

So add-ons would need to create their own permission and pass that to the library, then the library would use that.

Yes.

You might also want a general permission for your library to allow you to hide the log UI completely from admins who can't see any logs - you'd set that in the admin navigation entry for your log UI.

 

[QuackieMackie]

Yes.

You might also want a general permission for your library to allow you to hide the log UI completely from admins who can't see any logs - you'd set that in the admin navigation entry for your log UI.

Oh! I thought I had added that already! Thank you for pointing that out