Address Book Data Privacy (P01138) - FAQ

Purpose

 This document answers sone frequently asked questions on JD Edwards EnterpriseOne Address Book Data Privacy.

Questions and Answers

Question 1: What setting should be checked if Address Book Data Privacy functionality is not working?

Answer 1: These are some helpful hints, things to watch out for, or considerations when troubleshooting or implementing Address Book (AB) Data Privacy. Remember to:

• Enable the data privacy option in AB Constants (P0000) when implementing.
• Set up data permission records and create the relationships for the user ID/role you would like to secure.
• Create a Permission List that includes the *PUBLIC role that sets up the default desired security for all users. You can then create more lax or heavier security for specific users/roles. If you do not have a default permission list using the *PUBLIC role, then no security will be used (which is the default for all users). Please note that to find the *PUBLIC role in Create and Maintain Permission Lists (P95922), you must search using only the asterisk as a wildcard. If the *PUBLIC is not assigned to any other list, it should be the first option returned.
• Add mode is not secured.
• Copy mode will blank out those items with security settings.
• The security setting for Phones and E-mail Addresses is an 'All or Nothing' option.
• This is a Web-only solution.
• Setup tables (F0009, F01138 and F95922) are included in System Cache Tables list (F98613).

Question 2: Is it possible to associate the same User to more than one Permission List?

Answer 2: Permission List Relationships only allow one user to be tied to one permission list. To have multiple permission lists apply to one User ID, it is possible to set up Roles. A user can be associated with multiple roles and each role can be associated with a permission list. Another option is to set up several Permission Lists, each for a different Search Type but with the same Permission List Name. Be aware that same name permission lists share the same permission list relationships (users/roles). When setting up multiple permission lists with the same Name, you will get a warning, and just need to click OK to bypass it.

Question 3: We have created a Permission list definition in P01138 and cannot find it in Permission List Relationship P95922 in order to assign it to specific userIDs/roles.

Answer 3: Please follow these instructions:

1. In Work With Permission List Definitions (P01138), create a Permission List (or select one that you have previously created)
2. Take the Row exit to Perm List Rel, find the users or roles that should be secured out, and click the arrow to bring them over to your permission list
3. Close out of the Maintain Permission List Relationships screen, do a Find, and click the radio button next to your Permission List
4. Take the Form exit to Perm List Rel, and do a Find. Your Permission List should be there and can be selected for editing.

Question 4: What are the checkboxes on the User Defined tab of Add/Edit Permission List (P01138)?

Answer 4: With a little additional work, you may be able to use these fields as part of Address Book Security. According to JD Edwards EnterpriseOne Tools Security Administration Guide, there is a Note that states: "In addition to these fields, the system enables you to designate up to eight other user-defined fields as secured. Included in the eight fields are: five string, one math numeric, one character, and one date type. To secure additional fields, you must modify the parameter list in the call to the business function B0100095. For example, if you want to designate Industry Class as a secured field, you must modify the call to the B0100095 business function to map Industry Class in the parameter list."

In P01012, form W01012B, Write Grid Line-After event, B0100095 is called to secure the fields, if a new user field is in the grid and needs to be secured you will need to modify the parameter list in the call to the business function B0100095:

1. Open P01012 in FDA.
2. Go to Write Grid Line-After event of W01012B form.
3. Double click on the bsfn named "Secure Address Book Personal Data" (B0100095).
4. Look at Data Item in the right, find UserDefinedString1 to 5, UserDefinedDate, UserDefinedMath and UserDefinedChar 8 fields and map desired field to one of the UserDefinedString. Currently, you can see TaxID and AddressLine 1 etc. are mapped as an example.

For other applications that display the user field, open the app in FDA, and either find the event rule that call B0100095 or add event rule to call B0100095 and map the user field to one of the user defined string in the parameter list. The user defined fields can be enabled using P01138 the same way as Tax ID but you must complete the extra step of mapping the bsfn parameter in FDA.

Question 5: Is it possible to utilize security for *PUBLIC as well as security for a specific role/user for different search types? 

Answer 5: Unfortunately, this is a limitation of security. When the runtime engine selects these records, it only considers the lowest level of input. If a security record exists at the User level, then the records for Role and *PUBLIC are ignored. Therefore, do not try to setup security combining logic from user, role and *PUBLIC records. If a user is assigned a role, then security for each search type should be set up for that specific role. The *PUBLIC records are not going to be used.

Question 6: If setting up data privacy for a user, would that have any influence when the user attempts to run a query directly over the database?

Answer 6: The address book data privacy would not have any affect when directly querying over the database is because P01012 calls business function SecureAddressBookPersonalData B0100095 which verifies if there is any data privacy set up for the user making the search in P01012 application.  A simple select directly over the F0101 table would not call the business function to verify if there is a data privacy security set up.

Question 7: Why does the Word Search (P01BDWRD) return no records when using Address Book Data Privacy?

Answer 7: This issue is functioning as designed. If ANY of the available fields are secured,P01BDWRD will hide the grid row.  Because this form searches over all the personal fields in the AB files. From application level it can't determine what type of data they are searching for, so if any of the fields are secured, it will not show the record.

Question 8: After setting up the data privacy for TaxID thru In Work With Permission List Definitions (P01138) and applied to a role, user cannot edit the Search Type field(Alias: AT1) in Address Book revision(P01012). Why ?

Answer 8: This is functioning as per design, a user should not be able to change the Search Type in Address Book revision(P01012) for Search Types he/she is secured out of.
If user can change the Search Type, data privacy can very easily be bypassed, that is, if secured user changes the search type to something which is not secured, the secured data would be displayed.
This function was implemented by Bug 17060531 - DATA PRIVACY ISSUE