By Edhy Rijo - 4/20/2009
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?
|
By Trent L. Taylor - 4/20/2009
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?
|
By Bill Cunnien - 4/20/2009
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
|
By Bill Cunnien - 4/20/2009
...I grab all of this data once and user it...
Uh..."use it". 
|
By Edhy Rijo - 4/20/2009
Trent L. Taylor (04/20/2009)
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?
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.
|
By Edhy Rijo - 4/20/2009
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.
|
By Bill Cunnien - 4/20/2009
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.
|
By Edhy Rijo - 4/20/2009
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.
|
By Greg McGuffey - 4/20/2009
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?
|
By Edhy Rijo - 4/20/2009
Greg McGuffey (04/20/2009)
2. Have an optional extended panel available, 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.
|
By Bill Cunnien - 4/20/2009
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
|
By Edhy Rijo - 4/20/2009
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 
|
By Greg McGuffey - 4/20/2009
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.
|
By Bill Cunnien - 4/20/2009
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.
|
By Greg McGuffey - 4/20/2009
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.
|
By Keith Chisarik - 5/14/2009
How have you guys handled the interface to let the end users enter the additional data that is stored in the external table that links to the RBS users table. I dont see a way to easily do this. I need for my end users to be able to easily define additional user data (customer ID, phone numbers, etc) and would really like to avoid them having to maintain users in two places (RBS screen and a custom screen).TIA
|
By Teddy Jensen - 5/14/2009
Hi Keith,I know it's not the best solution, but I have a second maintenance form to edit the extra userfields and control which datagroups they have access to. /Teddy
|
By Trent L. Taylor - 5/15/2009
All you need to do is create a second table that uses the SFSUSers.us_pk as the foreign key to that table. Within this table you can put anything that you like such as preferences, etc. You will need to have a separate maintenance area for these preferences, but this is not generally an issue. You will setup the user then have another table with all of your custom data fields. You can then INNER JOIN the queries to get what you need.
|
By Keith Chisarik - 5/15/2009
thanks, was trying to avoid that second screen. Like others have posted here I would very much like some way to add custom users data from within the RBS, like an infopanel, even a way to add a button right in the RBS screen somewjere that says "Add Custom User Data" woudl I think be acceptable.
|
By Trent L. Taylor - 5/15/2009
Understood and added to list
|