MAMS Registration not passing user properties to MAMS

[WDJames]

Hello all,

We are using MAMS and MAMS Registration to create a member's area. We've set up the User Properties on MAMS (users need to enter Name, Job and Organisation as well as the Username). We are allowing users to register via MAMS Registration on Sign Up page. We have set MAMS Registration to not require the user to confirm via email and to automatically create users in the MAMS module.

The issue we are having is that the Extra Info (Name, Job & Organisation) entered by the user aren't being passed into the MAMS module when the user is created.

Does anyone have any ideas on how to get this to work?

Also, when we set the "Automatically create users in the MAMS module" to No, the Extra Info is passed to MAMS when the users are manually sent to MAMS but if the user was edited in MAMS Registration and then sent to MAMS then the Extra Info is lost.

Apologies for the long question and thanks in advance for your help.

Thanks,

James

[Jo Morg]

User properties have to be linked to user groups, which means that the user registration needs to have a user group with those properties set as optional or required in order for the properties to be saved for the automatic registration. From your description it seems the registration tag is not using the group parameter or you may have a typo in it.

[WDJames]

Hi All,

I think I've got something. The Extra Info (Name, Job and Organisation) are being passed to MAMS but is not being displayed either on the MAMS admin panel or when the user is editing their settings from the front end.

I forgot to mention that the Extra Info were all set up as Encrypted Properties. As a test I've added a non encrypted property and tested the MAMS Reg form. The non-encrypted property was displayed but the rest weren't.

It's weird because we know that the Extra Info is being captured by MAMS Registration and stored and is sent to MAMS but is not shown.

Thanks,

James

[Jo Morg]

As per the module documentation:

Encrypted Data:

The Encrypted field functionality is intended to store (in a secure way) personal and private data that even the site administrator should not have access to. i.e: items such as Credit Card information. The only person that should be able to view and edit this data is the user himself. This data should not be exported to plain text either. The data could however be read and used by other modules.

[WDJames]

User properties have to be linked to user groups, which means that the user registration needs to have a user group with those properties set as optional or required in order for the properties to be saved for the automatic registration. From your description it seems the registration tag is not using the group parameter or you may have a typo in it.

Hi Jo,

Thanks for the reply. All the User Properties are set to Required for all the groups. There are 3 groups: Admin, Members & Public. The registration tag is: {MAMSRegistration group=Public}. The idea is that users register for the Public group then a member of staff changes their group to Members after verifying their info. Going to try it with quotation marks and update the post.

Thanks,

James

[Jo Morg]

As per the module documentation:

Encrypted Data:

The Encrypted field functionality is intended to store (in a secure way) personal and private data that even the site administrator should not have access to. i.e: items such as Credit Card information. The only person that should be able to view and edit this data is the user himself. This data should not be exported to plain text either. The data could however be read and used by other modules.

PS: by the way the quotations marks are not needed in that case.

[WDJames]

As per the module documentation:

Encrypted Data:

The Encrypted field functionality is intended to store (in a secure way) personal and private data that even the site administrator should not have access to. i.e: items such as Credit Card information. The only person that should be able to view and edit this data is the user himself. This data should not be exported to plain text either. The data could however be read and used by other modules.

Thanks again for looking into it, Jo. While this is what we have in mind when we set up the Encrypted fields, there is still a problem because:

1. When the user is manually processed from MAMS Registration to MAMS, the info is visible to the site administrator when editing the user's info on MAMS.
2. The user is not able to see their info when they change their settings from the front end.
3. If the user adds/edits their info on the "Change My Settings" form, then the info becomes visible for the site administrator. It is still encrypted on the database but is readable when editing the user in MAMS.

I hope I've explained this well enough and thank you again for your help.

Thanks,

James

[Jo Morg]

1. When the user is manually processed from MAMS Registration, the info is visible to the site administrator when editing the user's info on MAMS. As far as I'm aware, this was always the case even when previously using FEU.
2. The user is not able to see their info when they change their settings from the front end.
3. If the user adds/edits their info on the "Change My Settings" form, then the info becomes visible for the site administrator. It is still encrypted on the database but is readable when editing the user in MAMS.

I hope I've explained this well enough and thank you again for your help.

I think I get you you mean. TBH I didn't thoroughly test this particular feature: as I didn't see any bug report I assumed it worked as expected. This is not a feature that I use much as I rarely store sensitive data from users on sites I work on (well, besides passwords...). I'll test it asap and see what can be done about it. In the meantime, if you don't mind, could you list here what would be the expected behavior you believe it should have, and the needed behavior if not coincident to the expected behavior. I'll see if we can add extra options to the feature and fix what is wrong.
Thanks

[WDJames]

Hi Jo,

Thanks again for looking into it, we've used the modules before and are really happy with what it allows us to do. This was just the first time we've thoroughly tested the Encrypted fields. For now, I'll double check with the client if it is an absolute necessity that the fields are encrypted - if not then we'll set it to non-encrypted.

Based on the module docs, I guess our expected behaviour is:

1. Site Admin is unable to read the Encrypted info when editing user in MAMS (action.admin_edituser2.php).
2. User can see their Encrypted info on the Change My Settings form.

At the moment, the Site Admin cannot see the Encrypted info when editing the user in MAMS IF the user hasn't edited the Encrypted info. But once the user edits it on the Change My Settings form then the Encrypted info is visible to the Site Admin.

Also, initially, the user is not able to see their Encrypted info on the Change My Settings form (fields appear blank but the data is in the database) but once they fill it in, they are able to see the new values (still encrypted in the db).

Again, I'm sorry if my description isn't the best but I hope this helps.

Thank you so much for the module and all the help.

James

[Jo Morg]

Thank, and yes it does make sense: it seems to be a bug in the encryption algorithm; it seems to be using the salt source from the username and some other data, but probably when is set manually by an administrator the username (or whatever the salt is computed from) is not the same as when the user itself enters the data. Should be a simple fix though. Thanks again.