3 Replies Latest reply on Apr 2, 2015 7:26 AM by philmodjunk

    Design advice - Web based form submission

    mchancevet@gmail.com

      Title

      Design advice - Web based form submission

      Post

       

       

      Hello,

      I have a brief for a solution in which:

             
      • We have a contacts database ( this already exists and is referenced by 2 other of our files)
      •      
      • Another file (new) will access contacts records ( and modify them as needed)
      •      
      • Clients will need to submit a form requesting service (web based)
      •      
      • We will approve the request (or not)  and then promote the request to a new status (approved) at which point it becomes an active record in a table in the new file and we get to work organising.
      •      
      • We will need to somehow link client forms (requests) to preexisting contacts (automated) or if they are a new client, to create a new one (this could be manual off the form information).
      •      
      • Clients can not have access to any contact information that is not their own.
      •      
      • Clients should have access to only their own web based form record.

       So far I have thought of

             
      • A separate file for request form records- referenced (related) to the New file and the contacts file
      •      
      • Creating accounts via script in this separate file - linking (relating) client accounts to their own records and contact information scripturally using finds.
      •      
      • Or just having plenty of criteria to relate a client's form  to a contact record so their is low chance of error and then manually assigning the hitherto unrelated ones.

      Any advise gratefully received.

      Morgan

        • 1. Re: Design advice - Web based form submission
          philmodjunk

          There is no need for a separate file or even a separate table. There are a number of different ways to design the interface and use FileMaker's built in security to limit a user's access to only "their" data.

          On option is to use a set of fields with global storage specified to collect the user's input. If they click a button or check box to indicate that they are a returning customer, your system can pop up a search tool which, if it finds their record, copies their contact data over to the global fields so that they can review and edit it. When the user submits the data, this contact data is copied back into the contacts table--either into a newly created record for new customers or to the existing record found in the search for returning customers. Any data that is not part of that contact record--such as a request for service, can be put in a new record in a related table linked to the person's contact record for review. A status field in that record can record what has been done with that request.

          • 2. Re: Design advice - Web based form submission
            mchancevet@gmail.com

            Hi Phil thanks again,

            I like your global field concept. 

            However, some stakeholders with veto privileges on this project are exquisitely concerned with privacy and may be concerned that users could access contact details either deliberately (by entering in a name that is not their own) or accidentally if they have sufficient similarity in match criteria.

            Perhaps I need to learn more about FM13 security and get better at communicating about it.

            I had also considered generating user accounts with email address as the account name and get (UUID) as a calculation for generating passwords - this would be emailed to the client (from the server?) for access to the form to ensure the request is actually coming from the email account holder.

            I found the following recent post on email addresses as account names

            http://forums.filemaker.com/posts/aa1431345c#

            And this one on restricting access to records

            Record Level Access

            The following is a bit of a rant on effective consultation in development and  could be ignored by busy forum readers.

            My separate file concept is no doubt redundant but was conceptualized as a very obvious and visually demonstrable way of mollifying concerns about ‘backdoor access to data via the web’. This phrase gets bandied about a fair bit around here (my workplace) and was instrumental in terminating a very expensive, ill conceived and poorly researched/managed attempt to resolve many of our booking/client interaction problems. Unfortunately, throughout this process our institution (the primary users but non budget holders) were poorly consulted and multiple significant concerns remained unaddressed. When the project (a slow train wreck from our dismayed perspective at the time) unraveled we were left with our original systemic problems PLUS a managerial / institutional ‘bitter taste’ as regards attempts to address it and a somewhat exuberant institutional aversion to web based solution elements.

            I personally had a very instructive observation/lesson in development planning consultation deficiency from the perspective of the primary user of the solution.

            • 3. Re: Design advice - Web based form submission
              philmodjunk

              FileMaker certainly can function with multiple files--it was originally designed to function with only one table to a file and this multi-file capability has always been supported. I was just pointing out that it was unnecessary and that it doesn't really add much true security to the design since the data in this other file still has to be accessible to the first. One of the complications that arise from multiple files is that each file maintains its own accounts and passwords so setting up a new account requires creating an account with identical name and password in both files.

              It is possible to use a script--typically set to run with full access privileges that creates new accounts with an assigned password and specified privilege set. Such could be run from an EmailAddress entered into a text field and Get ( UUID ) can specify either their permanent or temporary password. And such a script can ensure that accounts with identical credentials are created in each file of a multi-file system.

              Only problem there is that the text of the UUID is very long for a password. But passwords need not be unique, only account names and you can assign an initial default password and require them to change the password the first time that they log in.