Permissions reset on upgrade or configuration change

added git:civicrm-joomla sig:bug triaged labels

@monish.deb I know you have been doing some work on Joomla - any insight here? @nicol ?

@webmaster_cses_org_uk - not sure what user group you are trying to reset it to – but on two instances I've just checked, this permissions is 'Inherited(allowed)' for Joomla Admins and Super admins and this hasn't been reset with any upgrade/extension enable/etc.

(NB - I did used to have some upgrade permissions issues, ie of them being removed/restricted on an upgrade, but it was several years ago I last noticed it).

@webmaster_cses_org_uk contributors and CRM users has as it's parent 'public' so my understanding is it will use that as it's base permissions set. If you want to give a user group admin-level permissions, ie accesing CiviCRM, it needs as its parent a user with that level of permissions (ie 'super user' / 'administrator'). Then take away the permissions not needed.

@webmaster_cses_org_uk I have experienced this several times (and honestly feel like I added a ticket about it but can't find it) but like you have not been able to determine a pattern. So far, I've only experienced this on Joomla 3 series and not on Joomla 4. It seems that some upgrades work as expected whereas others do not. Because extensions are often updated at the same time as core, it seems possible that an extension is causing the issue. Again, I'm not sure because I've not tested it thoroughly, but I have definitely experienced it.

The super user group seems to always have access no matter what, but I believe that's baked into Joomla's permissioning. If you look at the global configure for users you can see "is super admin" and I think that basically overrides all individual permissions and forces super admins to have access to everything.

@nicol my understanding is different than yours re: the "public" group. If I'm understanding you correctly, you're saying that the "Public" group should have "See CiviCRM is installed" and that subgroups should "Inherit" or "Disallow". I think that set up is wrong and isn't how permissions are intended in Joomla. In this instance, it would not seem adviseable to have "See CiviCRM is installed" as enabled for the "Public" group, which is essentially anonymous access. Obviously in some instances, what you are saying works perfectly well, but for more sensitive permissions I would think what @webmaster_cses_org_uk has done is the right way to go.

@josh you're saying that the "Public" group should have "See CiviCRM is installed".. no I'm saying that the parent group for 'contributors' should be a Joomla user group that defaults to having 'See CiviCRM is installed' turned on, ie administrator or super user - definitely not public. Any custom user group without such a parent would presumably reset on upgrade as Civi core doesn't know the permissions for a custom user access group, but does know/set the default permissions for public, admin and super users. Custom user groups will inherit their permissions from the parent 'public' if they aren't given another default joomla group like 'administrators' or 'editors' or whatever as their parent.

NB - are you managing to run Civi on J4 setups despite the outstanding issues? When I checked a few weeks ago it felt like lots was still broken.

Aaaah, ok, I see. Yes, that would indeed make sense re: using administrator or super user as the parent group. I've not tried that. Following your logic though, i.e. "Civi core doesn't know the permissions for a custom user access group, but does know/set the default permissions for public, admin and super users", wouldn't the child group, a custom group, experience issues where permissions were overriden at the child group level? I mean, if you set other permissions to "Allow" or "Deny", then wouldn't those revert to the parent group's settings? Again, I've never tried this approach so I am just curious about what you've experienced here.

Re: J4, the only big issue I've seen is this: joomla#41 (closed)

(sorry @josh - didn't get a notification of this comment so just saw now)…

wouldn't the child group, a custom group, experience issues where permissions were overriden at the child group level?

This is a guess - but maybe upgrades are more faithful to permissions that have been turned off, than when they are turned on? ie it recognises inherited permissions that tighten security, but not those that loosen it? So adding 'administer CiviCRM' to a child of a public group would get lost in an upgrade because the parent group doesn't have it, but removing 'administer CiviCRM' from a child of an admin group would survive because it's just removing a permission. But that's a guess - maybe it just needs a parent group other than 'public' to inherit from or something else.

Re: J4, the only big issue I've seen is this: joomla#41 (closed)

That's really good to hear - I still get an error when I try and access Joomla User Permissions for Civi (joomla#35 (closed)), or uninstall (joomla#16). But that's locally on MAMP - maybe PHP related. Which PHP version are you using?

ok, i see. thanks for the insight. re: joomla#35 (closed) i applied the fix that monish provided and that solved it. I've not attempted an uninstall. Why on earth would anyone ever want to uninstall CiviCRM?

@josh I know you were joking but see #3710 (closed) - the only way to guarantee 'as-designed' behaviour after an upgrade is to fully uninstall and re-install CiviCRM, on Joomla at least.

Whilst we won't necessarily start doing this at every upgrade, it looks like it's a necessary periodic maintenance action, i.e. every few upgrades.

@nicol Thank you for your thoughts and insight - most useful. I can try rearranging the Joomla groups (and possibly should anyway) BUT before I embark on that...

You'll see that all the groups are underneath Public, including Super Users? This is how Joomla is configured by default, I believe, i.e. the 'base' group is Public and everything else acquires more permissions from there. So it's not possible to move the Contributors group (and its children) 'outside' of Public. I have tried and it is equally not possible to create a new group outside of Public (i.e. with no parent).

If I try to move Contributors under Super Users, it will automatically acquire all permissions and these cannot be blocked (see second screenshot), so this won't work, unfortunately (as well as being a dangerous move!).

You also mention the Administrators group - the built-in one that ships with Joomla - which as you can see we no longer have anyway (it, and several of the others, would have been deleted a long time ago as surplus to requirement). But I'm not aware that there is anything 'magic' about these built-in groups: the Contributors group has the Administrator Login permission, configured through Global Configuration, and the Super Users group has the Super User permission, configured likewise.

So in summary, yes I'm up for trying a re-arrangement of the Joomla user groups to see if this fixes things, but I can't see how I could change it! Whatever we do, Public will be the root parent of the CRM group(s), and they are already under an intermediate group that (to the best of my knowledge) performs the function of one of the built-in Joomla administrator groups.

I think an important point here is that not all the CiviCRM permissions are affected by unexpected reset. Apart from See CiviCRM is installed (and possibly some of the CiviGrant ones), everything else is preserved. This is true for both the parent CRM Users group and its children.

I suppose I could try assigning that permission individually to all the child groups as well? When I next pick this up in a few weeks I'll give it a go.

Any further thoughts and suggestions welcome!

Just a quick update: I can confirm that the symptom now applies to the CiviGrant permissions also. They have disappeared and I can no longer access the grants except as a Super User.

The most recent 'disappearance' has not coincided with any extension installations / upgrades etc. It just happened one day recently, which suggests something to do with a cache resetting?

I will do some further investigation as time permits...

My hypothesis - that it's permissions in the parent group that CiviCRM resets to (so a Public grandparent is ok, if the direct parent is administrator level) - is really just a guess, trying to throw some logic at a quirky behavior.

I think an important point here is that not all the CiviCRM permissions are affected by unexpected reset. Apart from See CiviCRM is installed (and possibly some of the CiviGrant ones), everything else is preserved. This is true for both the parent CRM Users group and its children.

That's more curious tho. Maybe it is just a Civi/Joomla bug ultimately, triggered by something unique about your setup - which may be the user group, or something else! I guess the best way to exclude this hypothesis would be to create a sub group under admin or superadmin that matches the permissions of your custom group and see what happens the next time an upgrade breaks your custom group - does it break the admin-parented group in the same way.

@nicol You could be on the right lines about being a Joomla thing...

Setting the 'parent' and 'grandparent' groups to the right permissions seems to have stabilised the CiviGrant permissions, although we'll see whether they survive the next update!

The one that does keep resetting (seems to be every time CiviCRM refreshes the cache) is See CiviCRM is installed. I did find that this seems to be defined (here) outside of the main CiviCRM permissions, presumably due to being Joomla-specific. Perhaps this is why it keeps resetting?

A question to everyone: the documentation and code make extensive reference to a permission called access CiviCRM, but I don't see that anywhere on our installation? Is this only a Drupal permission? Is See CiviCRM is installed the Joomla equivalent? Some explanation / clarity would be helpful as I am most confused!!!!

Will continue to investigate in the background...

Hi,

Thank you for raising an issue to help improve CiviCRM. As you may know, this issue has not had any activity for quite some time, so we have closed it.

We would like you to help us to determine if this issue should be re-opened:

If this issue was reporting a bug, can you attempt to reproduce it on a latest version of CiviCRM?
If this issue was proposing a new feature, can you verify if the feature proposal is still relevant? Did it get the concept-approved label? Have other people also shown interest? Could it be implemented as an extension?

If the answer to either question is yes, please feel free to comment or re-open the issue. Please also consider:

Is it something that you could help implement, either by sending a patch or hiring someone who can?
Would you be willing to fund the work, either through a CiviCRM partner, or the Core Team?

Thank you for your help and contributions to CiviCRM.

P.S. This is an automated message, see infra/gitlab issue 20. We understand that automatic responses are annoying, but given the number of open issues as the project evolves, we need a bit of help to triage and prioritise the most relevant issues.

closed

reopened

Reopening this issue as it's still there and still annoying! As of CiviCRM 5.78.3.

Now that CiviGrant is a separate module, all of its permissions are reliably deleted / reset every time we upgrade CiviCRM.

"See CiviCRM is installed" gets reset every few days by itself without any apparent user intervention.

I'd be grateful if anyone has any insights on my "access CiviCRM" question above (i.e. this permission doesn't seem to exist?).

@webmaster_cses_org_uk this sounds somewhat serious. @JoeMurray / @ayduns - have you seen anything similar in Joomla? I wonder if this is actually a CiviGrant issue?

Confirming that this is still present as of Joomla 4.4.10 and CiviCRM 5.78.3. Just to keep this issue alive.

The main annoyance is that See CiviCRM is installed keeps getting reset every few days, seemingly of its own volition, and so I have to go in and re-enable it so that non-super-users can see CiviCRM in the Joomla admin menu.

Hi,

Thank you for raising an issue to help improve CiviCRM. As you may know, this issue has not had any activity for the past 30 days.

We would like you to help us to move this issue forward:

If this issue was reporting a bug, can you attempt to reproduce it on a latest version of CiviCRM?
If this issue was proposing a new feature, can you verify if the feature proposal is still relevant? Did it get the concept-approved label? Have other people also shown interest? Could it be implemented as an extension?

If the answer to either question is yes, please feel free to comment. Please also consider:

Is it something that you could help implement, either by sending a patch or hiring someone who can?
Would you be willing to fund the work, either through a CiviCRM partner, or the Core Team?

Thank you for your help and contributions to CiviCRM.

P.S. This is an automated message, see infra/gitlab issue 47. We understand that automatic responses are annoying, but given the number of open issues as the project evolves, we need a bit of help to triage and prioritise the most relevant issues.

added stale label

Permissions reset on upgrade or configuration change

Child items ...

Activity