I would suggest that you familiarize yourself with record level security in the Filemaker security section. You can restrict the user to records by a calculation so if your user's name is not in a particular record they can't see the record at all. This is kind of buried about 4 levels down in the security section where you can limit access with a calculation.
If you go the scripting route you would probably need to hide the status bar from the user and set up your script to find out who is logging in then doing a search for his/her records. But if you leave the status bar active they can user the find or find all and find any records in the file. So any buttons to let them find their constituents for example would have trigger scripts to include their user name.
You have to first define how you know that a record belongs to a specific user.
Then you will have explain how you are sure that the current user is really the specific user from above, not somebody else just using his credentials.
Then you will have to do a lot of work to make the whole foolproof but with reduced penalty on performance and functionality.
Do you really think it's needed, for attendance training ?
Short answer is yes it can be done.
The success of such a venture will be directly related to how much time and effort you want to expend trying to cover every possible escape condition.
For example performing a find WILL prevent the user from having access to the records in question but what do you want to have happen if they click the show all records button? What if they do their own find?
How do you want to restrict access to child records from a portal on a parent record? What if the user can write their own scripts or make new or edit existing layouts?
Ever play whack-a-mole?
I would strongly heed the advice to leverage the built in security model first. Build a scripted system only when you can not achieve adequate control with the tools at hand.
coherentkris, yeah, i have thought about the security issues that may arise from all this many, many times over. yet at the same time, the people who are doing the data entry are not that all programming literate. of course, some can be but those are the minority or only a few. still, i know that i will have to think of them as well.
i will be locking down pretty much anything that a user may used to try and snoop around this FMP solution.
for the time being, however, my script looks like this (from the Attendance Menu as assigned to the Attendance button):
the fact that i'll have like 25-30 users, the IF statement will be longer that what is shown above.
let me know your and everyone's thoughts, please.
Regardless of the users IT skill level they will probably find some way to break the security even if by mistake
the minimum you can add is a allow user abort off, otherwise any monkey hitting cmd-. can screw your script..
Consider using a CASE statement instead of multiple IFs to set the cFullName field.
very true coherentkris
siplus, that's a very interesting addition to the script. how can a user abort a script assigned to a button with now show dialog?
Whats wrong with using properly nested If statements?
No problem at all, I make extensive use of nested Ifs.
In this instance I'd go with Case.
It is clear that just one field is being set, and formatting with line breaks makes it easy (for me) to follow the logic.
It reduces the number of script steps, and only one step needs editing to add more conditions.
So like I said, consider the option, then go with what you are comfortable with.
by pressing cmd-. on a mac or esc on windows while the script is running.
It is possible to prevent the user from stopping the execution of a script.
In French FM : Auto. annulation utilisateur (Yes/No)
Something like : Cancel user autor.
Happy new year