Accessing / using Usergroup membership to control functionality

I’ve got a series of issues which I’m a little stumped on, that relate to having different categories of members on the same site - using Revo2.0.7/8.

1. There are snippets that deal with whether users are logged in or not, and resource groups to hide or display entire resources. However, I want to show different things to different members. I can’t get the ismember/mo/memberof output filter to chain properly (ie if it’s true, then it parses fine, but if it’s false, it throws an error on both the ’then’ and ’else’ output filter - I think this is a bug).

What I was thinking of doing is using a TV to contain ’Premium’ content on a resource, that only displays if the user viewing it is (a) logged in, and (b) a member of a specific usergroup. If they’re not a member, they get an upgrade message, if they’re not logged in, they get a ’register/login’ message. Does that sound sensible?

I just can’t decide whether it makes more sense to hide things entirely (ie using ’normal’ access restrictions) or whether users should be able to see that there is more content, it’s just that they need to pay to see it.

2. I might move this on to it’s own thread, but my client also wants those premium members, and only those members, to be able to access a forum that is running on the site. I’m using Vanilla at present, with ProxyConnect. The problem there, as far as I can make out, is that it will authenticate any Active user, rather than a member of a usergroup. I’ve thought about hiding the login to those not in the group, but that’s easy to get around in a bookmark.

Discuss (Revo’s forum) doesn’t seem ready for production use yet, and I don’t know whether it would cater for that scenario anyway. Ideas, anyone?

Aha! I’d forgotten that the sign-on in Vanilla is in part handled by a MODx snippet populating a cookie that is then read by the ProxyConnect Vanilla plugin. I think I may be able to control what goes in that cookie based on whether they’re a member of a group or not, not just whether they’re logged in. I will experiment and come back to this thread.

I think you could do it with a pretty simple snippet:





I think it would let you skip the login check, since an anonymous user would never belong to the user group.

BTW, I think isMember() takes a comma-separated list of group names and will let you specify if the user can be a member of any or needs to belong to all.

Thanks Bob. There is already a package that does this - called Personalise. Personalize is for logged-in users only, not groups

I think I’ve just been very dense - I was focused on the fact that Personalise uses chunks (which a user can’t usually edit) - whereas of course the chunk simply contains a placeholder pointing to the appropriate TV. I’m soo shtooopit sometimes.

I can’t get the other bit to work properly though. Vanilla ProxyConnect is particularly dumb - when presented with no credentials it simply creates a blank user. I think I’m going to have to create a dummy user that is banned from Vanilla, and use their credentials to populate the Vanilla cookie if the user is not logged into MODx. Not really the desired outcome, but needs (or in this case, edge scenarios, must).

I was focused on the fact that Personalise uses chunks (which a user can’t usually edit) -- whereas of course the chunk simply contains a placeholder pointing to the appropriate TV

I created Revo version of Personalize, but I’m afraid I don’t understand what you’re saying here. The chunks can contain whatever you want it to. Mine usually contain content and/or snippet tags.

Sorry - I simply mean that I’d forgotten that chunks can contain things that are dynamic (including things that a non-admin editor can edit in the manager). I had it fixed in my head that chunks were static blocks of text - I’d forgotten their primary use is as mini-templates (what I’m used to calling component templates from commercial CMS systems).

Your IsMember snippet does exactly what I need it to do, and doesn’t throw errors the way the ismember output filter does.

--
On the Vanilla side I’ve ended up using the Vanilla embed plugin on a page that MODx has restricted to a resource group w/ specific group permissions, so even if you have Vanilla access you can’t get into it unless you are both currently active on MODx and in the right group. You see vanilla come up for a second before redirecting, but it seems to be the only way to get the single-sign on to work reliably, and in the way that I want, without hacking it.

I contemplated allowing an array of group/chunk pairs in the snippet parameter like this:



Would that be of any use to you?

I don’t think so, as it’s probable that either through error or design there are users who are members of more than one group.

I don’t really understand the caching / performance hit of calling snippets multiple times, but I was expecting to use:

[[!IsMember? &groups=`Paid’ &yesChunk=`premiumContent` &noChunk = `blankChunk`]]
[[!IsMember? &groups=`Registered’ &yesChunk=`upgradeContent` &noChunk = `blankChunk`]]
[[!IsMember? &groups=`Anonymous’ &yesChunk=`registerContent` &noChunk = `blankChunk`]]

Although now that I see it written down, the overlap is more likely to be on the Manager side (ie admins who are editors, and also in group ’paid’ and group ’registered’). But again, if I set up roles properly, I guess the superusers don’t need to be in other groups.

You might think about removing users from the registered group when they join the paid group.