User Signup form with manual approval

(Joel Porgand) #1

We've got a signup form (an account manager page) on our site, where users sign up so that they can access restricted resources on the site (technical details of products that we don't necessarily want free for the taking). 

 

Users can request access to a specific resource (which is controlled by the user group permission), there are a number of dynamic create locations set up for these groups in the account manager.

 

Since we want manual approval, right now the account manager points at 'pending' groups which the users are dumped into until a staff member here approves them and they are moved into the actual group - I've currently got an admin page with a messy snarl of group mappings that get shuffled around with the JS API. 

 

What'd be perfect is if there was a 'restrictions' screen on user groups like there is on user assets so I wouldn't have to do all this dicking about - I could just stick them in a 'pending' group so none of their permissions would apply until this group membership gets removed. Setting restrictions on a per user basis with a trigger is probably possible however since it's serialised data & I've got a number of different groups to work with it doesn't seem like a sane thing to do. 

 

Anyway, does anyone have any suggestions for simplifying my current setup? Descriptions of your own setups? It feels like this is far harder than it should be to manage, maybe I'm missing something?

(Bart Banda) #2

Hmm, what about if you set the future user group the user is applying access for using a metadata field. Then when the approval happens, you can have a trigger that moves that user into that group. But also depends on what the approval process actually is, but should be possible. That way you wouldn't have to use any JS API functions to do it. 

 

In 5.2 there is a new trigger action that can assign users to groups more dynamically and with more flexibility, which would probably be good for this scenario. However you should just be able to use the Create Link trigger action for yours as well. 

(Joel Porgand) #3

Hmm, what about if you set the future user group the user is applying access for using a metadata field. Then when the approval happens, you can have a trigger that moves that user into that group. But also depends on what the approval process actually is, but should be possible. That way you wouldn't have to use any JS API functions to do it. 

 

In 5.2 there is a new trigger action that can assign users to groups more dynamically and with more flexibility, which would probably be good for this scenario. However you should just be able to use the Create Link trigger action for yours as well. 

 

The main issue is that access to some of the resources has to be requested specifically - so a user could potentially be linked into anywhere up to a dozen different groups - I don't see an easy way to do that with triggers? 

 

I have thought about adding users to a single 'pending' group and then denying read access on all the permission restricted resources to the 'pending' group which should override the read access they are granted by their groups, but then I need to apply that permission across a gajillion assets, and it feels a bit sketchy.

 

Do you have a squizmap link to the 5.2 trigger action?

(Bart Banda) #4

Hey JP, see https://squizmap.squiz.net/matrix/6438for more details on that new feature. It may or may not be useful for your instance.

 

Based on a metadata condition, you could link them into a user group next time they login, based on a metadata value or other value using trigger conditions. 

(Joel Porgand) #5

Hey JP, see https://squizmap.squiz.net/matrix/6438for more details on that new feature. It may or may not be useful for your instance.

 

Based on a metadata condition, you could link them into a user group next time they login, based on a metadata value or other value using trigger conditions. 

 

Cheers, looks like it might work? Not sure it's an ideal solution though.

(Joel Porgand) #6

In the interest of giving this thread a conclusion - I've been mucking around with using 'leave user group for session' trigger action to control this - if a user in a pending group then remove them from XYZ groups. 

 

I've come across something that seems to me to be fairly 'quirky', here's my setup:

 

Permission restricted asset:

- deny read permissions to Public User

- grant read permission to Group A

 

User is linked into groups like so:

 

 Group A

  |

  ---- Group B

          |

          ----- User

 

 Pending Group

  |

  ----- User

 

Trigger:

Event: User login

Condition: Has child/parent with ID: Pending Group AssetID

Action: Leave User group for session

 

Anyway, I initially set up the trigger to leave group B for session as that's where the user was linked to. This however doesn't seem to actually restrict their access. Then I set the action to remove Group A for the session (even though the user is only a member of this group through inheritance) and voila... they no longer have access to the asset when they login. 

 

I think it's a little counter-intuitive (I haven't delved into the inner workings of group/permission handling in matrix), so I thought I'd post my observations.