I heartily agree with you on this one as well.

Attribute tables are not generally the best way of doing things, as things may turn out to be way too data dependant. Also handling things such as changing an attribute name, deleting an attribute become more complex. Maybe a mixture of the two approaches would be best.

"Core" entity fields are ones in which the core team is responsible for be are handled in the actual core tables via fields. However, each core entity has an ExtSettings (Extension Settings) which can map additional settings for extensions or expandibility. Thus, core code would always refer to an actual table /field combination, but any extended functionality, instead of modifying the core table, could simply use the ExtSettings for the table.

This helps to get away from migrating databases and merging database changes from multiple verisons, ie: XXL and core 1.0.10.

there, that's my thoughts on the subject as well - now, we'll both step off of the soapbox and watch the responses!

Richard Cox
ByDesignWebSights

Shaun,

You mentioned that you've already got some functionality for extending the vendor information and could adapt it to extend the information gathered on users.

I would think that gathering information about users, not standard to everyone, is a fairly common need. Obviously there are ways to program around this and gather the information but it seems like information related to the user should be part of the core and not a home grown addition.

Not anything to lose sleep over, just curious about whether you've already done the leg work for this or should I start building this functionality myself (which will have to be removed at some point when it is built in).

Y'all (Core team) are doing a fantastic job on this project and I, for one, appreciate all the work you've put into it.

Rob

I have been looking at this also. One thing I have wanted is a profile page other people can look at, and only the user or admin can edit.

So far I have modified the address.ascx file and created to more controls, one for login details and another for personal info like AOL #, ICQ#, Yahoo #, likes, dislikes, and background.

Each of the fields can be turned on or off by the admin, plus address fields can be selected to validate or not.

So far it works.

If anyone is interested to look at it I will set it up online for people to try.

Anthony

It would be great to see what you have working.

Thanks,

Christian

If there was a simple mechanism to add a new registrant to a specific pre-defined user role because they checked a specific checkbox next to a registration question, that would be idea.

For example, I would add a listbox of several choices the new registrant could make, and based on their response they would be automatically added to a specific user role.

'Simple' would be in the setup form for the registration form, I could add my custom field, select 'checkbox field' and type in what i wanted that checkbox text to display, then I'd check another box next to that and select an existing user role from a drop-down list.

A more complex method would be basing the user role on a combination of checkbox selections, but that would require the user putting an if/then or select case statement in a box that could be used. I think the simple option would be great and people could adapt their checkbox options to accommodate it.

[add checkbox field] text: receive monthly newsletter
[checkbox] add to user role: [selection list]
[checkbox] redirect user to: [TAB or URL]

users could be added to multiple roles with this,
the roles could be refreshed on submitting the registration page:

The redirect TAB or URL could be added to each choice, but only one be used;
perhaps the last one that corresponds to a checked checkbox.

//expire the cookie that has the portal roles
Response.Cookies["portalroles"].Value = null;
Response.Cookies["portalroles"].Path = "/";
Response.Cookies["portalroles"].Expires = DateTime.Now.AddYears(-30);

//redirect to a selected tab. this should cause the cookie to get reloaded and the new
Response.Redirect(DotNetNuke.Globals.GetPortalDomainName(PortalAlias, Request, true),true);

To make it truly flexible, I think the option to add a checkbox GROUP would be useful.
The admin could add checkboxes independently, and if needed could add checkbox GROUPS as well. This way one could put something like:

Select your primary interest
(only one choice allowed)
[checkbox or radio button] text: Option A add to user role: [selection list] redirect to: [TAB]
[checkbox or radio button] text: Option B add to user role: [selection list] redirect to: [TAB]
[checkbox or radio button] text: Option C add to user role: [selection list] redirect to: [TAB]
[checkbox or radio button] text: Option D add to user role: [selection list] redirect to: [TAB]

The redirect URL field next to each of the checkbox field works even better in the GROUP scenario because only one choice can be made.

Is this possible?

Yeah - I'm also VERY interested in seeing this type of functionality in the core - I was going to create another UserData table with customisable fields that an admin could create and then my other modules could use them, but I think the ability to extend the fields held against a user in the core functionality would be ideal. To be honest I am suprised this has been outstanding for so long given the benefit and usability it would provide (and considering the differences in every different implementation, but I know we are all busy people!!! Please let us know if this is in the pipeline...