Hello, I am having a bit of trouble understanding this I don't really get what this does? Is it possible to make several groups available with aMember? And is how I have it set up here correct? I want all users to have the primary group "Registered", so do I need to put that at the top to make it primary? The order they are in at the moment is how they are ordered within Xenforo. But I really don't get what this does in aMember because I thought it was only possible to assign 1 user group when someone signs up? Below is my product integration set up... ...is this right? The user group drop down menu here only allows 1 group to be assigned, so the "Groups Priority" options above don't make sense to me Can someone help me understand this please? Thank you Regards, Richard
Hello Richard. You can add as many integration records as you want. So you can add record for each group and assign product to it. aMember will check groups that customer has access to (based on his active subscription) and assign this groups to user in xenforo. Primary groups will be the group with maximum priority from available ones. Priority defined according your settings in plugin configuration. You can drag and drop groups to change priority. Please consider the following example: You have two integration records: - Gold Member (allow access for active users of Product A) - Silver Member (allow access for active users of Product B) Then you have customer with access only to product B: aMember choose only group Silver Member for him and assign it as primary (only one group available) Another case you have customer with active subscriptions to both products A and B aMember choose two group for him Gold Member and Silver Member . From these available 2 groups aMember choose group with maximum priority (according plugin configuration, your first pic.). Gold Member is higher on your pic. So aMember set it as primary and all other available groups set as secondary. In this example Silver Member will be set as secondary. I hope it make some sense.
Hi Caesar, Thank you for your reply Yes, it makes more sense to me now. I just want to be clear though and make sure I have it right, because the thing is, XenForo are quite anal about ALL members beings assigned to "Registered" as primary. So, if I set up Guest access via another record and assign that group to "Unregistered/Unconfirmed" with lifetime access, but very limited permissions and then all other subscriptions get assigned to "Registered" and last for x amount of months, as long as I have "Registered" above "Unregistered/Unconfirmed", "Registered" will be assigned as primary? Then when the sub expires, the user will be removed from "Registered" as primary and reset to "Unregistered/Unconfirmed" as primary? The only thing with this is, if someone decides to purchase x amount of months subscription without signing up as a guest first, when their paid subscription expires, they won't have guest access, even if I set the "default level" to return to "Unregistered/Unconfirmed" because this will just be a group inside XenForo that they will be assigned to, which doesn't mean they will have access via aMember in the first place. I know I'm probably repeating or over explaining, but I'm just trying to get things straight in my head to make sure I'm getting it right lol So, let's say, Joe Bloggs "A" comes to my site, signs up as a guest, gets assigned to "Unconfirmed", has lifetime access, but very limited permissions. He then pays for 1 month sub, gets assigned to "Registered", still has lifetime access plus more permissions until his 1 month sub expires and he is returned to "Unconfirmed", still has lifetime access but is back to limited permissions. Then, Joe Bloggs "B" comes to my site, he doesn't sign up as a guest, so doesn't get lifetime access, instead he pays for 1 month membership and gets assigned to "Registered", so he has 1 month access with more permissions, until his sub expires and then he removed from "Registered", added to "Unconfirmed" via the "default level reset", but he doesn't have the lifetime guest access, so he can't sign in to see anything, until he either, A) Pays for a sub again or B) Signs up as a guest. What I would like is for all members to be returned to guest whether or not they sign up as a guest first. Or.....(I'm just thinking out loud here)....will I have to "force" people to sign up as a guest first by not allowing them view the subscriptions until they have guest access? Sorry to be a pain, and I know I'm probably being dumb and making things more confusing than they actually are, I just want to make sure I get it set up correctly because the user groups I have set up in XenForo are not paid permissions, they are groups that the user gains access to when they meet certain criteria, x amount of messages, etc. Thank you for your help Regards, Richard
Yes this is right. Right. yes sure, that is possible solution. Another one is to use default-product plugin. That plugin will add default product to user's account if user doesn't have any other active products. You can request that plugin through helpdesk
I noticed something with the group priority order, which I think may cause problems for other people to. The problem being, if the order of these are changed AFTER the user already has a couple of products, then the priority does not apply and it is set in the order which it was when they were first added to the groups. Not sure if this is a bug or something that has been overlooked, but as I was testing some settings, I noticed this with all my test accounts that had one group as primary when products were added, then when the order was changed in the ACP, it was not reflected in their accounts. When I removed their products and re-added them immediately after, only then were the changes reflected. Anyway, just thought you should know.
This is expected. When you change order or groups this affects new updates only. aMember doesn't change this for all previous users. So for example, if you change order, and user will make purchase after this, user's groups will be updated using new order. But if user doesn't make any purchase, he will not be updated. You can use aMember CP -> Rebuild DB in order to fix all accounts. So change priority order then run Rebuild DB, all accounts will be updated using new order.
I did run the Core rebuild, which didn't do anything. I'm a bit weary about doing a Xenforo db rebuild inside aMember because last time I done this, it removed my admin and mods and I had to go directly into the database to add the permissions again, then I had to remove the permissions from them inside xenforo and re-make them admin and mods again to them to function correctly.
You have to run Xenforo rebuild. In order to keep admin and moderator permissions make sure that you have these groups set as Admin groups in amember CP -> Setup -> Xenforo.
Hi Alexander, I tried that before, but when admin or mod signs in, they don't get the "visitor tabs" - username, inbox, alerts, etc. And although they have "logged in" and it shows that they are "online" in the ACP, they're not actually logged in and don't have any of their usual permissions. It's like a ghost account and they can't even log out. After removing them from "Admin Groups", I've tried "logging in as user", so that I could log them out, the visitor tabs come back and normal function returns, but it just creates a whole new session and the other ghost account remains logged in, so the only way to log them out is to go into the database, clear the sessions and clear the amember/data/new-rewrite folder.
I've noticed another problem since setting up multiple records for integrations. If a member is added to more than 1 group, the Groups Priority list works fine and "registered" is set as "Primary", but inside XenForo, to have title display priority, the user groups have a number, the higher the number, the higher the priority, so if the "Registered" style display number is "0" and "Admin" is "1000", then the "Admin" title style will be used and displayed, regardless of whether it is the"Primary" or "Secondary" group. This is not the case here though, it never used to be an issue inside XenForo until I created multiple integrations inside aMember. When a user signs up for "Platinum", they are added to both groups via the integrations, and they are added without any problem. In the "Group Priority" list, I have "Registered" above "Platintum" so that "Registered" is Primary and "Platinum" is Secondary, this works fine. "Registered" has a style display order of "0" and "Platinum" has a display order of "1000", so it should be the "Platinum" title that displays, but it's not, the "Registered" title is displayed instead. I've played around in XenForo, trying different things to get them to display correctly and I have to do a "User cache rebuild", but this only lasts for about 24hrs-ish, then they are back to be displayed in the wrong order. The only thing to correct them is a "User cache rebuild" inside XenForo. Like I say, this was never an issue until I set up the multiple integration records. Members are still in both groups and still have "Platinum" permissions, it's just the titles that are effected. After trying everything in XenForo and doing a user cache rebuild to get them to display correctly, I left it for a while and then done a "Xenforo DB Rebuild" inside aMember and immediately after, the titles were back to being displayed wrong again, so everything seems to point to an aMember issue and I think it may be something to do with the "Group Priority" list, as that sets the "Primary" group, it seems to force the wrong title to display as well. If I go straight back into XenForo and do a "User cache rebuild", the titles are displayed correctly until, either A) I do a Xenforo DB rebuild in aMember or B) I leave it for a day or so and things get displayed wrong themselves. I assume it happens periodically like than due to a cron task that aMember does to clear out expired subscriptions or something. Anyway, is this something that could be looked at please to see where the issue lies exactly? Thank You for you help I appreciate it
This is expected result because aMember set display group id to the same value as primary group id. Why don't you move Platinum group to the top? This way it will be set as primary and displayed group id will be correct.
Hi Alexander, I have "Registered" as primary for all users, even Admin and Mods, because permissions are cumulative, so "Registered" has all the main permissions set for every member and then all secondary groups have only their individual set permissions. This way, every member can be controlled by one change in the "Registered" group, instead having to go through each group and repeating the same change. Also, it makes it easier to see what the differences are between each secondary group because they are the only permissions that are set. Also, another problem would be that I have other user group promotions inside XenForo that are not available for purchase, they are just groups that members will be added to via different criteria and to apply these promotions, xenforo has a cron task that updates user info, so all it will do is update them, then aMember will be basically doing, is just resetting them. And another issue would be that, admins/mods/ and some other user's have the permission to have a custom title and because each group has a set default title already, even if I worked backwards with each different group being set as primary, any custom titles would also just be reset to the primary value. I've noticed this when testing it with my with admin account that has a custom title. Is there a way to change/edit the code so that aMember doesn't change the title display order and just adds the group as primary? Having aMember set the title display order is not something that is needed considering it's something that is easily handled inside XenForo anyway. Thank you
Yes sure this is possible to modify plugin so it will work that way. Contact us in helpdesk we will help with this modification.
OK, thanks. What about the "Admin Groups" issue? At the moment, I'm having to add the admin and mod groups, perform the rebuild and then remove them again.