Trigger to update usergroup is not providing group access during session

I have a trigger which will change a user’s ACL group based upon a database value for that user. Right now I have it working such that the onAfterLogin code reviews the user and determines if they need to change the usergroup.

The code is working fine, but the issue has to do with the active session of that user. For example let’s make it easy and say that we are evaluating whether or not the user should have access to a membership area of the site. When the user logs into the site, if they are properly configured to be site members then the onAfterLogin sets them up with that usergroup. The problem is that during that session if that user were to then try to visit the membership link, they get a 403 error.

If that same user logs out and then back in, they will be able to view the membership link with no trouble. This tells me that the error has to do with the trigger establishing the user with the group permissions after they are already logged into the site. Thus, the session seems to be loaded with information that the user is not a member.

Is there a better trigger location to run the database query on the user with CB Auto Actions that would set up the correct permissions before the user is logged into the site?

I am going to add the trigger to check prior to logging the user out of the site, but what if they choose not to log out of the site and just close the browser? Any suggestions?

Are you using a Usergroup action or some other means to add the usergroup? A Usergroup action refreshes their session with the new usergroups. If you're adding usergroups by any other means then that refresh won't happen and the session won't know they have a new usergroup until they re-login as you're experiencing. Using a different trigger won't resolve that behavior unless you somehow change their usergroups before they login (see before login triggers), but at that point you'll need to do your query using username instead of user id as user id probably won't be present yet.

Previously you are correct that I was manually updating the user’s group through a PHP script within a single CB Auto Action. As you have noted, this causes the delay in the user’s session having to be reset. So, from your description I have now broken this out into the following actions:



Tese actions take place at the following trigger locations:

onAfterLogin,onBeforeLogout

My idea was to pull out the portion of the script where I was manually setting the user in the “expired” usergroup and build the second trigger to follow-up and place the user in the group with the usergroup action.

After testing I have found that this still requires the user to hit the trigger point twice. In other words the user logs in and cb_profiletype is set to expired. Then in theory the second trigger should fire and see that cb_profiletype is set to expired and change their usergroup to expired. Unfortunately the test have revealed that I have to then log the user out before that second trigger is changing the usergroup to expired.

I have attempted switching the order of the two, but both instances are causing the same outcome. Any suggestions on how I can reconfigure this to function all in one login or logout?

Then in theory the second trigger should fire and see that cb_profiletype is set to expired

This is not the case. CB Auto Actions does not reload a user object (a planned feature). It uses the user object sent by the trigger, which if modified in 1 action then again in another action the second action will not see the first actions changes as the changes are not done by reference (CB Auto Actions can assume what variables are references).

See the below Usergroup action code to see how to refresh a users session with the new usergroups.

components/com_comprofiler/plugin/user/plug_cbautoactions/models/usergroup.php

Thanks for the reference. I am a bit confused as to how I can implement this function to get the session update that I am after. Could you please provide a bit more guidance on how this can be done in my case?

Review the "get" function of the usergroup model found at the location shown in my previous reply. You'd need to modify your Code action and have it assign the usergroup again then do the session reloading.