I have few observations from this lesson hope the forum might be able to help me understand these concepts.
As per lesson it was mentioned ABAC is more granular and applies restriction with row and column based checks.
for me row is a workobject or data object instance and column is a exposed property in a table mapped to object.
so in this example scenario we are verifying if the user belongs to HR or recruitment department and also checking if the create operator value is present in record.
however when I tested the table it is abstract in nature.
TGB-HRApps-Data-Candidate–Abstract.
if that is case how did policy condition allowed us to use pxcreateoperator in its configuration.
second it also made me think when is it best to maintain abstract class and concreate class in system and in which layer would make it more flexible.
generally in my thoughts i prefer keeping abstract class a)in frame works to support inheritance
b)In integration layer to support mapping.
however i see in implementation layer also do we keep abstract class if so what is the rationality or logic of deciding that factor.
Note: one size doesn’t fit all as one solution doesn’t fit all, the reason for asking this question is to understand the design behind this HR data layer design.
pxCreateOperator is defined in @baseclass so is inherited by every other class.
An ABAC rule can be used to prevent display of information within a data class regardless whether the data class is abstract or concrete. The PropertyRead access policy type would be used.
If this were not the case there would be an easy way to see the information even if the data class was concrete. All you would need to do is embedded a field group having that class.
Perhaps you are referring to the Discover access with regard to concrete data, which includes cases?
You point about abstract vs concrete is well made.
It would make perfect sense to persist each Candidate in its own table, not in a case BLOB which then requires the various properties in the Candidate class to be exposed in the work pool table.
Instead TGB-HRApps-Data-Candidate should extend PegaData-Contact and be persisted in the CustomerData schema.
The case would possess both a CandidateID property and a CandidateRef page, the latter using the former to retrieve the Candidate by way of a Data Page Lookup.
If the Candidate is not already persisted, there are ways to persist the record to the CustomerData schema.
Persisting the Candidates in their own table also supports auto-complete searching against a List Data Page.
