sorry, I need to ask you a few questions to understand this fully

-sek - 24 May 2007 03:32 PM

Just wanted to let you know I encountered a problem testing FAL 1.0.4 not sure if anyone noticed this, but my existing user from the previous version was in the database.

are you sure that this user had a profile before upgrading ? did you tried on 1.0.3 what you tried on 1.0.4 ?

I could bring this up fine in the admin and display the form to edit the profile. On the right, the new custom profile fields defined in the FAL configuration appeared, naturally with nothing in them.

why naturally ? because it did have nothing in it before too ?

I checked the database and the fields were created properly along with the profile table.

fields are created when you run FreakAuth_DB.sql
but no row for your user I guess

In the details (view user) to the right it says “no data in DB: please add them” but when I go to the edit profile form, enter my name and surname, it refused to populate the fields. It says “0 user edited successfully!”

did you keep the third field of the demo config/freakauth_light.php file ?
is there an error for it ?

I looked in the database and found there were no rows in the fa_user_profile table. Could the reason be that I did not go through the installer step, being an upgrade?

the installer does not create a row for the #1 superadmin in the profile table anyway

Or is there some reason why it will not create the row if one is not already there (the automagic?) I suppose it could be the user entry was created under the previous system and therefore no user profile row exists.

I hope I followed the upgrade instructions correctly. They were a little confusing.

sorry for this, I’m a beginner!!!
could you point to the obscure parts?

Okay, I added a row for user 1 using phpMyAdmin (the superadmin was the only one in the database left from the previous time) and it works fine. I assume this would happen for pending users as well. It could really be a problem if you had a dozens of users and had to create these rows manually for each. Perhaps this could addressed in the next release for those upgrading.

well, I don’t know what we could do here, this is linked to the ‘profiles filling at register time’ question
it depends on you, FAL user !!! do you want FAL to create an empty profile for every user?
I think that this behaviour is correct for now, displaying “no data in DB: please add them”.

sorry, concerning my new profiles db structure

then the last table contains the data: (id, data)

I should have said:
then we have a table for each field, containing the data: (id, data)

I noticed ‘FAL_lenght_validation_message’ is not spelled correctly in several files. It should be ‘FAL_length_validation_message’

Hope this helps.

Steve

corrected in 1.0.5, thanks

@grahack

Those are excllent ideas. I agree with eliminated the distinction between extended and special types of user profiles. I was thinking more of the seperation between the basic auth profile as the regular and the custom as the extended, since when I did this before, we kept it very simple and just used a flag to determine whether to display or edit the extended profile information for the special person. Auth, profile and extended profile were all kept in the same table.

I like the idea of making it it possible to reuse fields for different types of users without any coding.

It makes perfect sense that a musician and an actor could want a favorite movie field where the actor would not want a musical instrument field. No reason to duplicate the movie field for both.

I’ve seen user specified meta data stored in a table with the id, field id and value this way:

custom_meta_data
————————————————————————
item1 | fieldname | valueA
item1 | fieldname2 | valueB
item1 | fieldname3 | valueC
item2 | fieldname | valueX
item2 | fieldname2 | valueY
item2 | fieldname3 | valueZ

It is a bit wasteful to repeat the fieldname, but this can store an id normalizing the value into another table, which is efficient.

Since a profile is now a collection of fields and there is a one to many relationship between a user and a profile field (one surname, favorite movie per user), I would think only two tables are necessary.

profile_fields
———————————————————————
fid | user_id | field_id | field_value
———————————————————————
10 | 102   | FName   | Stephen
11 | 102   | LName   | Wade
12 | 102   | FavMovie | Catching the Music

fields
——————————————————————-
FName | First Name
LName | Last Name
FavMovie | Favorite Movie

and so on.

Unless I do not understand your table scheme.

Steve

-sek - 24 May 2007 05:17 PM

I’ve seen user specified meta data stored in a table with the id, field id and value this way:

custom_meta_data
————————————————————————
item1 | fieldname | valueA
item1 | fieldname2 | valueB
item1 | fieldname3 | valueC
item2 | fieldname | valueX
item2 | fieldname2 | valueY
item2 | fieldname3 | valueZ

It is a bit wasteful to repeat the fieldname, but this can store an id normalizing the value into another table, which is efficient.

the problem to me is that we can’t define different field types for different fields (like a date, a boolean…)
I prefer one table per field

Since a profile is now a collection of fields and there is a one to many relationship between a user and a profile field (one surname, favorite movie per user), I would think only two tables are necessary.

profile_fields
———————————————————————
fid | user_id | field_id | field_value
———————————————————————
10 | 102   | FName   | Stephen
11 | 102   | LName   | Wade
12 | 102   | FavMovie | Catching the Music

well, as said above, I quite disagree with that

fields
——————————————————————-
FName | First Name
LName | Last Name
FavMovie | Favorite Movie

and so on.

and with this too
as for the country table, those things should go in a lang file

Unless I do not understand your table scheme.

I think that you understood it, tried to suggest another one, but I prefer mine.
Do you agree with the reasons I gave ?

Hi,

First:
I have made a little correction in my solution to reduce the number of database acces on login, see the commented code.
The initial post
All my notes

Second:
I have build an activation form with the needed librairie and front lib function and config and lang var.
That avtivate the user by form instead of email link. It needs the user name and activation code and use optionaly the security code.

Why

Because in some case I need to activate the user by phone only.
And so I change the content of the activationEmail…..

If you are interestead in this form I will give you tomorrow….

thierryREY - 24 May 2007 06:40 PM

If you are interestead in this form I will give you tomorrow….

yeah, why not!!!
just another config item!!!

Hi everyone, please consider this common auth API attempt.

grahack - 24 May 2007 06:34 PM

the problem to me is that we can’t define different field types for different fields (like a date, a boolean…)
I prefer one table per field

Since a profile is now a collection of fields and there is a one to many relationship between a user and a profile field (one surname, favorite movie per user), I would think only two tables are necessary.

profile_fields
———————————————————————
fid | user_id | field_id | field_value
———————————————————————
10 | 102   | FName   | Stephen
11 | 102   | LName   | Wade
12 | 102   | FavMovie | Catching the Music

well, as said above, I quite disagree with that

fields
——————————————————————-
FName | First Name
LName | Last Name
FavMovie | Favorite Movie

and so on.

and with this too
as for the country table, those things should go in a lang file

For the meta data case, administrators needed to add and modify field names, so they were stored in the database. If field names only change when new software is released, the language file is the best place.

I am reluctant to create a table for each field. After a while, there might be a lot of tables cluttering the database. Is storing field data type beneficial? The configuration still specifies the validation rule to apply based on field name.

Steve