XF 1.4 User Promotions not running on registration

Siropu

Well-known member
I have set a user promotion where users with less than 50 posts and state "valid" are added to a custom group. From what I understand, the promotion should run on user registration but in my case it doesn't. Can someone please tell me where's the problem?

Thank you.
 
Why are you running a promotion for < 50 messages?

Why not set the Registered user group as you want and run the promotion on >= 50 messages?
 
I switched from phpBB and on phpBB you could set a default group for newly registered users and since this option doesn't exist on XF, I need a workaround. So a user with less than 50 posts should be "promoted" to the "newly registered group". I don't want to make the default group to be that group as I already set the permissions.

Why new users don't get promoted in the group I set on registration? I see $this->_executePromotionUpdate(true); on the _completeRegistration() method. Isn't this supposed to do that?
 
I've set some restrictions to newly registered users group so that's why a user must be promoted to this group when registering. The issue here is that the user doesn't get promoted to that group upon registering like it should.

Trophy and promotion cron speed improvements
Trophy and promotions are now automatically applied on session creation. While the cron still runs, it only runs for users that have been active very recently.

According to @Mike's post, this should work. Why isn't working for me?
 
The code is explicitly there and I think people have used that before. That said, the promotion system isn't really designed to instantaneously change a user; there can be a window where they meet the criteria and aren't promoted and this is expected.

I would definitely recommend changing your structure to fit how XF's groups/permissions work; it feels like you're trying to fight against it.
 
I've set some restrictions to newly registered users group so that's why a user must be promoted to this group when registering. The issue here is that the user doesn't get promoted to that group upon registering like it should.
This is why you need to read the guide I linked to.

"Restrictions" are basically setting Not Set (No) for any permissions that you don't want new users to have. You shouldn't use Never as it can't be overridden (there are a few circumstances where it should be used but mostly it should be avoided).

So you set up the Registered group with the minimum permissions that you want newly registered users to have. You then set up a secondary user group with the additional permissions you require (and only these, no need to replicate permissions from the Registered group) and use a user group promotion to promote users to the secondary user group.
 
The code is explicitly there and I think people have used that before. That said, the promotion system isn't really designed to instantaneously change a user; there can be a window where they meet the criteria and aren't promoted and this is expected..

I would definitely recommend changing your structure to fit how XF's groups/permissions work; it feels like you're trying to fight against it.
This is really confusing to me since here it says "Trophy and promotions are now automatically applied on session creation".

So according to this, a promotion is automatically applied right after the user registers if the criteria is met, right?
Since I'm expecting XF to do this, how am I fighting against it?
 
There is code to do it. I specifically remember adding it actually:
Code:
protected function _completeRegistration(array $user, array $extraParams = array())
{
XenForo_Model_Ip::log($user['user_id'], 'user', $user['user_id'], 'register');

$visitor = XenForo_Visitor::setup($user['user_id']);
XenForo_Application::getSession()->userLogin($user['user_id'], $visitor['password_date']);

$this->_executePromotionUpdate(true);
$this->_executeTrophyUpdate(true);
// ...
I have not heard any issues about this not working previously.

But my point was that you can't rely on the promotion only being applied at exactly the right moment; it is possible for it to be added or removed slightly later than you might expect due to it only being checked in certain cases. For that reason, promotions are generally designed to add permissions, not remove them; regardless, the requirements need to be designed to "tolerate" a promotion being slightly "laggy". Since your promotion is removing permissions and requires instantaneous application, it seems like it's fighting against the system (vs making the registered group have the base permissions and then promoting to give a "trusted" group).
 
The code exists but it doesn't work. In my case at least... It's failing somewhere in _executePromotionUpdate()

I know I'm using promotions the wrong way with this group but I've set many forum based restrictions for this group and switching the groups wouldn't be a good idea.

One unrelated question to my issue.
How does a user know that was warned and what for?
 
I just setup a promotion to promote with the condition "User has posted no more than X messages" (value was 1) and it promoted immediately on registration without issue. I would check your promotion criteria and confirm with all add-ons disabled.

As for warnings, if you want to notify the user, the option to start a conversation should be used.
 
Top Bottom