Propose new functionalities for Decidim software
#DecidimRoadmap Designing Decidim together
Linked to others proposals we submitted lately is another request from our client which deals with the customization of the registration form.
The aim through this feature is to collect data enabling him to improve his evaluation of his actions for his users. Data would be age, gender and others as already written in this proposal (https://meta.decidim.org/processes/roadmap/f/122/proposals/14381).
Obviously this is a sensitive matter regarding Decidim’s social contract.
We thought about making the registration form customizable by the admin from the back office. The responsibility of collecting the data being his, the admin would have to justify in terms and conditions the collection of additional personal data.
Report inappropriate content
Is this content inappropriate?
7 comments
Conversation with Antti Hukkanen
This would be very useful, although many of these use cases can be handled through the authorization metadatas. I can understand it is not always the most elegant way of supporting this kind of use cases, especially with data that the user should be able to control themselves. This would be e.g. their voting location, which is not always the same as home address.
There are also need that some of this user-specific data should be "sticky" based on some specific conditions. In case of budget voting, the user data should become "sticky" (non-changeable) after the user has already cast a vote in one budgeting component.
@ahu we are currently re-discussing how to implement this in Decidim ? Do you still think AH meta data is still the way to go ? We were thinking maybe we could use Decidim forms on the user profile.
Regarding controlling what the user can do, yes, the authorization metadatas are meant for controlling that.
But the usability for manual form-based authorizations is not really great right now. This works when we are using e-identification services since we get the data from a central digital registry automatically during the authentication process. But when entered manually, users have no idea what is an "authorization", how they can get to that view and why they should authorize themselves.
It works the best when this happens through an action they tried to perform but they did not have the right to do so due to missing authorization metadata. E.g. in the budgeting view, it shows a popup that data is missing and then they can authorize themselves after which they are redirected back to the budgeting view. This is quite OK right now.
So in my opinion:
1. The necessary backend functionality is already there through the authorization metadatas and action authorizers.
2. Entering of the manual form-based metadata is currently quite difficult and could be definitely improved, e.g. during the registration process. Not in the current registration form (users already feel it's too difficult) but the next step after that (it would be also a great place to show the sign up for newsletter which is currently missed for omniauth registrations). Entering this data during the registration process and changing it in the user profile would make it easier IMO but I'm not sure how to handle the case if there are multiple authorizations. Maybe you could define for the authorization handlers which of these fields should be displayed in the user profile form?
3. Some of the data should be marked "permanent" (e.g. date of birth cannot change) and some of it the user should be able to change.
Conversation with Antti Hukkanen
To add to this, we have later found it would be useful to have this possibility also in addition to the authorization metadatas. Authorization metadatas serve a specific purpose for "sticky" data that is provided by the authorization provider, e.g.
In some instances admins would like to add extra information fields for the users that the users themselves could control under their profile information. I believe this is technically already possible in the user models but it would require creating the forms that allow collecting and validating this data before it is stored.
If this was added to the core, I would suggest it would be possible to control which fields show up on the registration form and which fields do not show up during the registration. Those fields that are not in registration, could be controlled under the profile information where you can currently control your name, email, nickname, personal URL and about description.
The field types that could be controlled could be similar to those that are right now available for surveys/forms. I vaguely remember seeing some conversation about this particular aspect but I couldn't find it after searching a while.
Hey Antti,
Here are two approaches that come close to what what you are describing
https://github.com/PopulateTools/decidim-module-extrauserfields (I like that you can export the data)
https://github.com/OpenSourcePolitics/decidim-module-sociodemographicauthorization_handler (User can edit the info inputed)
Would love to collaborate on something that would answer to all requirements
Thanks a lot Virgile for these reference implementations!
The first one (extrauserfields) is definitely to this direction that would be preferred regarding these needs. The fields would, however, need to be different but a similar approach would definitely work.
It would be great if these fields could be defined dynamically defined either in a config file or the admin/system panel. But I understand it's a challenge, not so simple to implemet.
Anyways, these are great resources, we'll think further when this comes to the table.
Add your comment
Sign in with your account or sign up to add your comment.
Loading comments ...