Hello,

I have an appointment delegation system where employees can login and view any appointments which have been assigned to them as well as their managers being able to view themselves and their teams appointments and employee details.

What i wanted to do was have a button which when clicked, took the logged in user to only their employee details and didnt allow them to view any others and i thought this could be achieved through some kind of find script but i am struggling to do it!

At the moment, I am still desgining the database so things can be changed. I am using the employees full name as their login name and i know this isnt ideal, i would like to use their employee id as the user name but this brings me onto my next challenge.

When creating a new employee i wanted a drop down list of managers to assign to them and at the moment i am using a value list for that field which is based on a concatenation of their name. whats the best way of selecting a manager, would it be to have another table called manager and when have a tick box on the employee table called manager so when that is ticked the employee is then also copied into the manager table? Not sure how i can achieve that.

Any help anyone is able to give would be really appriciated

A

I think reading Jonathan's post will help:

http://jonathanstark.com/recursive-data-structures.php

When I've done such systems, I use a staff table. Each record has the staff members AccountName and PrivSet in addition to the basics such as FName, LName, etc.

In an Open script, I find in the staff table for Get (AccountName). That'll land me on their staff record. Now I publish their StaffID to a global field in my SYS table (gStaffID). So, the system now can use that gStaffID anywhere. Meanwhile, on their staff record, I have a portals of the data that they are allowed to see (since each portal looks to other tables using a relationship that matches on the StaffID). All navigation is tightly scripted to/from their staff form layout (their Main Menu).

Thank you so much for that reply.

The example on that site regarding the recursive table is exactly what I needed and has actually taught me something very useful!

I think reading Jonathan's post will help:

http://jonathanstark.com/recursive-data-structures.php

When I've done such systems, I use a staff table. Each record has the staff members AccountName and PrivSet in addition to the basics such as FName, LName, etc.

In an Open script, I find in the staff table for Get (AccountName). That'll land me on their staff record. Now I publish their StaffID to a global field in my SYS table (gStaffID). So, the system now can use that gStaffID anywhere. Meanwhile, on their staff record, I have a portals of the data that they are allowed to see (since each portal looks to other tables using a relationship that matches on the StaffID). All navigation is tightly scripted to/from their staff form layout (their Main Menu).

Does anybody know where the posting above has gone to? The link no longer works and I looked on his site and it doesn't appear to be there anymore.

Christopher

Jonathan has moved onto other things and has revised his site.

I think reading Jonathan's post will help:

http://jonathanstark...-structures.php

When I've done such systems, I use a staff table. Each record has the staff members AccountName and PrivSet in addition to the basics such as FName, LName, etc.

In an Open script, I find in the staff table for Get (AccountName). ...

bcooney,

I know this is an old thread but it sounds useful for what I'm working on. As mentioned above, the link you posted is now dead. Could you explain the technique you were referring to? I have a Personnel table with all the standard contact info stuff, as well as a UserName field. All users of the database will have their AccountName (under FMP>Manage Accounts) entered into the UserName field of the personnel table. But even though the text value of the Personnel:UserName field is identical to an AccountName, FMP doesn't know to link the two.

How can I reference the fields in the personnel table for the currently logged in user in calculations and scripts? I need some way of telling FMP to-

take the currently logged in user's AccountName, find the record from the Personnel table that has the same value in the Personnel:UserName field, and return the Personnel:LastName value for that record.

I have a tread started on it here, but then I found this one and it looked like your link might have been the answer... but it's dead

http://fmforums.com/...__fromsearch__1

The answer is above!

"In an Open script, I FIND in the staff table for Get (AccountName). That'll land me on their staff record. Now I publish their StaffID to a global field in my SYS table (gStaffID). So, the system now can use that gStaffID anywhere"

Please let me know what part of that you do not understand. Perhaps a pseudo-script sample:

Go to Layout "Staff"

Enter Find Mode

Set Field "AccountName" ; Get (AccountName)

Perform Find

//trap for errors

Set Field gStaffID to StaffID

I would rename your UserName field to AccountName because, um, that's what it is.

Please let me know what part of that you do not understand.

I just got it working using a similar script but hadn't been back to update the forum. Thank you for the reply. What does the "trap for errors" line do though?

that was my first incline, but I was afraid that I would end up confusing the FMP AccountName in "Get (AccountName) with AccountName the field. This way I know what I'm looking at and that the scripts are referencing the item I intended, instead of accidentally looking up the FMP account when I meant to get the field value from the personnel table.

Well, the "trap for errors" is a comment line. You should write the script to account for not finding a user record or finding more than one user record. What you do if that happens is your choice. I usually throw a dialog to "contact the system admin" and quit.

good point. I'll throw something in there for that then. I'm using the user names assigned by our IT for emails, so there shouldn't be any duplicates. And as long as I enter them correctly in the database, it should always find one and only one record. But if something does get entered wrong it would be good to have a script that can handle that.

The next level of scripting well is when you script for errors (even those that are "impossible").