Jump to content
Salesforce and other SMB Solutions are coming soon. ×

Help with Passwords


burno_06
 Share

Recommended Posts

Hi guys. I use File Maker Pro 5v1, (I know it's a bit obsolete). I'm currently designing a database for a school. Wherein the teachers are required to input information about their classes into a page that is exclusively theirs (namely individual records of a particular layout) . So basically I want to know how to set a password for individual records. Does anyone know how to do so?Thanx.

Link to comment
Share on other sites

Hi guys. I use File Maker Pro 5v1. I'm currently designing a database for a school. Wherein the teachers are required to input information about their classes into a page that is exclusively theirs (namely individual records of a particular layout) . So basically I want to know how to set a password for individual records. Does anyone know how to do so?Thanx.

Link to comment
Share on other sites

You don't do that in FileMaker 5.

 

You do that in FileMaker 5.5 or beyond, using Record Level Access (RLA). Beginning with FileMaker 5.5, you can define access on a record-by-record basis using a formula that you input. For example, if there was a field "Teacher ID#" and there was also a global field "g.CurrentLoggedInTeacherID", you could set up record level access as

 

Case(Teacher ID#≠ g.CurrentLoggedInTeacherID and not IsEmpty(TeacherID#), 0, 1)

 

 

In FileMaker 5, no. Access Privileges in FileMaker 5 were basically untouched since FileMaker 1. I kid you not. They only got marginally better in FileMaker 5.5 and 6, and then got totally revamped and modernized in FileMaker 6.

 

If you do upgrade to FileMaker 5.5 (a somewhat difficult task, given that you can't buy it off the shelves so easily nowadays), be sure to put an introductory script step that turns User Abort off, checks for Status(currentapplicationversion) and exits the application with a message if TextToNum(Status(CurrentApplicationVersion)) is less than 5.5. Otherwise, anyone can open your solution with 5.0 and have access to all records, unimpeded.

Link to comment
Share on other sites

I put an answer in your other thread which asked the same question.

 

Short answer: you're hosed in FileMaker 5 (unless you want to meticulously script the finding of records and turn off all menu items except Editing functions). If you can upgrade to FileMaker 5.5 you can do it though.

Link to comment
Share on other sites

I'm not sure of functionality in version 5.0, but what if

- you shut off menu bar access to users (can this be done in v5?)

- hide the status bar

- script the login, and create a found set of records that match the user's ID

- browsing the found set using scripted find or scripted 'next record' only.

not the same as RLA privileges, but it might do as an alternative.

 

kjoe

 

PS i just notice this is similar to what AHunter wrote in post #4 which got merged from the other thread. ah well this is what happens when you double post.

Link to comment
Share on other sites

Actually (since in my profile I brag about being into retro-FileMaking)... yeah, you can do it under FileMaker 5.0, it's just a nasty mess of business best avoided if you can get a later version.

 

The problem with scripted Finds is that if anything misfires in Find mode or otherwise dumps your user out into a "Show All Records" state, your user has editing and viewing privs and your other teachers have no privacy. And the possibility of that happening is really hard to eliminate. The entire time that they are in the solution, you've got a file out there that they have access to, that has editable layout(s) that they have access to, and only artificial ways of keeping them from viewing and editing data that is not theirs. One forgotten "Allow User Abort [OFF]", one forgotten "Set Error Capture [ON]", one navigation script that doesn't turn this file to a blank layout and lock the status area before heading off to some other file, etc etc ad infinitum, and OOPS, Joe is seeing Susan's records (and, perhaps thinking they are his, editing them as well).

 

The way I used to do it before RLA made its debut (and I did tell you it's a nasty mess, right?): You dump your user out into a different file entirely, one with no fields of its own except a constant that you use for relationship-making purposes and a massive double-handful of globals. You build your data entry and editing layout out of those globals, and you load values into them via script from a Find that you perform in the background based on parameters that your user initially enters (if your user has legitimate access to multiple records) or that is hard-wired into the script (if your user has one and only one record). Thus, the data that your user sees is their data but they are not on the record containing it, nor are they even in the file that contains other users' records.

 

The file that does contain those records is given no face (no layouts with fields on them that anyone but programmer or administrator has viewing access to) and no one but the programmer or administrator can create or delete records from it.

 

After your users finish editing data on their global-laden layout, they have to hit a "Save" button to load the data back to their own record, replacing local field values with global values. (You can also save time-of-last-edit and date-of-last-edit for each and every field using this method).

 

If your users' layouts (as originally intended) have related table data such as a portal to multiple child records, you can have a relationship from the global value that holds the primary record's serial number to the child records of the related child table-file. That means that when they edit THOSE fields, the changes are real and instantaneously permanent, just like FileMaker editing normally works, whereas the fields of the master table (which are mimicked in globals) don't get preserved until and unless the user hits the "Save" button. OR you can loop through the child records and write their contents to one or more globals with "¶" separators PLUS a line (child-record) numbering scheme and force your users to enter a line number to bring up just one child-record at a time into yet another raft of globals in order to edit and then save back to the aggregate global, which in turn is flushed via looping script to the real field when you're finished...uh, did I mention that it's a nasty messy piece of business?

Link to comment
Share on other sites

Make a layout that you show on opening, where the user can fill in his/her user name and, if you want a password.

You could make a check password also.

If you do not need that security then all you need to do is create a startup script that set the global “current user” field to the current user name in preferences.

 

You can put a loop at the end of the startup script to keep user abort off even while running other scripts. It does this by preventing the script from ending. The only way to end the script is to use another script to halt or exit . However, this step is not necessary since you can achieve approximately the same level of security with passwords, but you may find looping user abort scripts useful since it prevents users from changing windows, closing files and other things not possible with passwords.

 

Make sure you have a creatorName field and a self-join relationship CurrentUser=::CreatorName.

 

Put only fields based upon this relationship on the layouts.

Lock the status bar and script the navigation between records.

 

Result: only the current user will see data from his/her records.

 

The fields on the data entry layout are related fields and the relationship is based on a global field (current user) and a regular text field (creator name). Actually, the relationship is based on two calculation fields that are based on these two fields but they are the driving force in this technique.

 

If you make scripts to go to the next record and to the previous record you can make them skip the hidden records by making the scripts conditional. Just have the scripts check to see if the current user equals the creator of the record. If not then go to the next record. Put this in a loop and the user will never see the hidden records when browsing.

 

HTH

Link to comment
Share on other sites

The problem with scripted Finds is that if anything misfires in Find mode or otherwise dumps your user out into a "Show All Records" state, your user has editing and viewing privs and your other teachers have no privacy. And the possibility of that happening is really hard to eliminate.

I'm afraid I disagree with the assertion that scripted finds for restricting access to a particular user's records is problematic. Though it does require careful scripting to make the filtered Finds and relationships work correctly, it certainly doesn't require entry screens made up of globals or a separate interface file. In fact, the same general filtering techniques can and should be used in FM7/8 to show only those records that the current user has access to.

 

The bigger problem with filtering by user in versions prior to FM7, is that it really requires a separate FileMaker password and group for each user, or a custom login system. Managing a separate password and group for each user is difficult for a large number of users (as in a school). And a custom login system can be hacked fairly easily. If security is a concern, then it is a better reason for upgrading rather than how difficult it is to implement some technique to filter by user in the current version.

Link to comment
Share on other sites

You got that right. I *hated* dealing with the native Access Privs / passwords architecture of FileMaker 6 and earlier. In an otherwise user-friendly and intuitive application, here was this...ugh! Can't even LOOK at the thing while it's served up by FmServer, have to unserve it and open it as sole user. And that awful screen called "Overview", which you couldn't see at the same time as the baseline "Passwords" screen, and from which you could set ridiculously contradictory settings... talk about user-hostile! I always created and deployed homemade custom login systems. Another nasty piece of work compared to being able to do it natively under Fm7-8, although once I had a couple of variants I liked I just rewrote the same logon-routine scripts.

Link to comment
Share on other sites

This thread is quite old. Please start a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share



×
×
  • Create New...

Important Information

Terms of Use