http://www.invisionpower.com/ Can't test whether aMember's IPB plugin works with it yet---I need a good weekend of skinning and permission setting (above basic subscriptions) first
Alex, while you may find some things in there to update, it appears as though the plugin functions as advertised with 1.2 I ran some tests and found zero issues....at least from an end-user's point of view
UPDATE.... Upon further review, aMember will properly update a member's usergroup in IPB 1.2; however, if the member has overriding permission masks applied, the current IPB plugin will NOT remove those. Basically, a member can "expire", yet still have access when permission masks are in use (we use permission masks extensively). Update needed
Burnspot, please explain - what is permissions masks? I have found it, but I'm not sure that it is useful, because you can only set masks from predefined list of groups, isn't it? If yes, why do you use permission masks extensively? And how aMember should work with it? Thank you!
Okay, let me see if I can explain this; it's somewhat difficult because it can get downright confusing when you start thinking about. You've seen how the usergroup/forum access permissions work with IPB 1.1.x and you set up aMember to work for that- a user can belong to one group and that one group's mask, but no more than that. IPB 1.2 goes a step further by adding multiple wearable "Permission Masks" for the usergroups/users. The new system basically revolves around where a single member can wear the permissions of multiple groups. The Old IPB 1.1.x--->A member can only reside in one usergroup, with that group's forum access; however, if you want the member to assume the access rights of several different groups in 1.1.x (all with both similar and dissimilar access rights), it can' be done without a hack/mod. The New IPB 1.2-->A member can still reside in a single usergroup with that usergroup's set forum access, just like 1.1.x. NOW, with the addition of a robust permission masking system, a member can be placed in a single group, but then ALSO, wear additional permission masks, allowing the member to "virtually belong" to more than one usergroup. When a user is given additional masks, it overrides the original usergroup that member was in. An example of this "override" is seen below: <img src='http://www.burnspot.com/images/example1.jpg[/img] This member (above) belongs to a usergroup called "SWG Citizens". On it's own, the SWG Citizens usergroup has access to 2 forums; however, this member's usergroup has been overridden- not only does he belong to his SWG Citizens usergroup (which must be included in the selections that override the group- it's not shown in the image but is just under those other selected masks), but he also belongs to a number of other usergroups, each with its own unique set of permissions. In the image below, note the "Masks", listed on the left, and which "Groups" use those masks. The "Basic SG Membership" mask you see is the default level for a member who's subscribed to my orgnization. Once they subscribe and get assigned to one of our "Portals", they're moved into a more specific group. Often, the member will be assigned to more than one of our Portals, which means they'll be assigned a basic group overridden with permission masks: So where does aMember fit in with IPB 1.2? Well, from what I've seen thusfar, when a member's subscription expires, aMember dutifully removes them from the usergroup they were in and places them into the "non-paid/denied" usergroup as it was designed to do- this is perfectly fine for a user in a single usergroup. HOWEVER, if that member's usergroup is being "overridden" by multiple permission masks, as shown in the first image, aMember will still move the member to the "non-paid" usergroup, but it WILL NOT remove the permission masks the expired member holds. Essentially, the expired member will "appear" to be at the denied level, as reflected by their usergroup change, yet they'll still have full access to protected content by virtue of the overriding permission masks. Basically, aMember not only needs to reset the usergroup, but it also needs to check for overriding permission masks and clear out any an expired member may have. Right now, I have no clear cut way of telling if a member is truly expired except by going through aMember's user listing, page by page, looking for expirations. I hope this explanation helped somewhat Alex.
OK, but if aMember should remove Masks, these masks must be assigned by aMember as well, right? Who currently assigns masks? How should it work? Will it be enough if you will be able to choose several masks for every product in aMember control panel? Or, if you want aMember to only remove masks from expired member, it can be done for you as free customization - I'm not sure that this will be useful for another customers. Thank you for your explanation!
The masks do not need to be assigned by aMember. aMember can function as before by placing member in a "paid" usergroup, then Admins apply the additional masks, if needed. The problem is only that when aMember revokes the subscription of a member in IPB 1.2, it fails to check for "overriding" permission masks and clear them if they exist. It really is similar to the way phpBB works in that members can belong to several usergroups at one time- IPB just plays the game slightly different. In IPB 1.1.x, like what you have for CGI's forum, a usergroup has a defined list of forum permissions (masks) (set by you/Admin). If a member is placed into a usergroup, they inherit the forum permissions of that usergroup. IPB 1.2 functions in exactly the same way in cases of a user being put into a single usergroup. 1.2 goes a step further by allowing an admin to "override" the member's group permissions, adding additional permission masks so that a Member can access more forums, but without actually changing their usergroup. I think that as IPB grows in popularity, you'll find the need for aMember to be able to check and clear these "overriding" permission masks to be a growing demand. aMember functions perfectly, in terms of moving members from "non-paid" to "paid" and back to "non-paid", it just no longer does a complete job of clearing a member's permissions when they expire.
Great explanation of permission masks, Burnspot. I wasn't clear myself how the new permission masks worked, but you cleared it up. I love Invision Board
Alex, just to let you know, the updated IPB plugin works great! No side effects on the members from installation