Uninstalling an add-on breaks other add-ons which implement a permissions using interface groups from the first add-on

[Xon]

Affected version

XF2.2.13

If you have add-on A, which has defined a permission interface group B, and then Add-on C which implements a permission in that interface group; uninstalling add-on A will break any add-on C.

Running php cmd.php xf-addon:build for add-on C will generate a broken install which will throw this error:

Please enter a value for the required field "interface_group_id"

when attempting to install/upgrade add-on B on anotherXF instance.

The problem is XF\Entity\PermissionInterfaceGroup::_postDelete():

protected function _postDelete()
{
...
    if (!$this->getOption('delete_empty_only'))
    {
        $this->db()->update(
            'xf_permission',
            ['interface_group_id' => ''],
            'interface_group_id = ?',
            $this->interface_group_id
        );
    }
}

This will damage all add-ons which implement a permission on the interface group.

 

[Xon]

This also applies to a production environment. Uninstalling add-on A, then re-installing add-on A will leave add-on C's permissions which are for add-on's permission group no longer visible.

 

[Sim]

To be fair - by having addon C implement addon A's permissions - you've created a dependency between addon C and addon A. Uninstalling addon A before uninstalling addon C would reasonably be expected to break things for addon C.

It's a pain that re-installing addon A does not fix the issue due to the missing permissions - but how would you expect XF to handle this situation? It is reasonable to expect that if you uninstall addon A, then the permissions it defines should be cleaned up - otherwise you'll get orphaned permissions left.

I don't know whether there could be a nice way for XF to handle this dependency situation elegantly? How would it know when it is safe/unsafe to delete those permissions?

Is it reasonable to expect XF to cater for uninstalling a 3rd party pre-requisite addon before a dependent addon?

Just thinking out loud here.

Do you have a suggested solution @Xon ?

 

[Xon]

There isn't actually any need to zero out xf_permission.interface_group_id (ie put it into an invalid state). XF will just not display these permissions in the standard permissions ui in the admincp, but they are shown in the development permission definition list.

This is the behavior of content type fields where it is only the things linked to the add-on which are removed, and not every content type field.

It is actually safe to leave permission definitions untouched, as without the parent content type they just don't get loaded.

 

[digitalpoint]

Kind of indirectly related... I've always wondered if XenForo prevents uninstallation/deletion/disabling an addon when there's an addon enabled that has an installation "requires" dependency on the one being disabled.

I never went so far as to test it out, so just wondering if anyone knows?

If it doesn't, maybe that's the solution here? I can't think of a reason you would want force addon A to be installed in order to install addon B, but not uninstall addon B before addon A was uninstalled...

 

[Sim]

Kind of indirectly related... I've always wondered if XenForo prevents uninstallation/deletion/disabling an addon when there's an addon enabled that has an installation "requires" dependency on the one being disabled.

I never went so far as to test it out, so just wondering if anyone knows?

I'm not 100% sure and haven't checked, but from my recollection, it's only checked at installation time, preventing installation if the prereq addon is not installed.

 

[Xon]

Kind of indirectly related... I've always wondered if XenForo prevents uninstallation/deletion/disabling an addon when there's an addon enabled that has an installation "requires" dependency on the one being disabled.

It doesn't, this includes disabling an add-on. addon.json's requirements section is very limited.

My SV/StandardLib add-on hacks in a soft-dependencies section which my various add-ons often use but it isn't a stock solution.

If it doesn't, maybe that's the solution here? I can't think of a reason you would want force addon A to be installed in order to install addon B, but not uninstall addon B before addon A was uninstalled...

In my case, this was a soft-dependency. Ie addon B extends addon A and implements an additional permission. If addon A doesn't exist it doesn't matter.

 

[digitalpoint]

It doesn't, this includes disabling an add-on. addon.json's requirements section is very limited.

My SV/StandardLib add-on hacks in a soft-dependencies section which my various add-ons often use but it isn't a stock solution.


In my case, this was a soft-dependency. Ie addon B extends addon A and implements an additional permission. If addon A doesn't exist it doesn't matter.

Ya, I get that in this case the first addon isn’t needed, but even if it’s not technically needed after the fact, it does put it in a bit of a grey area if it’s using the other addon’s permission group.

I was more just thinking about some cases where addon B requires addon A to install, but would also catastrophically fail if addon A was later uninstalled. I have a couple of those myself I use internally... was mostly just thinking aloud.

 

[Ivancas]

There isn't actually any need to zero out xf_permission.interface_group_id (ie put it into an invalid state). XF will just not display these permissions in the standard permissions ui in the admincp, but they are shown in the development permission definition list.

This is the behavior of content type fields where it is only the things linked to the add-on which are removed, and not every content type field.

It is actually safe to leave permission definitions untouched, as without the parent content type they just don't get loaded.

This is how your post is read in dark mode

 

[Xon]

That is the result of a copy&paste bug with the XF2.3 editor that is still unfixed. They adjusted the edit time limit on posts so I can't correct that.

That has nothing todo with this bug report.