Custom Fields for User Info and Registration

Posted: Tue Aug 23, 2011 10:36 am

Raven wrote:

The `users` table is set to default to 1. I don't know why but I would not agree with that. Here is a portion of the schema:

Field Name: user_allow_viewonline
Default Value: 1

Try changing the Default Value to zero using phpMyAdmin or a similar tool. That should `fix` the new user issue. If that works we can then address the profile update issue.

Still having this issue.

I have set the user_allow_viewonline default value to 1.

If I leave that default field in Admin Users Configuration Active, when a new user registers/activates, their online status is set to NOT hidden. However, if I deactivate that default field, then all new user registration/activations are saved with status HIDDEN. This makes no sense....

Site Admin/Owner Joined: Aug 27, 2002 Posts: 17088

I suggested setting it zero, not deactivating it. What happens when you set it to zero (in the table itself)?

Posted: Tue Aug 23, 2011 3:48 pm

Raven wrote:

I suggested setting it zero, not deactivating it. What happens when you set it to zero (in the table itself)?

Same result as above...

Site Admin Joined: Jun 04, 2004 Posts: 6432

We are testing changes that enable most (but not all) of the user profile fields to be:
- used in the registration process
- optional or required (for registration, user maintenance or both)

We expect to have this in the 2.5 release.

Some assumptions that are important to note:
- admin views and can edit every attribute, regardless of whether or not the user can (this is necessary in case a field is deactivated, but users can still have data there)
- every attribute is optional for the admin
- if it's required for registration only, it will be display-only on the user maintenance screen
- if it's required for registration, it's required for user maintenance, too

While testing the activation, we found a significant issue related to this forum topic. We are asking the user - who has already entered most of the information (excluding the forum yes/no flags) to confirm / maintain this information. But there is currently no provision for this to be maintained here (it is only copying the data from the temp table to the users table). Now that we will have the ability to specify almost all fields in registration (the Yes / No forum settings are excluded), there are several options for how to address this.

Options:
1. Display the fields for registration, and allow them to change ONLY the additional yes / no flags not available to registration.
2. Allow even the forum yes / no flags in registration and only display them on the activation screen
3. Skip the activation screen and create the account with defaults and / or whatever is entered on registration, then take them to the user account screen for maintenance of all fields
4. Modify the activation screen to enable maintenance.
5. Default the forum yes / no fields and skip the activation screen. If Forums and Private Messages are active, and if they want to change the defaults, they can do this on the regular user maintenance screen.

Option 2 is annoying - it would discourage people from registering if they had to answer all those unnecessary questions - especially if the forums aren't even active. Option 4 seems unnecessary since it duplicates the maintenance function. I favor options 1 and 5 (with 5 being the best).

What do you think?

Posted: Sun Aug 28, 2011 2:42 pm

Not sure how helpful I will be as I haven't signed up and activated a new user in a very long time. I like the direction this is going though. Some possibly random/disconnected thoughts:

1) First off, I'd like every user profile data element to also have the ability to have a default assigned (by the admin). Admins should never have to change code or alter a table to get new defaults assigned. Wink

2) Keep the registration / activation as simple as possible. Only required data for registration needed.

3) Maybe separate registration from use? Could be a crazy idea, but make it painless to register, but then to use that registration there is a small price to pay: make sure all required profile data is up-to-date plus give them a chance to update all the other (because they were defaulted). Once they've update the required, they are now allowed to continue using the site.

What if an admin decides she wants to now collect another required piece of information, maybe clear out the "profile complete date (a new date field) and highlight for the user upon next accessing the site the field on the user maintenance page which now needs to be entered.

Not sure I've helped... Sad

Posted: Sun Aug 28, 2011 2:50 pm

2 sort of answers the questions, but 1 and 3 are more work...not for this release.

Posted: Mon Aug 29, 2011 11:10 am

kguske wrote:

We are testing changes that enable most (but not all) of the user profile fields to be:
- used in the registration process
- optional or required (for registration, user maintenance or both)

We expect to have this in the 2.5 release.

Some assumptions that are important to note:
- admin views and can edit every attribute, regardless of whether or not the user can (this is necessary in case a field is deactivated, but users can still have data there)
- every attribute is optional for the admin
- if it's required for registration only, it will be display-only on the user maintenance screen
- if it's required for registration, it's required for user maintenance, too

While testing the activation, we found a significant issue related to this forum topic. We are asking the user - who has already entered most of the information (excluding the forum yes/no flags) to confirm / maintain this information. But there is currently no provision for this to be maintained here (it is only copying the data from the temp table to the users table). Now that we will have the ability to specify almost all fields in registration (the Yes / No forum settings are excluded), there are several options for how to address this.

Options:
1. Display the fields for registration, and allow them to change ONLY the additional yes / no flags not available to registration.
2. Allow even the forum yes / no flags in registration and only display them on the activation screen
3. Skip the activation screen and create the account with defaults and / or whatever is entered on registration, then take them to the user account screen for maintenance of all fields
4. Modify the activation screen to enable maintenance.
5. Default the forum yes / no fields and skip the activation screen. If Forums and Private Messages are active, and if they want to change the defaults, they can do this on the regular user maintenance screen.

Option 2 is annoying - it would discourage people from registering if they had to answer all those unnecessary questions - especially if the forums aren't even active. Option 4 seems unnecessary since it duplicates the maintenance function. I favor options 1 and 5 (with 5 being the best).

What do you think?

5 seems most simple to me, although I do like the activation. It helps deter spammers a little.

Posted: Mon Aug 29, 2011 11:27 am

You can still activate, but they won't have an extra step.

I am working on another solution that has proven very effective against spammers...basically, on registration, the email address, user name and IP address are checked against multiple databases of known spammers. If there is a match, no registration. I call this nukeSPAM, and it's in development for a future release of RavenNuke (it won't be in 2.50, though it might be released earlier than the release after 2.50).

Posted: Tue Aug 30, 2011 6:24 am

kguske wrote:

though it might be released earlier than the release after 2.50).

Cannot wait...

worship

Posted: Wed Aug 31, 2011 10:37 pm

Here's an update on skipping the activation screen:

These 2 fields are updated from the activation screen, and we can default them as noted:
user_dateformat - D M d, Y g:i a
user_timezone - 10

The rest of the activation screen fields are not written to the user account, so it doesn't matter what you enter on the activation screen, they will default as:
user_allowsmile (1)
user_allowhtml (1)
user_attachsig (0)
user_allowbbcode (1)
user_popup_pm (0)
user_notify_pm (0)
user_notify (0)

At this point, activation verifies the request, but before displaying the somewhat bogus activation screen, redirects to activation function. We could consider using a switch to configure whether or not to skip activation, but if we did that, we'd need to do a lot more coding to address the issue raised earlier in this post. Smile

IMO, let's leave it like this and move forward with the release.