aaApi_CopyDocument2 and permissions

We have a tool that was originally developed by Brian Flaherty at Bentley that basically clones a folder tree from one datasource to another.  (It's pretty cool.)  It gets submitted as a batch process on a dedicated desktop.  I recently had to reconfigure a few things on the batch processor and ran into an issue that confuses me. 

The tool takes both a Source and Target datasource, user account, and encrypted password; as well as the Source folder to be copied and the Target folder where the project copy lands.  We were using the pwadmin "God" account for this, but a recent management philosophical change forced me to create a separate service account.  I put this account in the Administrator group in all of the relevant datasources.  But it would fail executing aaApi_CopyDocument2 for every document.  It wasn't until I unchecked "Use access control" for that account that it would copy the documents.

Is this expected?  Is there another way to let this work?  I've always thought unchecking that was potentially risky and to be avoided.

Parents
  • , It depends upon what you mean by "is this expected?".

    What I suspect that Brian expected was that the accounts being used would have "full" access to the objects that they are trying to manipulate.  By disabling access control then security isn't checked when accessing the various objects.

    If the two account involved (source and target accounts) are only used by a "service account" and are never used by an actual user (and have passwords that are either unknown or at least difficult to guess), then "what's the harm" in disabling access control for those accounts?

    An alternative to disabling access control would be to setup security on the objects involved so that anything that the source account needs to access in the source datasource, it has access to.  And of course, similar for the account used for the target datasource, that account needs to be able to create, modify, and possibly delete objects.

    One more thing to consider that is related but is sometimes overlooked - a user's "right" to do something.  Even with access control disabled, if a user does not have the "right" to create, modify, or delete the objects being manipulated, then the "permissions" on those objects will not matter.

    One other reason to disable access control for at least the target datasource user is that you don't have to remember (or ensure) that all the objects that the user needs access to have security set in a way that the user can do the desired tasks.

    You might want to take a look at the "Greenbook on ProjectWise Security" found here:  https://communities.bentley.com/products/projectwise/content_management/w/wiki/5448/greenbook---best-practices to learn more about how ProjectWise security works.

Reply
  • , It depends upon what you mean by "is this expected?".

    What I suspect that Brian expected was that the accounts being used would have "full" access to the objects that they are trying to manipulate.  By disabling access control then security isn't checked when accessing the various objects.

    If the two account involved (source and target accounts) are only used by a "service account" and are never used by an actual user (and have passwords that are either unknown or at least difficult to guess), then "what's the harm" in disabling access control for those accounts?

    An alternative to disabling access control would be to setup security on the objects involved so that anything that the source account needs to access in the source datasource, it has access to.  And of course, similar for the account used for the target datasource, that account needs to be able to create, modify, and possibly delete objects.

    One more thing to consider that is related but is sometimes overlooked - a user's "right" to do something.  Even with access control disabled, if a user does not have the "right" to create, modify, or delete the objects being manipulated, then the "permissions" on those objects will not matter.

    One other reason to disable access control for at least the target datasource user is that you don't have to remember (or ensure) that all the objects that the user needs access to have security set in a way that the user can do the desired tasks.

    You might want to take a look at the "Greenbook on ProjectWise Security" found here:  https://communities.bentley.com/products/projectwise/content_management/w/wiki/5448/greenbook---best-practices to learn more about how ProjectWise security works.

Children
No Data