Create users/roles with new fields

[SamC]

I wanted to create a client profile with fields:

profilePicture
clientEmail
clientAddress
clientPhoneNumber
profileFacebook
profileTwitter
profileLinkedIn
profileGooglePlus

...etc. At the moment, this lot sits in a template called 'site-settings' but they should really be associated with a user. Ok, so this site only has one user so it doesn't matter, but I'm looking at future practice and if the site had multiple users, assigning the above to each user would be impossible.

I created a new role called 'client'. So I have a couple of questions. Hypothetically, my new site will have 10 client accounts, each with the same fields as above:

1) Would I assign these fields to a ROLE (rather than a user, where name, email, password and role fields seem sufficient), then create new user with this role?
2) How do I add fields to a role?

I'm confused between 'modules/configure/processRole' and 'modules/core/processRole'. Both of these urls have a way to add fields, but what's the difference?

Any advice would be awesome, thanks.

--EDIT--
Are roles just for permissions?

--EDIT--
Wait, I just saw there's 'processProfile' and 'processUser' (in core and config dropdowns). Even more confused now.

[arjen]

You assign the fields where they need to be stored. For example:

1. Save every field which should be connected to the user to the user template (for instance: an address field, since every user will have their own address) 
2. Go to Setup > Templates ... Filters > Show system templates. When you need to add logic to a role 99% of the time it makes sense to use permissions. For instance create permissions so show specific parts of the layout like a comment box for a specific type of user. I have seen rare edge cases where it would make sense to add other fields to a role. See permissions and user.
3. Role are used to store permissions, but since they are pages you can assign any field which makes sense. See point 2
4. ProcessProfile is where the superuser defines which fields the user is allowed to change on their profile page (/processwire/profile/).
5. ProcessUser is the process module for the users page (/processwire/access/users/).

[SamC]

Thanks @arjen that's a decent explanation but I'm still not 100% clear on this.

I think it would be helpful if we could define what is meant by a user (or use different terminology to show what type of user they are). This confuses me a bit when people talk about 'users'.

To me, there are different types of users (of the logged in to your site variety). For example, an admin could have superuser role, staff could have a 60% permissions client role (maybe excluding config/permissions sections or something), and members (i.e. people who are a member of your site, who can only change their email/password/avatar) with a member role.

So in the above case, how would you handle something like this:

1) An admin may only need name, email, password.
2) Staff may have fields, email, phone, address, department, name, email, password.
3) A member may have avatar, email, social media profiles, name, email, password.

Is it just a case of putting EVERY possible required field onto the user template, then users (I mean anyone who logs in) would just fill in the fields they require? Or did I just describe an edge case?

I've seen situations on the forum which describe having users as part of the page tree. Would this be a normal way to do things if you had 100,000 members? Or would they all be listed in '/access/users/'?

I've set up a local site in which I am going to experiment with user profiles to see if I can get this sorted in my head.

[LostKobrakai]

Generally I'd advice to keep the user template as minimal as possible. It's meant to authenticate users and hold basic infos applicable for all users, not to fulfil all your additional data needs, which can be related to an user. E.g. in your example I'd say a user might have a profile for avatar / social media or employee information for phone / address / department details. These can simply link back to the user they belong to.

Having alternative user templates is possible in processwire, but it's limiting you to have just a single (more or less fixed) type for each user. As soon as your types of users can overlap that strategy is going to break down.

[SamC]

Thanks @LostKobrakai

9 hours ago, LostKobrakai said:

in your example I'd say a user might have a profile for avatar / social media or employee information for phone / address / department details. These can simply link back to the user they belong to.

This sounds like a sensible way to organize, Ilike it. So I'd do this?

User (template)

 - name

 - email

 - password

Profile (template)

 - avatar

 - social media link

 - page ref (to user)

...how would I link the two? A page ref field on profile to user?

I'd like to manually create a few users to test this. But if you had 100,000 users, that'd be hell of a long dropdown list on the page ref field.

I'm guessing it would be better to do this programmatically in a template when a user signs up to create a matching profile when the user is created.

Is this what's meant here?

[LostKobrakai]

Yeah doing that manually not not really a good thing if you expect so many users.

[arjen]

I tried several options but for me adding all fields to the user template would be the way to go. I've experimented with different templates per role, but like @LostKobrakai mentioned this won't work when you have roles with overlapping functionality. Using several templates with Page fields is also an option I tried, but then the amount of templates increased.

My simple solution: create per role a Fieldset and show and hide these fieldset based on InputfieldDependancies. So fieldset_role 1 will only show if role=1. This way you can visually hide fields that don't belong to certain roles. Yes, you have more fields, but at least you won't see them. And getting and setting data from the API is pretty straight-forward too. Although the template option won't create much overhead.

[SamC]

Some good suggestions, thanks. Just gonna crack on with a test site and see if I can put this together. Can I just clarify something, when we talk of creating new users, are we saying all users will be listed at '/access/users/'?

Or do they sometimes get created in the page tree?

(I'm talking generally, not edge case)

Also, (in @LostKobrakai's approach) if having minimal fields in the user template means having a second template, wouldn't deleting a user in the admin (when logged in as superuser) mean also having to delete the associated profile page manually? Everything seems to be doubled up.

I'm sure my preferred method will become clear once I've played around with it.

[LostKobrakai]

With processwire not using foreign key relationships it does need custom hooks and/or logic to enable the structure I proposed. It's a bit more work to do, but also a lot more flexible than simply dumping all fields in the user template. Also users are by default stored under /access/users. Only with manually creating an alternative user template and enabling it in the config.php you could have users elsewhere in the tree.

[SamC]

On 27/07/2017 at 9:20 AM, LostKobrakai said:

With processwire not using foreign key relationships it does need custom hooks and/or logic to enable the structure I proposed. It's a bit more work to do, but also a lot more flexible than simply dumping all fields in the user template. Also users are by default stored under /access/users. Only with manually creating an alternative user template and enabling it in the config.php you could have users elsewhere in the tree.

Been meaning to come back to this as I wanted to try it out. Custom hooks and/or logic?

Are there any examples of this floating about? Ok, don't know what a hook is so it's not a great start, but willing to learn. How about this for my idea:

1) User can either login or sign up n a little content block. Would need a create account like which would go to (a) a custom login form or (b) the standard admin login (not sure which)

2) Signs up, is redirected to site.com/my-profile

3) They can edit profile info, click save

4) Profile page is automagically created

TREE:

Home

About

Profiles

 - John Doe

 - Jane Doe

Something like this? Then when they log in (in future) they are redirected to their profile page. Ok, so it's a bit naff, they can't actually do much. However, I really need to start making some more interactive things but I seem to be trapped in this void between brochure type sites (with one admin and one client) and more interactive sites (with automatic user creation etc.).

Seems my problem is how to handle new users, and how they create content themselves. Do they use the admin tree? Or have a separate dashboard? So many questions.

I guess experience will help to guide me eventually but right now I'm up the creek without a paddle. Wish I knew someone round here that used PW so I could see some real life setups in action, would make so much more sense.

[LostKobrakai]

Here's a primer on what hooks are and how to use them: https://processwire.com/api/hooks/. They're essentially a way to add custom functionality within processwire's workflows.

[Krlos]

@SamC I'm working on a project of this nature, but its an Intranet with profiles and custom fields for storing information about differents kind of user. How did you do it in the end, which approach did you use?

 

 

[SamC]

3 hours ago, Krlos said:

@SamC I'm working on a project of this nature, but its an Intranet with profiles and custom fields for storing information about differents kind of user. How did you do it in the end, which approach did you use?

Sorry but I didn't actually make anything, the whole thing was hypothetical. TBH I still don't know how to approach different 'types' of users.

Saving everything on a user template doesn't make sense to me when users will need different fields. I like the sound of @LostKobrakais approach best, using a user template simply for authentication and having a 'profile' or 'employee' template linked to the user.

If you do work it out, feel free to share how you did it!