Could it be possible to add an email field to the User Table and of course the Edit User Item form?



Also make the DisplayAs field available as a property of SecurityBasics.CurrentUser instead of having to create the User's BO and query the BO to get this info. Frankly I would like to see all User's fields available as properties of SecurityBasics.CurrentUser, that shouldn't be difficult to implement unless there is a reason not to?

Edhy Rijo

Uh..."use it".

Hi Bill,

Sure I like your approach and it is nice to be able to expand the user data that way, the problem is with the End User (my customer), if they have a form (the Edit User Item form) to enter their user info, I don't see how I can add fields to that form other than me re-creating this form at the SF base class level.



Other option may be to have my own form to extend the user's properties and have a One To One relation, but in my case mostly all I need is the email address for now.

Edhy Rijo

Create a small data table in the DB:



USERDATA

userindex int

us_pk int

emailaddress varchar



The UsersBO that I described would have a custom property that would read/write to the emailaddress field of the USERDATA table based on the SecurityBasics.CurrentUser.UserPK. One-to-one relationship? Sure. But unlimited extensibility. Tomorrow a new request will arrive that you will need to further extend the user information (phone number, extension, birthdate, employee ID, etc.). The USERDATA table would be the place to do it.



If the USERDATA table gets to big, then I would suggest going the other way. Make the UsersBO structured from the USERDATA and have the SFSUsers' fields be the custom properties.



Lot of ways to slice this one.

Hi Bill,

Thanks again for the explanation, I will explore that route also, even thought for now since I only need one file which is common for everybody it will make my life easier to have the email field in the SF database.



Using my custom form, I still need to know how I would link the users to my form, probably using a Combobox with all Active Users.

Edhy Rijo

I tend to agree with Bill on this and think that adding more fields to the SFSUsers table isn't likely a great solution. I'd tend to use another table (and actually do) for extra info.



However, I also agree with Edhy ( ) that the UI for this could get messy. If you're using the SF security dialogs, then you'd need to provide another way to add extra user information. Or you have to replace the security dialogs to include the special user info. The first isn't ideal from the user's perspective and the second isn't much fun for the developer.



So, maybe the enhancement request would be extend the user form to allow an option extended user information. I can think of a couple of possible ways of doing this, both of which would just provide hooks into the form, such that additional information could be provided or accessed as needed. A couple of thoughts:



1. Have an optional toolstrip button on the user form which would call a delegate which would handle opening another form to capture/view additional information. The delegate would likely need the user_pk.



2. Have an optional extended panel avaialble, kind of like the browse dialog does. The panel could then have any UI needed and it would be integrated into the SF user form seamlessly. There'd have to be hooks between the panel and the main form, to manage saving of data, obviously.



Any thoughts of this?

I vote for option 2, it would be the perfect solution to have an Extended Control to add all extra fields needed and will keep the related data in a single place for the End User.

Edhy Rijo

Extending the Edit User Item form might be nice, but you may still going to run up against certain constraints. User data can come from so many directions...database, XML file, Operating System, Active Directory, etc...that preparing a form to be extended may not be the easiest thing in the world. In order to extend it for one field, SF might as well extend for any field, or any number of fields.



Perhaps a new tab could be placed on the security dialog that is called User Defined. When the security dialog is opened. a specified user control designed in the application (with unique wiring just for the security dialog) could be included in that tab which would allow the developer to extend the general user data to anything that they want. It would pass the us_pk to the user control. From there it is up to the developer to extend the user info (just an email address, or more). How's that sound?



Bill

Bill,

This could be extended as the Browse Dialog Information Panel where we are able to enter all fields, labels, etc. Of course this will required a BO translation to handle the One2One relation or something along those lines.



I am sure Trent will get the idea

Edhy Rijo

Exactly Edhy! The information panel in the browse dialog essentially allows you to do anything you need to, it just provides you with information/translations etc. from the main dialog. I'm thinking the same thing here. The SF framework would know nothing about what else might be going on (with good reason), just that there is a place for something to happen/be shown and there is a mechanism to share info out of the main dialog with the extended user info panel.

What I was suggesting is essentially the same thing. The only difference is that the developer is not creating a new security dialog then attaching a user info panel, but rather the security dialog is looking for the "User Information Panel" (a specialized user control similar to the browse info panel!) and adding it to itself (on the User Defined tab). Unless there is a a security dialog in the framework that I am missing somewhere.

Bill,



Exactly what I was proposing...guessed we just got our wires crossed (tried :electrocuted: but that didn't work). I'm suggesting that on the standard SF User dialog (the one were you create the user, set roles and/or permission), there would be the option to set a user info panel/control/thingy. Likely this would be done in the constructor and/or via a property. Putting on a tab is certainly an option and would work fine.