Make the UserProfile model customisable

[madduck]

[This was originally just about removing the Twitter/Github fields for the DebConf context, but has since turned into a discussion about the UserProfile model in general]

======== original text ==========

Hell will break loose if we "condone" or "endorse" a non-free service such as Github or Twitter by even displaying form fields asking for these data.

Would it be possible to make their use optional? A good implementation of #147 (key-value store) will likely give those data a new home anyway, but meanwhile maybe a simple settings.py entry could be used to hide them from the web forms?

(I'll send the patch…)

[drnlm]

I think this should be handled by having proper support for custom UserProfiles. Arguably wafer's UserProfile should not have these fields, and we should have a PyConUserProfile or DebconfUserProfile with the required information as required.

[madduck]

Hi @drnlm, thanks for your thoughts. As I explained in #147, a conf-specific user profile just bears the danger of growing too large over time. Wafer's single-conference approach kinda guards against that, but I can still see much value in the KeyValueStore approach, especially if that storage became available through a REST API.

That said, and realistically speaking, we probably won't have this in time for DebConf16, which means we'll need a DebConfAttendeeProfile anyway.

Am I right in assuming that the main change to wafer required for this to happen would be to parametrise the actual UserProfile model used, e.g. to settings.py? So in our case, if setting WAFER_PROFILE_MODEL=DebConfAttendeeProfile (which derives from UserProfile) would cause Wafer to just use that instead everywhere, we'd be done, right?

And then we could monkey-patch the fields hinting at those evil proprietary services to oblivion and make it all fuzzy for us… ;)

[stefanor]

You could probably also trivially hide these fields with CSS (hack hack hack)

[madduck]

Good idea. I hope to have a look into overriding UserProfile within the next week or two, and will report back.

[stefanor]

I think the entire user profile can be replaced with #147

[madduck]

I am not entirely sure we want to do this. On the one hand, there is still the consideration of allowing multiple UserProfiles for an auth.user (e.g. for family, or colleagues).

On the other hand, at least when I envisioned the k-v-pairs solution, I thought of it as a datastore for per-conference, per-subteam data, sort of ad-hoc stuff, while stuff like email address, emergency contact, display name override, and the occasional other field are really "core" data.

Obviously, the set of core data should be kept absolutely minimal, but I think that in addition to #147, it'd be good to have extensible user profiles, i.e. an easy way to subclass/specialise a user profile for a given conference family.

[stefanor]

On the one hand, there is still the consideration of allowing multiple UserProfiles for an auth.user (e.g. for family, or colleagues).

I don't think that actually works, at least for the current UserProfile schema. I think we'd want a User for each user.

[madduck]

We could always introduce a new schema, but as we've previously discussed, maintaining the auth ←→ profile relationship is also possible. I guess we'll see once we get our hands dirty with KVPairs.

[madduck]

@drnlm and @stefanor:

Having played with this a bit today, I could not find a straight-forward way to override the user profile model to use. Wafer's settings.py has it in its INSTALLED_APPS and this will mean a hook gets installed to create an instance of the profile for every auth.user created.

Furthermore, UserProfile fields are accessed in various places, such as the Page and Talk models.

My suggestion would thus be to remove users.UserProfile from Wafer and fix up the templates and other stuff to use reasonable data in place.

Once that's done, individual conferences can easily inject their own profile models, using the same post-save signal approach, and can access all the profile data from their own templates.

If you guys agree with this approach, then I would get started to do the heavy lifting.

[hodgestar]

I'm -1 on requiring conferences to define their own core models like this. I'd prefer us to provide a configurable list of social media platforms to show / ask for in profiles and only have the forms display entries for supported fields.

[madduck]

I don't believe it's possible to make the existence of model fields configurable, so you are really just talking about hiding the data from the UI?

Would you be open to the following? Next to the current UserProfile (which can grow in the way you envision, though I thought the goal was to keep things lean, and social media sites come and go…), provide a bare-bones profile that conference can opt to use and extend instead?

If so, then this is surely a setup-time decision conference organisers must take and I would be happy to investigate how to make this configurable.

[jonassmedegaard]

5 years later, this issue is still open despite #198 being merged (or am I misunderstanding that as being directly related?), yet I see only Twitter and Github handles at the instance for MiniDebconf India and personally I made a crude hack of adding handles in the bio field: https://in2021.mini.debconf.org/users/js/

[hodgestar]

This did stall a bit because there wasn't a clear path forward and everyone stopped discussing it. After re-reading it and looking at the comments in the code, I think the correct approach is to:

• Add optional support for social auth using a standard Django library.
• Replace the hardcoded Twitter and Github links in the profile model with a list of social sites and handles (possibly with the list of sites and validators being configurable)

I'm not likely to implement this plan myself right away, but I am happy to review and potentially merge PRs.

[drnlm]

The social media and code hosting profiles have been removed from the user profile and are now configurable via settings.