[SOLVED] Managing family membership via auto-action?

This was a static SQL query I just changed to symbolize the what I was thinking, but thankyou for the heads up.

Well the idea is, the 'master' user is changed to non-member. This triggers a reset of his information, and also triggers the above action, resetting the members field for the other 'slave' members.
But as the member information is more than just a field, and I already have actions for fixing it all, it would be nice if the change in the field, would activate the other actions that triggers on that field change.
The other thing I could do, was to set the FamilyID to 1 (there is no user with id=1), as that is not a valid FamilyID, I could have a 'Users' trigger that just searched the that familyid, and then triggers all the appropriate actions. This will not remove the users as members immediately, but they would be removed next time the Users is run (it's run once a day).

BTW. just to be clear, I'm not using CBSubs (the club can't afford that, so the membership system is coded in autoactions

I just tried with the query, didn't work, darned.
I just entered this in the query box:

UPDATE `xxx_comprofiler` SET `cb_familyid` = '1' WHERE `cb_familyid` = '[user_id]' AND `id` != '[user_id]'

I also tried

UPDATE `#_comprofiler` SET `cb_familyid` = '1' WHERE `cb_familyid` = '[user_id]' AND `id` != '[user_id]'
UPDATE `#_comprofiler` SET `cb_familyid` = '1' WHERE `cb_familyid` = '[user_id]' AND `user_id` != '[user_id]'

I'm again missing something due to lack of experience with this :blush:

Well the idea is, the 'master' user is changed to non-member. This triggers a reset of his information, and also triggers the above action, resetting the members field for the other 'slave' members.
But as the member information is more than just a field, and I already have actions for fixing it all, it would be nice if the change in the field, would activate the other actions that triggers on that field change.
The other thing I could do, was to set the FamilyID to 1 (there is no user with id=1), as that is not a valid FamilyID, I could have a 'Users' trigger that just searched the that familyid, and then triggers all the appropriate actions. This will not remove the users as members immediately, but they would be removed next time the Users is run (it's run once a day).

Ok, so you're wanting the field action to fire after profile update trigger? I don't think I can safely add that at this point as everyone is using it with regards to it not doing that. However, every action fires a trigger of its own when the action is completed. Specifically autoactions_onAction. The variables for it are as follows.

$return, $trigger, $user

So you could have an action act on another action by using that trigger with the below condition.

[var2_id] Equal To PREVIOUS_ACTION_ID

I just entered this in the query box:

UPDATE `xxx_comprofiler` SET `cb_familyid` = '1' WHERE `cb_familyid` = '[user_id]' AND `id` != '[user_id]'

I also tried

UPDATE `#_comprofiler` SET `cb_familyid` = '1' WHERE `cb_familyid` = '[user_id]' AND `id` != '[user_id]'
UPDATE `#_comprofiler` SET `cb_familyid` = '1' WHERE `cb_familyid` = '[user_id]' AND `user_id` != '[user_id]'

Neither are valid queries. The prefix replacement is #__ (double underscore). The below will execute, but i'm not sure it makes sense.


You're conditioning off cb_familyid being the user id, but you're setting it to 1. Is that the reset usage to break the family subscription connection?

What I've done is that the familyid is set to the masterusers id.
So when the master user is resigned, I need to search the other users for the masterusers id in the familyid.
Setting it to 1 will 'tag' the familyid to something invalid, and then I can make a users action that runs through all the users looking at the familyid '1', and then resign them.
So in worst case the family members will be resigned 23 hours and 59 seconds after the master user, I think that is ok.
As I understand it, the autoactions are run in sequence, so if I place that 'invalid familyid' search action at the top, it should reach the user before any of the other 'users' actions, right?
Ahh, double underscore, hadn't noticed that, thankyou, I'll try it out!

Hmm, I can't figure out what is going wrong.
I have an 'action' auto-action that activates all the sub-actions to resign the member properly.
If I disable all the actions, except the query action, it works as it should.
If I enable all the other actions, it doesn't work. I don't have 'reload user' set on any of the actions.

If you've multiple actions altering the _users or _comprofiler tables (field actions or query actions, etc..) you probably need to set them to reload users otherwise the next action may never know of the previous actions changes and either overriding them or their conditions failing.