Try Delete Root node but edit authorization for sub node needed

[Former Member]

Hello,

i try to the delete a BO instance. For that the user need the delete authorization (Activity = 06).

For the root note the check will be executed with activity '06' and for the subnode with activity = '02' (Edit).

But i dont want give the user the "Edit" authoriztion.

How can i switch the check for that use case? Why does BOBF check agains "Edit" and not "Delete"?

It is a "Business Process Object" which have a super object. We redefine something on root node and re-use the sub node.

Kind regards

Christian Scheffel

[ivo_vollrath]

Hi Christian,

I do not know any reason why BOPF should check for EDIT authority on a subnode when deleting the parent instance. I made a quick check with a test BO in BOBT: I debugged the deletion of a ROOT instance with a single ITEM and I did not observe an authority check for activity EDIT. I just saw two authority checks for DELETE ('06') for the ROOT and ITEM node, respectively.

However, I did not test an extended BO.

Please analyze the call stack leading to the unexpected authority check. Is there any BO-specific logic involved which does not belong to the BOPF framework? Otherwise feel free to open an incident, so we can analyze your situation.

Kind Regards,

Ivo

[ivo_vollrath]

Hi Christian,

now I understand: My test BO had "own checks" configured on every node. Your BO only has authority checks on the ROOT node. When deleting the ROOT node, BOPF recursively deletes all items. BOPF also recursively checks for authorization to delete all items. Since the items do not have their own authority checks, the check is done on the ROOT node. However, deleting an ITEM semantically means to change the BO within the ROOT scope. Therefore, you need EDIT authorization on the ROOT node in order to DELETE an item.

Adjusting this behavior would be dangerous as it might be an incompatible change for some applications. We have not received other reports complaining about this. Therefore, I assume that it is not a very realistic use case to have DELETE authorization without EDIT authorization. Therefore, we would rather not change this behavior.

Kind Regards,

Ivo

[former_member190794]

Hello Christian,

a node that has an authority class maintained is defined as "authority node". All nodes that are subnode (and subsubnode and so on) of this "authority node", but do not have an own authority check class, are part of his "authority group".

The behavior is like that:

If you delete an instance of the "authority node" there will be a check for DELETE 06 for its authority implementation class. However if you delete a node of his "authority group", there will be a check on UPDATE instead.

To solve your issue you have thus two options:

(a) Make the node you would like to get the DELETE check an "authority node" by maintaining an own authority class and implement the check there.

(b) Use the BeforeImage in the check implementation to distinguish between an update or delete case, as soon as a check for UPDATE is requested.

Best regards

Tilmann