Define permissions and sample data

It's worth noting that you actually have a choice here. Defining the permission model up-front is technically more efficient because you can assign Permission Roles to individual records, fields, views, and processes in a single pass as you build them out. However, it's also true that as long as you are willing to test your application only as an Administrator, then you could always postpone setting up roles and Functional Roles until after the application is developed. So, if you skip this part of the tutorial for now, that's fine but do remember that it will not be enabled for other users until you come back and revisit this topic.

That being said, assuming you want to set up permissions at the beginning, let's dive in. Recall the access control model we determined we needed during analysis:

This consists of setting up permission roles and functional roles as part of the application, and also creating (or importing) some sample test data. As mentioned previously, you can choose to skip this lesson for now, but this means that your application will only be able to be run by someone with Administrator permission. You can always choose to do this later and revisit your definitions to apply permissions when ready to do multi-user testing.

Create permission roles

Let's do this first, since functional roles need to be mapped to these.

1. Go to the Administration area of BMC Helix Innovation Studio.
2. In the Settings list, go to Configure My Server → Application Permissions → Manage Role Permissions.
3. Click New.
4. Specify the properties for an Order Submitter role as described in the preceding logical model.
   1. Application Name - this must match the application ID that was set when you first created the application (it is generally in the format developerid.application-short-name). If you used the install package to catch up, it will be Lunch Tutorial.
   2. Role Name - Order Submitter
   3. Role ID - you can specify any id as long as it is negative, unique, and in a very large range as it will prompt you. For more complex applications you should think about what kind of system to use to maintain these.
   4. Group Mapping - you can leave these blank, since we are going to map these Permission Roles to  Person via Functional Roles.
   5. Save it.
5. Repeat for Restaurant Manager.
   

Functional roles

Although our permission roles can be specified for our definitions, as mentioned above, they can't be mapped directly to our test users. That's what the functional roles are for.

1. Go to the Administration area of BMC Helix Innovation Studio.
2. In the Settings list, go to Configure My Server → Application Permissions → Manage Functional Roles.
3. Click New.
4. Specify the properties for Meal Program Member
   1. Application Name - same as used above.
   2. Functional Role Name - Meal Program Member.
   3. Description - up to you.
   4. Selected Role - this is where you map the permission roles for this functional role.  
      1. Search for Order Submitter and select it.
      2. Also add AR Foundation Person Read.
   5. Save.
5. Repeat to complete all the mappings needed according to the diagram: Meal Program Administrator and Meal Program Manager.

Test yourself:  why do we need to map the Permission Role for Person Read for this particular application?

When you are done, the Functional Roles list should look like this, matching our diagram.

Import Test Data

The application's access control model is complete, but for any kind of testing, you will also need Person and Primary Organization records. You can create these manually, or as a short-cut, you can use the Data Management Console to import them from the provided for this tutorial.

Get and unzip the data spreadsheets found in Tutorial Foundation Sample Data.zip. You should now have the following three files:

• 01-Tutorial Organization Data.xlsx
• 02-Tutorial Person Data.xlsx
• 03-Tutorial Person Associations.xlsx

The use of the Data Management Console is fully described in Loading foundation data in bulk. The important thing to remember is that each spreadsheet should be loaded in the order shown above (associations last).

If you see the Data Load Result as Processed, refresh the list of Employee records to see if they have been imported properly (if the status is not Processed, you can download a spreadsheet containing the error codes)

Sometimes, even if the status is Processed, there still could have been errors on a particular row basis. One common reason is when the create operation specified in the spreadsheet is specified repeatedly, those rows might error out. Also, when you import an operating organization, a group is automatically created based on a a group ID in the spreadsheet. You may need to manually delete this permission group in order to retry, and then you will have to re-import all subsequent data that depends on it as well.

If you did not use the Data Management Console, you will need to manually associate the employees to the operating organization.

Assign functional roles

Now that you have some employees, you can assign them the functional roles called for in our design. To map a functional role, find the Employee record in the Administration area, and use the Functional Roles picker. 

Repeat this as needed to make the test data match our access control diagram. For example, Maria would be given the Meal Program Member functional role.

What we Learned

There are quite a few useful things you have now tried out.

• Prepared the permission roles so you can use these while creating the definitions in a single pass (otherwise, you would have to go back and apply them after development).
• Learned about functional roles, which is a great way to bind specific users to permissions, and even works across Applications and Libraries.
• You learned about the Data Management Console, an out-of-the-box Application that provides nice way of importing Foundation data.
• You used the built-in Foundation data editors to assign functional roles to person records (in this case, employees).