Difference between Setting OwnerId and AssignRequest in Create Plugin
Today, I encountered a strange issue. The problem was that the record is just showing security access error page once the user saves the record. The record is still available in the list view but upon opening the record, it is just showing the security access error page. The record owner is set as the current user’s team in Pre-Create plugin and the security access of the entity is User Level for that entity so that I am wondering why the user cannot view the record even though the team of the user is the owner of the record (which is the same for other existing records that the user can view).
After figuring out from the error log and trying out with other users, it’s found that the BU of the user is configured incorrectly which was the root BU and different from the team. So, what happened to the record on create was the OwnerId was replaced with the team by Pre-Create plugin but the objectBusinessUnitId remains the same as the creating user which resulting in inconsistency between the OwnerId and the OwningBusinessUnit. So, by right, the record should be visible to the user because the user has “User Level” read access to the entity and the record owner is the user’s team but the read access failed when the OwningBusinessUnit is different from the user’s team BU.
I can’t justify whether it’s a bug or by design but it’s kind of weird to see the record in the list view but throwing “missing prvRead” error upon opening up the record. I have faced such kind of error when I update the owerid from SQL backend for the migrated data but I never thought saving one web service call of AssignRequest would cause same issue when we replace the OwnerId in Pre-Create plugin.
So, the lesson learnt is in order to avoid such inconsistency, either keep the business unit of the team and the member users under the same BU or just call AssignRequest in Post-Create plugin instead of replacing the OwnerId in Pre-Create plugin.
Hope my explanation of the scenario wouldn’t make you confuse. If so, feel free to leave in the comment.
After figuring out from the error log and trying out with other users, it’s found that the BU of the user is configured incorrectly which was the root BU and different from the team. So, what happened to the record on create was the OwnerId was replaced with the team by Pre-Create plugin but the objectBusinessUnitId remains the same as the creating user which resulting in inconsistency between the OwnerId and the OwningBusinessUnit. So, by right, the record should be visible to the user because the user has “User Level” read access to the entity and the record owner is the user’s team but the read access failed when the OwningBusinessUnit is different from the user’s team BU.
I can’t justify whether it’s a bug or by design but it’s kind of weird to see the record in the list view but throwing “missing prvRead” error upon opening up the record. I have faced such kind of error when I update the owerid from SQL backend for the migrated data but I never thought saving one web service call of AssignRequest would cause same issue when we replace the OwnerId in Pre-Create plugin.
So, the lesson learnt is in order to avoid such inconsistency, either keep the business unit of the team and the member users under the same BU or just call AssignRequest in Post-Create plugin instead of replacing the OwnerId in Pre-Create plugin.
Hope my explanation of the scenario wouldn’t make you confuse. If so, feel free to leave in the comment.
Comments
Post a Comment