XF 2.1 Usergroup change via Job/Queue Laravel?

[improbable_airtime]

I'm in the process of building an app with Laravel that works in-hand with XenForo.

The issue is that in my use-case, I have a webhook that communicates with my server and I create a Job and run it with a worker. When that webhook is processed, I want it to give the context user a certain usergroup on the forum. However, it would appear to just not work whenever the webhook since whenever the job gets processed, it does everything (fair amount of other code), EXCEPT adding the usergroup. This is incredibly frustrating since there are no errors, no logs, and from my own personal debugging, there are no silly mistakes such as undefined variables etc...

So I've got no idea what the issue is and what makes it even more frustrating is that if I make something like some buttons for adding/removing usergroups in my application, those work FLAWLESSLY using exactly the same functions. But as soon as it's inside a Job, it breaks.

So my current theory is that somehow, the job is ending before addUserGroupChange and any other methods it depends on in XF finish.

My current code is as follows;

$service = Xenforo::getApp()->service('XF:User\UserGroupChange');
$service->addUserGroupChange($this->forum_id, $key,
    $groups->toArray());

Hopefully someone can help me out.

 

[021]

.why not just use the API?

 

[improbable_airtime]

.why not just use the API?

Because there are other parts of the forum I need to access in my application that AREN'T available in the API.
Also at this point since I've already included XF.php etc... into my application, it seems a bit foolish to then rely on sending web requests to the forum to change just usergroups and then do all the rest of my stuff internally.

I'm going to be completely honest, everyone says XF is an amazing forum software and usually I agree, but I cannot believe it's this hard to change a damn forum user group on a user internally. Meanwhile there are much more complex things that happen internally for the forum that I can call 1 method and have it work perfectly fine.

 

[021]

Because there are other parts of the forum I need to access in my application that AREN'T available in the API.

.so develop your methods)

Also at this point since I've already included XF.php etc... into my application, it seems a bit foolish to then rely on sending web requests to the forum to change just usergroups and then do all the rest of my stuff internally.

It's foolish to make a bridge, relying on the fact that applications will run on the same server. You will have problems if you want to transfer the forum to a separate server.
All components must work independently of each other. Use API to develop the bridge and you will not have any problems)

 

[improbable_airtime]

.so develop your methods)


It's foolish to make a bridge, relying on the fact that applications will run on the same server. You will have problems if you want to transfer the forum to a separate server.
All components must work independently of each other. Use API to develop the bridge and you will not have any problems)

For my specific application, the bridge was the best option. The things I can't do with the API are restrictions on XF's end, not mine.

I don't want to sound like a jerk, but if you aren't going to help please refrain from posting on here. Even IF XF fixed the restrictions I mentioned above, I'm not going to recode my entire application to use the API when everything I want it to do already works perfectly, except adding/removing usergroups...

 

[021]

.to help you, publish the entire code for your bridge. How is the receipt of the XF application and the full function using the service arranged?

 

[improbable_airtime]

.to help you, publish the entire code for your bridge. How is the receipt of the XF application and the full function using the service arranged?

I'm using a simplified and updated version of this that I did myself; https://github.com/UnderRatedBrilliance/XenforoBridge

By "updated" I mean for the latest version of Laravel and XF. I didn't add any new features, so it's 99.9% same as that one.

 

[021]

GitHub - UnderRatedBrilliance/XenforoBridge: Simple but Extendable Bridge for Xenforo to use with Laravel 5

Simple but Extendable Bridge for Xenforo to use with Laravel 5 - UnderRatedBrilliance/XenforoBridge

github.com

.this is the bridge for XF 1.x

 

[improbable_airtime]

.this is the bridge for XF 1.x

That is the one I used and updated.

Contracts-UserInterface.php

GitHub Gist: instantly share code, notes, and snippets.

gist.github.com

Really the only file that changed the most was this one. https://gist.github.com/marbuser/c3e4d16609a579bb0808f333b691cd5e#file-xenforo-php

Like I said, for everything else works fine for me just usergroups that's having the issue. Getting visitor, etc... all works fine.

 

[021]

addUserGroupChange

.what does the function return?

$this->forum_id

There should be a user id.

 

[improbable_airtime]

.what does the function return?


There should be a user id.

forum_id is the same thing as XF user_id, just an alias I use in my project.

Also, function just returns 1, even when it doesn't work..

 

[021]

Also, function just returns 1, even when it doesn't work..

.the function returns the true not in all cases. Use the tracer to see where this value returns.

 

[Mike]

Obviously without seeing the code beyond the one line you've shown, it's hard to guess. However, in that line, based on $groups->toArray(), it doesn't look like you're passing user group IDs in (I assume those are full user group entities), which would probably make it behave in very undefined ways. This function takes a list of group IDs. (Admittedly the phpDoc could be clearer about this.)

 

[improbable_airtime]

Obviously without seeing the code beyond the one line you've shown, it's hard to guess. However, in that line, based on $groups->toArray(), it doesn't look like you're passing user group IDs in (I assume those are full user group entities), which would probably make it behave in very undefined ways. This function takes a list of group IDs. (Admittedly the phpDoc could be clearer about this.)

In regards to $groups->toArray(), that's actually just an array of group ids. I just put them inside of a Laravel collection so that I can use their nifty helper functions and then at the end I called toArray() to make sure it was just an array and none of the other collection stuff.

While investigating I noticed these here;

if ($this->isChanged('user_group_id') || $this->isChanged('secondary_group_ids'))
{
   $this->rebuildUserGroupRelations(false);
   $this->rebuildPermissionCombination();
}

Would calling these from my own code be relevant or no?

Also in regards to showing more code, can you be a bit more specific? There is stuff I can't show from my personal source code due to legal documents etc... I don't want to be one of those guys who posts 1 line of code and expects top tier support, but I genuinely have no idea what the error is.

This code below is literally the only code I use inside my application for usergroups.
Add

public function addUsergroups($groups, $key)
{
    $groups = collect($groups);

    $service = Xenforo::getApp()->service('XF:User\UserGroupChange');
    $service->addUserGroupChange($this->forum_id, $key,
        $groups->toArray());
}

Remove

public function removeUsergroup($key)
{
    $service = Xenforo::getApp()->service('XF:User\UserGroupChange');
    $service->removeUserGroupChange($this->forum_id, $key);
}

And the part that is most confusing is, if I hook these up to a button and an input as a test thing, I can add/remove usergroups as much as I want and it works PERFECTLY.

But as soon as my Laravel Queue/Job/Worker tries to do it, it breaks, and there are absolutely no errors or weird logs, or anything. My somewhat absurd but current theory is that the Job/Worker is running too fast and finishing before removeUserGroupChange and addUserGroupChange can finish executing. Because they do leave records in the usergroup change table, just they dont update the xf_user secondary_group_ids column.

 

[Lukas W.]

The addUserGroupChange and removeUserGroupChange take the user_id as first parameter, but your code seems to be passing a forum_id. It probably randomly matches a user id, hence why it creates the logs and promotes a user, just not the one you'd expect it to.

Fwiw, I think integrating directly with XF when you have the chance to should always be chosen over using the API. There's no reason to load your application with the unnecessary REST protocol overhead that tremendously slows it down and security concerns that additional API methods exposed to everyone would add.

 

[improbable_airtime]

The addUserGroupChange and removeUserGroupChange take the user_id as first parameter, but your code seems to be passing a forum_id. It probably randomly matches a user id, hence why it creates the logs and promotes a user, just not the one you'd expect it to.

Fwiw, I think integrating directly with XF when you have the chance to should always be chosen over using the API. There's no reason to load your application with the unnecessary REST protocol overhead that tremendously slows it down and security concerns that additional API methods exposed to everyone would add.

Hey Lukas,

forum_id is just an alias I use in my laravel app for convenience sake since the context makes more sense.
It's really using user_id

 

[improbable_airtime]

Actually just discovered that it seems to be removing usergroups that is then blocking adding usergroups to the user again.

Basically the way I was testing was;

• Catch Webhook
• Add usergroup
• Remove usergroup
• catch webhook
• (doesnt add forumgroup anymore for some duration of time)

So I think it's actually the part where I remove the usergroup that is causing some issues with then future usergroups getting added. As in my previous message, here is the code I'm using to add/remove usergroups.

public function removeUsergroup($key)
{
    $service = Xenforo::getApp()->service('XF:User\UserGroupChange');
    $service->removeUserGroupChange($this->forum_id, $key);
}

public function addUsergroups($groups, $key)
{
    $groups = collect($groups);

    $service = Xenforo::getApp()->service('XF:User\UserGroupChange');
    $service->addUserGroupChange($this->forum_id, $key,
        $groups->toArray());
}

@Mike @Chris D Would either of you happen to have any ideas as to how removeUserGroupChange could be blocking future usergroups being added, especially if they were to use an identical "change key" to eachother? Never thought this might be an issue since I use the id of what the user purchased, and I figured removeUserGroupChange would remove the previous one before addUserGroupChange got called again.