Password Protected Editing

In this episode, we'll learn how to use Validation Rules in a Form Component to password protect editing.

Features Discussed:

1. Table Component (Time: 02:09)
   Learn how to import data into a data table using a CSV file. For example, mock medical records are used, but the process can be applied to any type of data. The user is shown how to browse for the CSV file, import it, and label it as "mock records."
2. Search Component (Time: 06:36)
   Learn how the focus is on creating a search field for IDs that requires exact matches, enhancing both usability and security.
3. Display Rules (Time: 09:56)
   Learn how the display rule is set up to show or require the record_unlock field when the Archive Record field is marked as "Yes". If not, the field remains hidden and not required.

Transcript Summary

Introduction

Hey everybody, and welcome to Build It with Tadabase. In this week's episode, we're talking about password protecting an edit form, specifically using validation rules to make sure that when you want to edit a particular field for a record, you can only do so if you enter the correct password.

Overview of the System

When we're finished with this build, we're going to have a system in place where we can search for records where we need to know a value. We're going to search for an exact match of that value, so we're only going to be able to see the records when we know that particular value and search by it. Once we find the record, we can edit that record. We'll have the ability to actually fill out some of the form fields. If I want to archive the record, then I'm going to need a password, and that password, in this case, is set to validate against a record value of the original ID. I need to enter that ID correctly to save this form with the archive field edited.

Setting Up the Data Table

Within Tadabase, there are lots of different ways to provide secured access to manage records within your application. You can do so using things like logged-in user roles and different page security options, but there are also more unique ways to do this.

We're going to have a bunch of records that are going to have two fields that we're going to compare. Field number one is going to be some sort of unique value, like a password, and the second field is going to be an inputted value that needs to match that first field.

Let's get started by adding our data table. For this, I'm going to import some mock data from a CSV, which we'll call "mock records" for now. The records I have are kind of like simulated medical records, but you can do this with anything. I'm going to browse for my CSV and import this table.

I have this ID field and this password field, which I'm not going to include in this case—I'm going to add that manually. Then we have these fake fields: diagnosis code, procedure code, and diagnosis description, which can all be text fields. That's totally fine. We're going to import this and bring in a thousand records that we can use inside our application.

I'm going to add this password field now. This will be field number two, the inputted field that we're going to use. Let's call this "record unlock," and this will be blank for now. As records are edited, this field will contain a value because it needs to match, in this case, this ID field. But for now, it's blank.

Let's add two more fields. These are going to be the editable fields. One will be editable by anybody, and the other field will only be editable when you actually know the password. That's going to be the one where you need to enter the correct value using validation rules to actually make changes.

The first field we'll call "provider note." This field will be editable, allowing you to add a note. The other field will be for archiving the record. If you want to archive the record, you'll need to input this value and pass the validation rules.

Building the Application Page

The whole point of this is that I'm not going to be logged into this application. While I recommend having logged-in users, defined user roles, and things of that nature, this is an extra layer of security. Someone who is logged in, say in this fake medical records example—maybe I'm a nurse practitioner, not a doctor—there are different levels within the medical field, and I am editing this record but not at the topmost level.

We're going to create a page and call it "app data" because, again, this is all kind of fake. It's going to be a table component that displays all our mock records from our data table. The fields I'm not going to include here are the ID—this is our hidden field that is a unique value for the record itself—and the "record unlock" field. We can include the "provider note," but we don't need to include "archive."

We're going to add an edit link to actually edit this record. We'll make a couple of changes here to spruce this up a little bit. We're going to show this in a pop-up and change it to a button.

Here's what this looks like. Again, I'm not logged in, and I can see all the records, which we're going to change in a moment. When I click on the edit record button, we have this pop-up window that also shows us all of the record information. We need to make a couple more changes here. Number one, we don't want to see all the records. We want to search for a record using this unique value that's hidden and only show the record when it matches that unique value. The edit form needs to be changed so that when we choose "archive," we're required to enter this password that has to match an existing field.

Adding Search Functionality

The first thing we're going to do is add a new row and a search component. We're going to search through the mock records table, link it to that table, and select "only load the table upon search." We're going to search the ID and make sure that we require it. In this case, we don't want to include all the operators. I'm going to leave it on "enable all" for now so I can show you the difference.

When we refresh the page, you'll see that the table component is now hidden. If I try to search anything like "is any," nothing appears. If I choose something like "contains" and put in a single letter, it's going to give us a bunch of results because the ID contains the letter K. In our case, we want it to be an exact match. We only want to find a record when it's an exact match to that ID. If I put in the letter K only for this one, there's no exact match where the ID is only K, so we won't get any results.

We can modify the search component further, specifically the ID field we're searching, to predefine what operators are available. We're going to choose "is," and that's going to be the only one available.

Now, when we go back and refresh, you'll see that this looks different. All we have is a text input, and every time we search, it will use the operator "is" to do an exact match.

This gives us one more layer of security, where the records aren't there until you actually search an exact match. That ID field is also not listed here, so it's under the assumption that you have this information in front of you, or somebody gives you that information, and you're looking up a record.

Editing the Record Form

Now we need to make changes to the actual edit form. We'll select our edit form back in the Page Builder and set up the form to be more user-friendly. We're going to show four fields—no, five fields—that we're going to make changes to, one of which will be locked.

We'll change the structure of this form a bit, with a two-column layout. On the left, we'll have the diagnosis code, procedure code, and diagnosis description fields set to read-only so that they cannot be edited. The field that anyone can edit will be the "provider note," and the field that requires a password will be "archive record." We also need to include the "record unlock" field, where someone will input the value to compare to an existing value.

We can clean this up further by using display rules. For example, if "archive record" is "yes," the "record unlock" field will be shown; otherwise, it will be hidden. We'll also require the "record unlock" field only when "archive record" is "yes."

Adding Validation Rules

To compare the inputted field to the existing field, we'll set up a validation rule. The rule will say, "Record unlock is not the record value of ID," and if it doesn't match, the error message will say "Incorrect admin password."

Inside validation rules, we can compare the inputted value of "record unlock" to different things. We can choose a custom value, another field on the form, or a record value like the ID. In this case, we're editing the record, so we're comparing the inputted value to the hidden record value of the ID.

Now that we're in a good place, we can test this. First, I have to search an exact match to find the record. Next, I can input a provider note and save it.

Final Adjustments and Testing

To address the issue where saving didn't work, we'll add a condition: if "archive record" is "yes" and "record unlock" is not the ID, we'll throw the error. We can now refresh and test again.

I can save the provider note, but if I select "yes" to archive, the display rule triggers and shows the "record unlock" field, which is required. If I put in a value that doesn't match the ID, it won't let us archive the record. If it matches, it will let us save the form.

Finally, we'll add a record rule to set the "record unlock" field back to blank after saving. This is useful if we change "archive record" to "lock record," requiring someone to compare the value to the ID field before locking.