I'm working on a design for a project that has the following requirements and I need to see how SF "User File" system can work into this situation:



a) The project is supposed to work for a company that has several remote stores.

b) Each store has it's own users, sales persons, customers, sales records.

c) All these stores will be using one common inventory, one order/item files for sales. So basically all these stores’ inventory, sales and other files are stored within one database.

d) Each user needs to be under a particular store. So, store # will be the parent of each user. Which means, when a user is being created, first the Store # must be selected and then the user, to have the store # as it's parent.

e) When a user logs in, the program, will look at the store # of the user and will limit all the customers, sales persons for that store. This way, I can logically separate each store from others.



Seeing that SF uses it's own program and data files to create users, permissions, roles and etc. and I need to attach a store # as part of User record, how can I incorporate Store # into user system? This way, I can look at the logged in user and get the Store # and take it from there.



Could you please tell me what my options are, without disturbing the flow of SF security system and still be able to use store as parent.



Thank you in advance!

..ßen

Ben, I've have a similar situation (but more complicated...imagine if the employees could work at different stores, with different permissions at each store ). Yours is a bunch simpler. You will simply need to create a separate table to link store to employee. The table will have a pk, a link to the SFSUsers table via the pk in that table and a link to the store, via the pk in that table.



You will have to build an admin form to link users to stores. Typically this is done by a manager type. I used a checked list box, filled it with all users, then check the users who have access to a particular store. If the manager is some HR type at the home office, I'd use a combo filled with all the stores. If it was the manager at a particular store, then the store is known (because the manager is associated with the store).



Now that you have the linking table and can fill it, you can use in your app to limit the customers and whatever else is store dependent. You might consider caching the store of the current user with a class, so you can get the ID of the store without requerying the link table.



Hope that helps!

Thanks Greg; I had thought about creating a seperate table (store/employee) that would contain the two fields: Store# and Employee# (user#). This way, I could have the main office manager create the user in SF security program first, and then create another program of my own that would allow the manager to create a new record in store/employee table by selecting a store from a list of stores first and then selecting a user from list of users from SFUser file. This would create me that link file. Then in my program, I can always look at this link file and see who the user is and which store#. Are we saying the same thing Greg?



I thought I bring this up to see if there is other way that the manager does not have to take the second step to create the link record. Somehow, when the manager creates the user, I can then create the link record, but I still need to know for which store #?

..ßen

I'm guessing that you're a former VFP user and in your mind file=table, right? You seem to use them interchangeably. I'm going to assume we are talking about a table in the database.



Yes we are talking about the same thing



The security tables/BOs/Forms can't/shouldn't be changed (as I understand/remember it, we don't have source for security forms/BOs or if we do, we don't have licenses to change them). So, this will either be a two step process, using the SF security form to create the user and a custom form to link users to stores OR you could role your own security form and do it in one step. The second seems like a lot of work for something that isn't done that often (one would hope). The list of users can be filled using the SFSUsersBO in MicroFour.StataFrame.Security.BusinessObjects namespace.



What I've done is have a form that has a combo with the list of stores and a checked list box with the list of all employees. When they pick a store, loop through the link table, setting/clearing check boxes for the employees at this store. Then when the user checks/unchecks the user for that store, set/clear the link, respectively. While it is still two steps, it's pretty easy for the user to manage users as the stores.



A suggestion about the link table, it should have three columns: a pk identity column (autoincremented), fk to SFSUsers and fk to stores. Having the pk column will make life easier when dealing with the link.

Greg, thank you very much for the confirmation. You're right, the link table will have an auto increment PK!





No, my last development tool was/is Delphi, which we user table/file interchangeably.



Prior to that I used other tools, but nothing that used dBase file system



BTW, are you coming to the class? Were you successful convincing your boss?

..ßen

Drat...I was being sooo clever too!







I'm still working on it. I'm hopeful. I'll let you know as soon as I do.