1 Reply Latest reply on Jan 27, 2012 4:25 PM by philmodjunk

    DB with Participant-Entered Data AND Hiding a Record-Based Password



      DB with Participant-Entered Data AND Hiding a Record-Based Password


      Greetings fellow FM users, and many thanks for all trouble-shooting and development help you've provided over the years...

      I work in the Student Media department at a state university (newspaper, radio, tv, magazine, etc) and we're trying to create a DB where we can keep track of all current and past participants for current needs, program evaluation, fund-raising etc.

      I was thinking I could make a limited rights user who logs-in at a computer at the front counter, creates a record using their student ID number, adds the data, answers a few questions etc. and exits via a script.

      What I think I want to do is have each student enter a "password" as part of their record, then allow students with the limited-rights FM login access only the record for which they have the "password".  I worked on this some last fall, and all seemed to be going ok (although my scripting needs some fine tuning).

      TWO questions:

      1) Is this approach reasonable, given that I don't want or need to create 100's of user accounts, and want the students to enter and edit their own data rather than complete paper forms requiring data re-entry.

      2) Is there a way to make their "password" secret/transparent and accessible ONLY by the application itself? My thinking is that a good number of them would probably use their campus ID online password which I don't want to in anyway be accessible by myself or any other administrative user.

      I realize that if we were to upgrade or FM Server and Pro software, we could use the active directory services on campus, and it wouldn't be a real problem. However, I don't see the funding for our FM software and a custom solution were running happening anytime soon.

      We're using FileMaker Pro and FileMaker Server v 8.5

      (Hopefully, once all the bugs are worked out I can migrate things to web publishing.)


        • 1. Re: DB with Participant-Entered Data AND Hiding a Record-Based Password

          It's not unreasonable, but keep in mind that you do not have to manually create the accounts should you choose to use actual accounts for the user. You can use global fields with a script set to run with full access privileges to create accounts with passwords specified by the user. This is the only method I am familiar with that would keep the passwords hidden from users with Full access privileges--though a plug in is probably available that could encrypt/decrypt passwords that might be set up in such a way that you can't access the unencrypted data...