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

I agree with exposed things through the CurrentUser.  But what would be the purpose of an email field?  Why would this not be part of the customer record?  If the email was provided, then other than it being accessible, what would it be used for?

Hi Edhy,



I've gotten around this problem by creating a UsersBO. It fills the basic data from the SFSUsers table, but then I extend it with custom properties and grab data from other User information sources. For example, I have an old users table with tons of data that I still want to access. I retrieve that data when I fill the UsersBO. In addition, there is a ton of info sitting in the Active Directory...I grab a few things from there, too, and fill some custom properties. Some other unique data that I retrieve are the computer name, IP address, and a few other things that are not necessarily stored in a data table anywhere. I wrap all of this up in a global class so that once the user fires up the application, I grab all of this data once and user it where ever I need it. This way I do not rely on SF to extend their SFSUsers table. I can extend it in any direction that I need to through my UsersBO.



Hope that helps...holler if you need more details,

Bill

Uh..."use it".

In my case the RBS users are not customers, but I have 2 projects where the users have their own email accounts and I need to send email from the application and must use the user's email in the ReplyTo field of the email.

Edhy Rijo

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