Changing User Name

[Allen Anderson]

I trying to replace an custom dbase program that basically runs the company from prospecting for customers through customer maintainence and service and installs. I have developed the 16 data bases so far to take care of the customer service side to include the new federal do not call laws. My problem is that I have employees all over the building through out their normal day and jump on the nearest computer and sign in. I need to track everything they do by the employee number. using the "CurrentUser" is great for this but I need a way to change the user in the preferences and appropriate password applied so that current user is the person entering or editing and not the station they are on. If posible can both be tracked?

[Steven H. Blackwell]

Version of FileMaker Pro??

Steven H. Blackwell

[CobaltSky]

Hi,

As Steven has hinted, the recently released version 7 of FileMaker Pro provides greatly enhanced options for indentifying and tracking individual users.

The side-bar of your post indacates you are using FMD v6, so I guess this is an .fp5 format solution you are talking about. That being the case there are a few options, but they are more onerous than would be the case with the current version of FileMaker.

One option you might like to look into would be the use of a third-party tool such as DialogMagic from New Millennium Communications Inc, which provides the capability to automatically update the user name in preferences via a script. However this is not a secure method (at least not unless you are also deploying a product such as SecureFM to manage menu access) since users can readily access the preferences dialog to manually change the user name.

Another alternative would be to ensure that each user password is assigned to its own separate group (via FileMaker's access privileges in v6) and then track the identity of the user with the Status(CurrentGroups) function. Whether or not this is feasible depends on the access privileges set up and the frequency with which privilege changes are requried to be made.

And of course, there is also the option to migrate to the current version of FileMaker Pro. If you are in a position to contemplate such a move, an added incentive may be the superior security options and flexibility that are available in v7.

[acta]

How can help FM7 to recognize a unique client of a group of clients with the same account and password (for example all the people of same repart)?

Thanks, Sandro

[CobaltSky]

In FIleMaker 7, every user should have his/her own account and password.

You can group individuals by assigning them to the same privilege set. There is not reason to have more than one person signing in with the same account and password (and every reason not to).

Once you have assigned an account to each individual, you will be able to tell who has logged in using the Get ( AccountName ) function.

[acta]

Yes, I tried. But if I use a calculated field with Get(Accountname) the field is non updated when I change account. So I have used a text field and change it with a script everytime there is a new user.

But in this way I am not able to update the field in the other databases (I should have different data for every record opened to every client connected to have a reletion).

I Would like to have a relation, for every client, so: ID clien<>ID client - to have the ID client showed in the opened record of the different database.

----

Sandro

[CobaltSky]

...the field is non updated when I change account.

In order to ensure that the calculation updates, it is necessary that it be defined as *unstored*.

This is true of all calculations which reference Get( ) functions.

[acta]

This is a light

---

Sandro

[acta]

My applicacation is formed by more than 20 databases. If I change the account in the main database I have to change in the other data base too for each computer client?

---Sandro

[CobaltSky]

For robust security and fine-grained control, it is best to set up scripts which will create flow-ons throughout all the databases so that when you create an account in the main database, a sub-script will be called in each of the others to create the account there also.

Password changes and re-logins should be managed similarly, so that the state of the file set is consistent and secure throughout.

The procedure is not too difficult, You will require a small core of three or four scripts in one of the related files which can then be imported into each of the others. A master script in your main file can then be configured to call each of the others in turn.

Once the above is in place, you will be able to efficiently manage the whole process (from creation and management of accounts to user login and password changes) from a single central file.

[acta]

Thank you, you help me a lot to the transition to FM7.

Bye,

---------

Sandro

[Fenton]

This is a fairly simple example file to create and change accounts.

http://www.fmforums.com/threads/download.php?Number=112911

[Allen Anderson]

As CobaltSky indicated I am using FMD and FMP ver 6. I do intend to update to FMP 7 (I have FMD 7 on my desk right now just staring at me) but I have to crawl first. As my side bar says I am using Win 98. I cannot update that until I replace the dinosaur dos based dbase II program first. This runs the whole company except accounting, which is using Peachtree. (I will be looking for a plug in to exchange invoicing data after I update to FMP 7). My employer wants to see the two programs running side by side before he will spend the money to upgrade and abandon the old program. As far as passwords for employees. At the data entry level we sometime have a revolving door and I was hoping to put individual password in the employee database and check for employment status upon login. (So the bean counter can terminate employees by entering their last date of employment and the administrator can possibly get a vacation (wishful thinking). I do plan to encrypt everything after I get all the bugs out. Current security at this level of development is a min. Some of my users are still looking for the "any key". I do need to track every thing they do so I can undo it if necessary. The "CurrentUser" for creation and modification looks to be the answer. But it is set under preferences and I don't want some of these users anywhere near there if I can help it. I currently have 16 databases three to comply with the Do Not Call laws. Under the current federal law if you have a customer that is on the National list and you have not done business with them for 18 months you cannot call them. I am looking for some help to overcome the transistion stages and any advise how to script things to help the upgrade to FMP 7 easier.

Thanks

Allen

[Kurt Knippel]

In this case it would be best to store the value in a GLOBAL field that is set with Get ( AccountName ). This global is then available to all files in the solution.

[CobaltSky]

Hi Kurt,

Just to clarify...

A value in a global will automatically be available to all tables in the same file. Tables in other files will only be able to access the global if they have a file reference to the file in which it resides *and* a table occurrence of the table in which it resides in their (local) relationships graph.

In a multi-file solution, there is a trade off to be considered. In order to access the name of the currently logged in account from each table in each file, one must either create a network of file references and table occurrences and then contrive a scripted write to store the account name in a single global - or one must include an unstored calc field in each table. Or some mix of the two (eg some files could retrieve the account name by one method and others by another).

Which approach or mix is best depends to some degree on the nature of the solution and on how much of the required infrastructure of file references and table occurrences will already be in place for other purposes.

[acta]

My solution function.

Now I can change password for each account for all the databases so every client recognize own files.

I used a text field (Nameaccount) in the main file for each account and calculated field in the other files get(Nameaccount) and create a relation between them.

From the main file a script call all the other scripts in the other file to create, modify and delete accounts.... all functions.

FM7 for this problem is more powerful!

---

Sandro