[#7183] CB Auto Actions will not set field value when new user is added via back end

The user store done in activateUser is causing it, but by default settings for a new user set as follows

Confirmed = yes
Approved = yes
Banned = No

The logic works the other way around - The conditions above will trigger "activateUser"
If I create a new user and set Approved to "No" Then the Auto action works as expected. ie i get a membership number

Reversing the order of the 2 events in the code fixes the problem: (libraries/CBLib/CB/Database/Table/UserTable.php - line 1120)

Change this:

To this:

Do not move the activate check. Just use the other trigger as suggested. Your change is currently causing an update trigger to fire before a registration trigger. Example as follows.

Global
Triggers: onAfterUserRegistration, onAfterNewUser, onAfterUpdateUser
Type: Query
User: Automatic
Access: Everybody
Conditions
1: [cb_membership_number] Is Empty

The above also means you can save a user from backend that is missing a membership number to cause it to generate one.

Creating another CB based website for a club where they require a membership number. The same problem still exits in CB/CB Auto actions, but i have found an easier solution. If the new user is created in the back end with Approved = No then there is no problem. A membership number is created and the approved process is not triggered. This also has the desired effect of being able to include a membership number in the approved email body.

The following change is all that is required

In the file : /public_html/administrator/components/com_comprofiler/controller/controller.user.php
Line 102: $user->approved = 1;
change to : $user->approved = 0;

Again, do not change core code. My above suggestion will work perfectly fine for your scenario.

Hi Kyle, sadly I can not get it to work, If i could get it to work then i wouldn't need to change the code. The Auto Action SQL in this website is a little different to the previous website but the principle is the same.

Add a new user via the back end.
As it saves the Auto Action as configured below should run:
Trigger = OnAfterNewUser onAfterUserRegistration
Conditions = [cb_membership_club] equal To IWMAC
Action = An SQL query to set the contents of [cb_membership_number] as the maximum of [cb_membership_number] +1
Parameters/ Relaod User = No

When I create a user via the back end [cb_membership_number] is empty which is wrong. The welcome email includes [cb_membership_number] in the email body so the message sent to the new user is missing information.

If you create the new user and set Approved to No before you save then it works correctly ( I changed to code to make approved = no the default )
If you create the new user and set Approved to Yes before you save then it fails.

This site will be going live this week end - I will put a backup copy of it on another server next week and give you access so you can see the problem i'm experiencing

The goal is - when a new user is created via the front end or the back end we set the contents of [cb_membership_number] as the maximum of [cb_membership_number] +1 and we can also use the contents of [cb_membership_number] in the welcome email that is triggered when a user is flagged as approved.

The below should work.

Global
Triggers: onAfterUserRegistration, onAfterNewUser, onAfterUpdateUser, onAfterUserUpdate, onUserActive
Conditions
1: [cb_membership_number] Equal To IWMAC

The onUserActive trigger fires after the store done in activateUser to prevent the changes from being lost. This should work for frontend and backend registration, profile update, and user activation if the membership number hasn't been set already. This basically is happening because you're using a Query to update the _comprofiler table during a store operation, which doesn't update the $user object. Ideally you'd use a Field action and set the necessary variable as a reference variable, but that's likely not an option in your case.

This also seams like a bug in activateUser as if the user is already confirmed and approved then they're not blocked so there's no point in it setting the block state to 0 when it's already 0 and triggering a store. Have added a bug ticket to fix that.

forge.joomlapolis.com/issues/7183