Custom User Fields

[lonnieezell]

Seamless integration of custom user fields into the app.

[ghost]

This would be great - there are a few other auth libraries out there that do this. We should have a look around and choose the best option. Eg Ion Auth (http://benedmunds.com/ion_auth/ - http://github.com/benedmunds/CodeIgniter-Ion-Auth/) has a meta table CREATE TABLE meta ( id int NOT NULL IDENTITY(1,1), [user_id] int, first_name varchar(50), last_name varchar(50), company varchar(100), phone varchar(20), PRIMARY KEY(id), CONSTRAINT meta_check_id CHECK(id >= 0), CONSTRAINT meta_check_user_id CHECK(user_id >= 0) );

and a config array $config['columns'] to specify the column names in the meta table.

That is one option.

[ghost]

I would love to get this one in sooner rather than later, but we need to be careful with the first_name and last_name code coming from the main user table.

[Icehawg]

What if you didn't hardcode the table fields? Would the table get to large and unwieldy with this manner?

CREATE TABLE meta ( id int(12) NOT NULL AUTO_INCREMENT, user_id int, property text NOT NULL, value text NOT NULL PRIMARY KEY(id), CONSTRAINT meta_check_id CHECK(id >= 0), CONSTRAINT meta_check_user_id CHECK(user_id >= 0) ) ENGINE=InnoDB DEFAULT CHARSET=latin1

IE. id,user_id,property,value 1,2,first_name,Sean 2,2,last_name,Downey 3,1,first_name,John 4,1,last_name,Smith 5,2,email,seandowney@awesome.com

etc....

?

[ghost]

That's another way of looking at it and I'd have to think about it more before giving a proper opinion.

Some possible issues (again without having thought about it properly):

• what if you wanted to add/edit/delete field types
• migrations might be harder this way
• hardcoding the table fields would only really become an issue if you had lots of fields (what do you think is the max number of fields you should have in one table - 10/20/30 ?
• if the fields are hardcoded you could possibly use the field type and details to auto generate the admin for the fields - not possible with the dynamic way

Anyway they are just some thoughts and after putting those down I would sway towards the hardcoded table.

S

[ghost]

Oh I just noticed the email address you used - I wonder would they let me have that :-)

[daK76]

Hi Funny, I just commited a new config option, 'auth.use_extended_profile', I use it to integrate my own auth libs.

If set, for now it just omits some address fields, before 2.0 I'm not comiting anything big.

But it's intended to be used exactly for this purpose. To have an option so we can start and play to extend bonfire default user profile.

[daK76]

Just a doubt... and a reference point

Are we somehow building an ORM kind-of extension, to interact with pre-exisintg user tables and 3rd-party libs?

Or preparing a meta-table kind-of, to share common data with other libs?

[ghost]

All I would want it to be able to link a user meta table to the main users table so that the main table doesn't include meta.

[daK76]

If you mean, ha ving a table for us to reproduce whatever extra user fields we want, perfect for me.

Feel free to user the config var for activating the new db qry call, it has that specific purpose.

[ghost]

Yeah that's what I mean.

Ah cool I'll have to try out your code.

[Icehawg]

@seandowney

Just to address your questions (not sure if you still want/require answers but just in case)

I guess it depends on what you intend to do with the meta data. Normally, for me, I create meta tables like I described because I don't normally have any real intentions with the data. It is "fluff" for lack of a better word so I don't care what kind of field, I use, or what kind of data that I am storing (other than harmful of course) so I use a generic blob for the name of the data and the value.

If I plan to manipulate/use/alter/adjust the data in any kind of real way (other than basic updating) or I want to use a different kind of field set to limit input to just integers (for example) I hardcode that data into a users table and properly set it up. Information which is just extraneous to the user account, I simply toss into the meta table with the generic property/value blobs.

That's all I meant by having generic fields in a meta table. Real work = hard coding, for sure. (heh...that wasn't intended)

EDIT : oh yeah, I normally find that once I get past a 12 fields in a table, I find it starting to get cumbersome to manage. But that's just me. I would rather have 20 tables with 10 fields each than 10 tables with 20 fields each.

[ghost]

Good points there from project to project we may want "fluff" or "hard" stuff :-) So the trick with this is to leave it as open as possible but still have good touch points into the Users so that us developers don't have to start hacking at the core files to get what we want.

As @daK76 said he has a setting in the app config (auth.use_extended_profile) to use the extra meta. We could possibly have another setting to say what type of meta it is - fluffy or hardcoded.

We could possibly use one or more modules to manage the extra meta and therefore not restricting ourselves to one meta table. These modules could be called using HMVC at the different touch points - User Create, Edit. The listing of users, and specifically using some of the meta in the list could be tricky.

But the modules could be listed in the app config and used in a specified way eg if you are on User Edit page then the meta module(s) Edit method is called.

Does any of this make sense? (I'm not sure)

EDIT: I would agree on the table sizes too btw :-)

[Icehawg]

Ya I think I followed all that. Although I think that to avoid forced nomenclature it might be wise to allow for the config to state the name of the users table so that developers can use their users tab....?..wait nevermind. This starts pushing bonfire back towards CMS or ORM which is not the vision.

My bad. ;) Sorry.

[daK76]

Ouch, my head hurts...

I don't know if I'm not following correctly, but we might be "mixing garlics and antibiotics" here (have to stop mind-translating popular proverbs). Extending Users authentication to something more then default bonfire or 3rd libs AND Extending default bonfire User table to easilly contain user extra fields.

Custom_User fields make all sense to me IF

1. we have a minimal Users Auth structure - IMO bonfire currently almost has it, but still doesn't (eg. address, country_iso...) AND
2. we want to empower our apps by extending that minimal necessary Auth, to our (inimaginable) needs - and here bonfire should help developers. OR
3. devs want to code with specific custom fields - eg. user type of blood - and bonfire will help us with UI coding

In fact, most designers I know of don't have a clue why am I concerned with:

• InnoDB and transactions
• Indexing
• Join VS Where, PK vs FK
• Redundancy and Normalizations
• DB optimizations and SQLizations
• 10 tbls w/ 20 fields VS 20tbls w/ 10 fields

Ultimately, I am the one who will be responsible for DATA records. I am the one who should set my architectural backbone. But I could get a hand here, bonfire could help me. How? To be honest it's dificult to answer my own question. Here's some loose ideas...

• Giving me an easy interface/tool to use whatever custom_fields I defined (and DBtable coded or going to do it) on my new webapp - on other words, it will facilitate my UI design but won't alienate me from my DB responsabilities.
• By somewhere during authentication process (Auth lib), optionally detecting I want to override some of default code flow - in other words, if a config item is set, do not run block A but instead block B (and then I'll have a new login algorithm) - note that block B here doesn't exist, the developer only has a conditional configItem ready to be used, like an empty else.
• The fluff and serious data is a funny concept, we should blend it in this cocktail somehow

Damn I just blew a fuse in my head! Maybe I just introduced more confusion, sorry...

[ci-bonfire]

First - I'm not sure if we want to move this to Milestone 0.2 or not, but that's a different question.

Second - I'm not going into the details of how we do this yet. I still need to think on that a bit. But I agree with the concept: let's strip the users table down to just the bare minimums needed for any type of app: first and last names(?), email, password, etc. Everything else should be in a meta table.

I'm not sure how nasty the code gets, but Wordpress handles it like this:

user table: holds the basics, plus display_name and a couple items like that. usermeta table: has a umeta_id, user_id, meta_key and meta_value. For each optional piece of information (like first_name), it inserts a new row that might look like:

umeta_id => 1, user_id => 3, meta_key => first_name, meta_value => Lonnie

This has the benefit of only storing what is actually needed for that user. As for how it knows what fields are available, I'm guessing it's either in the options table or hard-coded somewhere.

Another nice thing about this system is that modules can add to it as they need to.

What does everyone think about doing something like this?

[Icehawg]

Yes. I like this idea. :) It is the one I have used in my own works for years now.

-----Original Message----- From: ci-bonfire [mailto:reply@reply.github.com] Sent: Wednesday, July 06, 2011 1:10 AM To: icehawg@gmail.com Subject: Re: [Bonfire] Custom User Fields (#14)

First - I'm not sure if we want to move this to Milestone 0.2 or not, but that's a different question.

Second - I'm not going into the details of how we do this yet. I still need to think on that a bit. But I agree with the concept: let's strip the users table down to just the bare minimums needed for any type of app: first and last names(?), email, password, etc. Everything else should be in a meta table.

I'm not sure how nasty the code gets, but Wordpress handles it like this:

user table: holds the basics, plus display_name and a couple items like that. usermeta table: has a umeta_id, user_id, meta_key and meta_value. For each optional piece of information (like first_name), it inserts a new row that might look like:

umeta_id => 1, user_id => 3, meta_key => first_name, meta_value => Lonnie

This has the benefit of only storing what is actually needed for that user. As for how it knows what fields are available, I'm guessing it's either in the options table or hard-coded somewhere.

Another nice thing about this system is that modules can add to it as they need to.

What does everyone think about doing something like this?

Reply to this email directly or view it on GitHub: https://github.com/ci-bonfire/Bonfire/issues/14#issuecomment-1509500

[ghost]

Yep I've no problem going with the majority - the key/value method is fine by me.

I agree with what @Icehawg said in #45 that the first_name and last_name should also be stripped out. Most apps won't use them.

[daK76]

Sorry but I wish to make a stand here, before we redefine users core tbl and users meta tbl

I need the users made name, my apps are currently Organizational. And organizations are collaborators, which are my users, or employees.

Could you all please consider the following:

To me it makes sense, instead of first and last names, having

• Full user birth name
• Abbreviated user birth name

Why?

My name is "Nuno Miguel Lopes Costa". What's my first name? What's my last name?

Well, tough answer IMO. Because to some people, first_name is everything except last_name. Other people consider _lastname everything except _firstname

How could we satisfy every Use Case?

Like I said, by having

• User name - Full user birth name
• Abbrev name - Abbreviated user birth name, in case someone has 10 names

Also, Wordpress is all about CMS and worlwideweb users. That's why the first_name and last_name. IMO we should not stick to that specific WP conception of first and last name. We want bonfire to be all-rounded. And the best way to do it is by having a User full Name (Birth Name), and the Birth Name abbreviated form.

Of course, both fields not necessarily in core users table, but it must be somewhere.

Does anyone agree with my POV? Does it makes sense to you what I just said?

[daK76]

One more thing

Icehawg said

Users table, therefore, should only include those fields that are imperative to exist for bonfire to work. examples : userid, username, email, password, salt, ip address, status(active, inactive, banned, etc...), last login(?), etc...

Totally agree

If our App is worldwide oriented, we'll probably use email as login If our App is Organization oriented, we'll probably user username as login.

That's why I implemented the Identity thing...

[ghost]

@daK76 I don't think we should define the user meta table. That needs to be app based and defined by the developer.

We should however define an example meta table and code that goes with it. This should probably be an addon rather than in the core so developer modifications aren't on overwritten.

Thkughts?

[Icehawg]

@daK76 - last_name could be changed to "family_name" if that suits your needs better or since the meta table is so flexible you could use "given_names", "middle_names", "family_name" and allow the user to decide what names to put in each field since they would understand their own naming convention. Then, when you want "full_name" you just punch the three names together with a space separator.

i.e. given_names = "Nuno Miguel Lopes" mdiddle_names = family_name = "Costa"

or

given_names = "Nuno" mdiddle_names = "Miguel Lopes" family_name = "Costa"

in either case when your code pops them together it would read : Full name = "Nuno Miguel Lopes Costa" (code, of course, checking for empty or null values and dropping those to avoid too many spaces)

This, btw, makes a good case for the names to be out of the core user tables as I don't even want real names in my next app so I won't even bother offering those fields at all in the profile unless the users demand it. :)

@seandowney Aye. Agreed. A meta table itself should exist in the core for bonfire's needs so that the developers using it know of its existence but any kind of example (maybe incorporated into the todo tutorial) should be addon.

[kaysersoze]

Hey guys, I'm currently in the middle of a project that is integrating Bonfire into it's CI codebase, and we find a need to implement the meta table has been discussed here. As such, I'd love to contribute back to Bonfire.

To this end I've forked the code, and I'm putting in the features there. Our need for this is pretty immediate, so we'll be cranking away at this at a (hopefully) pretty speedy pace.

Some questions I'd like to pose to you guys:

• Should this live as a separate module, or part of the user module?
• Would it be smart to create a default set of meta fields that correspond with the existing user fields for backward compatibility? I assume this could be an array of field names in the applications config named something like 'auth.extended_profile_default_fields'
• Should the meta table be generic or just for User Meta?
• As far as the UI for this, how do you guys envision it working. It would be nice to have a way to add meta fields through a UI, as well as providing a means to add validation options (which could be as simple as providing a text fields where you could input them in like: 'required|trim'). Any ideas on how to display the fields relevant to say, the User's model (if we decide on a generic meta table).

Any and all feedback is welcome. Thanks.

[ghost]

Hey @kaysersoze

Excellent sounds good.

All good questions and need some thought. If you are ploughing ahead for your needs though I would say go for what suits your requirements now.

I think it would be good to make it generic but that makes it a longer dev task for you now because you'd have to introduce some way to match the meta to the parent data. Other people might not agree with me anyway and @Icehawg has some ideas on this too.

If it is in a fork we could always see how you went with it and then discuss it further before bringing it into the core. These changes are for 0.3 anyway so we have time.

From my point of view to answer your questions:

• separate module
• yes I agree with that
• generic
• yes but this makes it more complicated - almost adding meta (validation details) for the meta ! :-) A quick win for the validation would be to put it in an array structure in the 'auth.extended_profile_default_fields' config setting.

I'm looking forward to seeing this progress. Thanks for working on it.

S

[Icehawg]

Yes, @seandowney and I were having a goodly little talk about this for a couple days just before you posted this.

Basically, what I had understood from before, was that there was talking of instituting a global metadata table. Mostly for user data at first, but it would be opened up for all modules to access (according to what @lonnieezell was saying...I think. heh)

Anyway, that is great and I will be using it for global meta data but it doesn't really fulfill my needs and I prefer to also have per-module specific (or "table" specific if you prefer) meta tables. I find that, for me, one gigantic meta table for "everything" becomes too cumbersome for me to manage/maintain/admin/etc....so I use a global for things that are site wide, and module specifc for the particulars.

This conversation came up because I use table specific meta tables so often I was working that into the modulebuilder and spoke to @seandowney about it. I wanted to ask his opinion on my generating a meta-data-table option, if the checkbox is selected, during the modulebuilder and I got that finished but since the majority of what I reworked could be used without my meta stuff, I stripped it out and submitted it since the modulebuilder now works/functions mostly like the other core modules.

Now I am working on being able to grab the meta data fields in the controller files generated by the modulebuilder so they can be edited and dynamic adding new meta data fields in the controller files generated by the modulebuilder so I can have meta tables "out of the box" whenever I run the modulebuilder for my purposes.

Did I explain that right? Probably not. Tired.

Summation : I like global meta data tables for site-wide data and per-table meta datas for table specific data. Yay.

[kaysersoze]

Hey folks. Sorry for the radio silence in the last day or so, but I've been traveling back from the West Coast.

That said, I've been thinking about the best and smartest way to do this, even if it's a first iteration, as I don't really want to be removing flexibility or having to massively rework things later on to fit a better, more useful model.

Here's what I'm thinking so far:

• Separate meta module. Should handle any and all meta needs, with basic CRUD methods, as well as a thorough Find implementation. If people wish to implement their own separate meta tables, that's all good, but we should be able to handle most things "in-house".
• For the meta table, I'm assuming the following fields: foreign_key (for mapping to things like the User/Auth module, generic enough to be able to be used by anything - can be NULL for generic data), key (VARCHAR 128?), value (TEXT), created_date, modified_date

I guess those are my main areas of concern currently. If there's anything you'd change, just comment. I like being peer-reviewed as it can ferret out hidden issues before one commits themselves to them.

Regarding module-specific meta-tables: Once the first revision of the meta implementing a catch-all table is complete, I would consider making methods to create said tables, but I'd have to get feedback from everyone here first as to what would be useful, as that isn't something I handle often (I'd rather keep all my meta in one table, personally).

Look forward to hearing from everyone.

[ghost]

Hey @kaysersoze

No worries about the silence, nothing is expected. Thanks for spending the time on this.

All sounds good to me except I think you might need another field, eg "table", to identify which table the foreign key refers to?

Thanks again

[ghost]

Hi @kaysersoze

No pressure but is there any update on how you are going with this development?

Thanks Sean

[kaysersoze]

Hey @seandowney,

I was actually going to update this thread today, and you beat me to it. I've been delayed fixing some issues for our product that were blocking testing, so I wasn't able to get this out as soon as I'd like.

I will be putting stuff out this week, as I already have a few things implemented locally, and have really been itching to finish the meta implementation up this week and put it out there.

FYI, I will be adding the "table" field to the list of fields I specified before, to make foreign key linking easier. Thanks for the suggestion.

[ghost]

Hey @kaysersoze

Cool - looking forward to seeing and playing with it.

[kaysersoze]

Hey guys. I was working on Meta today, and was wondering where the correct place to put my DB modifications were. I used the 001 migration to place the initial creation of the meta table, as well as modifying the user table creation step to remove any user columns that could now be stored in the meta table. I then noticed that the 002 migration is being used to do DB upgrades/changes, so I was wondering exactly what should be done.

My plan is to use 'auth.use_extended_profile' config to enable/disable the extra meta, which is pretty much anything other than id, role_id, username, email, and other 'non-meta' columns...essentially the bare minimum.

So I guess my questions is: where is the best place to place each step?

[Icehawg]

I was under the impression that any db changes warranted a new migration file so a fresh install wasn't needed whenever a db change was made.

That help? ------Original Message------ From: kaysersoze To: icehawg@gmail.com Subject: Re: [Bonfire] Custom User Fields (#14) Sent: Aug 31, 2011 15:22

Hey guys. I was working on Meta today, and was wondering where the correct place to put my DB modifications were. I used the 001 migration to place the initial creation of the meta table, as well as modifying the user table creation step to remove any user columns that could now be stored in the meta table. I then noticed that the 002 migration is being used to do DB upgrades/changes, so I was wondering exactly what should be done.

My plan is to use 'auth.use_extended_profile' config to enable/disable the extra meta, which is pretty much anything other than id, role_id, username, email, and other 'non-meta' columns...essentially the bare minimum.

So I guess my questions is: where is the best place to place each step?

Reply to this email directly or view it on GitHub: https://github.com/ci-bonfire/Bonfire/issues/14#issuecomment-1960892

[kaysersoze]

That makes sense, but where would something like this live? Would we make a "Version_03_upgrade" migration, or would I just add a separate migration just for meta stuff like: 009_Add_meta_table?

I guess I'm not entirely clear on the migrations concept yet. Sorry for any of my confusion.

[Icehawg]

If it is planned for bonfire's core, as yours is, you would wrap all your db changes into a new migration file like 00#_add_meta_table and place it in the /db/migrations folder with the up() and down() functions defined.

You can have migration files for just your app, or make some module specific.

I am hoping that every 3rd or 4th RC we can wrap all the bonfire migrations into 1 install so that we don't have dozens of those files kicking around. But I haven't brought that up for discussion yet. :)

[kaysersoze]

Ok, I think that definitely clears up things for me. I was confused about the core vs. module/application migrations, but you have explained it quite well.

Thanks!

[Icehawg]

No problem. I only hope I did explain it right. Newest developer to the team so I can still get things un-right. :)

[ci-bonfire]

@Icehawg, you got it exactly right.

@kayswersoze - first of all, love the name. That was a wonderful movie. Second, looking forward to seeing this. Thanks for the contribution!

[kaysersoze]

Another semi-related question: is there someplace (IM, IRC, Skype) where people hang out? Just wondered if there was someplace I could ask some questions in since I'm running into some unknown issues creating this migration for meta.

[Icehawg]

Not really. There is a forums at cibonfire.com but this is the place to get the fastest response.

[kaysersoze]

Hey guys. Again, sorry for any delays. Work has been keeping me super-busy attending to non-coding and non-Bonfire stuff lately, so I've not had nearly as much time to devote to the meta stuff until now.

I've recently pushed my local changes to my personal Bonfire fork here: https://github.com/kaysersoze/Bonfire

This contains all of the initial meta stuff, as well as a few small text fixes I found as I was poking around. I tried to keep everything as similar to the existing code as I could.

Here is what is done so far:

• Meta module created. Implemented Meta_model and migration for meta
• Initial set of changes to the find() and find_all() function in the User_model.
• View changes in User admin to display user meta

Please check over my changes and review/comment on things. I'm receptive to all comments and constructive criticism, as well as any direction and changes you guys need me to do. I know there's some issues with the activities module that I will need to resolve, as well as the create/update implementation in the user model.

I'm going to be doing a lot of active development on this throughout the beginning of this week, as we star to integrate the Bonfire code into our application, so any comments and changes now will get implemented quicker. I'm sure lots of stuff that's there isn't quite right/needs refinement/may not be needed, but since I'm new to the Bonfire structure, I could really use your help in letting me know what those things are.

If you guys would like to reach me in a more instant form of communication, I'm often on Skype chat and IM. Both usernames are: tepofarkas

Fell free to message me there and here, and I will respond quickly.

[kaysersoze]

Realized I need to make changes to the login process as well (queries, first_name and last_name), so that will be going in along with some other changes tonight.

Any comments welcome.

[ghost]

@kaysersoze Thanks for all the work on this. I haven't had much time to test anything lately but will hopefully get time soon.

Thanks again

[kaysersoze]

@seandowney No problem. I know there's bugs there currently, as I'm not as intimately familiar with the Bonfire workings and methodology yet, but as they are reported (and hopefully I find them before that), I will fix them.

The most useful things to me at this point will be what meta functions are needed/wanted and which are superfluous, as well as any improvements over some of the methods I am using. Basically anything that will make the end product easier/better.

Thanks again for a great project, and I'm looking forward to continuing to contribute.

[kaysersoze]

User meta on user creation and update are now working.

[ghost]

@kaysersoze It's been ages but I am only getting to look at this now.

I'm not sure if you have done more development on your side but there are some issues with getting your code working.

I posted to you repo.

[ghost]

@kaysersoze Oh you don't have Issues turned on - here are the issues I found:

• The app, config and database config files aren't in the config folder so it won't install.
• Line 189 of the users/libraries/auth.php file is referring to first_name and last_name but they are not selected in the query above it.
• When I did get logged in and went to /admin/settings/users it's giving a user_meta error

[kaysersoze]

@seandowney Thanks for posting the issues. I actually had put this one on the back burner a while back, as we had a lot of new development (and new developers) come onboard for our project.

I will take a look at the issues you posted this week and get stuff working. We've actually made a decision to stick with barebones CI instead of Bonfire due to the fact that we would have to work just as hard to customize Bonfire to meet our specific needs as they evolved vs. just creating what we need from the beginning.

I am still committed to helping you guys get user-meta in there, though, and it will also work alongside some of my development, as I work to get a user class built for our project that includes meta, and move away from ion auth, which we currently use.

Thanks again.

[ghost]

@kaysersoze ah right that's fair enough, Bonfire is supposed to be a jump start but if it does suit there is no point using it.

Thanks for continuing to help on the user meta stuff.

Just curious, is there anything that could/should be in Bonfire that would have made it worthwhile to stick with it?

Thanks again

[kaysersoze]

@seandowney The user roles and permission in Bonfire were sort-of, but not quite, what we needed for our particular application. Nothing wrong or missing with Bonfire at all, just our development path took a different turn as our application evolved.

No problem with the meta stuff. It's something that I think is useful for a user class, and just for a framework in general, so I'm happy to contribute.

[ghost]

I'm going to close this ticket as there is code in place in the feature/sd_merge branch at the moment and a prototype in the feature/user_meta branch.