This section describes some advanced concepts about how Access Control is implemented. If you are curious about how Access Control works, this section can help explain how things behave in an Access Control environment.
aPriori implemented Access Control so that it works securely in an unobtrusive manner, adhering to the following principles of which the first four are always true
-
You cannot grant yourself new permissions because of updating an entity. For example, you cannot change the value of an attribute to give yourself update rights if you did not have those rights already.
-
You cannot give away permissions you had because of updating an entity. For example, if you had Read Update rights, you cannot change the value of an attribute so that you cannot read or update it anymore.
-
Fail fast when possible: For example, in order to load a BOM, you must to be able either to create and read and/or update the parent rollup and possibly any functional group rollups. aPriori checks these conditions first and fails immediately if it finds a problem before starting the BOM load operation.
-
Check before destroy: aPriori checks access control permissions before deleting data. For example, by using File > Import to import scenarios from a .ap file deletes any existing scenarios that conflict with the ones being imported. Before deletion, aPriori verifies that the importing user has the necessary permissions for the entire import to succeed.
One of the following rules apply, depending on the situation:
-
Keep going and notify: When the initial "fail fast" checks for operations that involve manipulation of multiple scenarios are done, aPriori skips over scenarios that fail because of Access Control but logs the issue and notifies the user. For example, after the initial check for rollups, the BOM loader loads everything it can and notes any access control failures.
-
Abort the entire operation: If any part of an Update operation fails due to access control, the entire operation is aborted and aPriori attempts to remove any scenarios created up to that point. For example, Scenario > Save As > Scenario & Children could fail an access control check after already processing some number of scenarios. In this case, aPriori stops the save and cleans up any scenarios that were created. Spreadsheet reports work in the same manner, except that there is no need to clean up.
Note: Fail fast when possible does not apply in this situation for performance reasons. It would not be efficient to visit each scenario to check if all permissions are okay before performing the save operations.