Understood and added to list

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.

Keith Chisarik

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.

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

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

Keith Chisarik

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.

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.

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.

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

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