Posting this here as well (was originally in the WorkView group) in hopes of catching the attention of anyone who might be able to shed some light on the issue:
Hello,
I've run up against a possibly application-breaking issue in OnBase 18. We have a WorkView class called Employee which holds employee data (as you might expect). A Unity Script runs on a schedule via the Unity Scheduler to check an external system for new employees as they are added to said external system. If the script sees an employee that does not yet exist in the WorkView class table, it creates a record for that employee and pulls in relevant data.
There are a lot of fields that we use exclusively in OnBase and that need to be read/write and/or used as fixed constraints as well as other features that are verboten for external class objects, so configuring this as an external class with a live look at the external data is NOT an option here.
All of that being said, here is the current issue:
In v17, this script ran flawlessly - reading data from the DB into variables in the code. The code then creates a new WorkView object via the Hyland.Unity.WorkView.Class CreateObject() method - the documentation for which states that the default function is for the newly created object to be activated once the attributes are saved.
The code then uses the newly created object to create a Hyland.Unity.WorkView.AttributeValueModifier object which reads the values from the variables and runs ApplyChanges() once those values have been modified using the SetAttributeValue([attribute], [value]) method.
However, in v18, I'm getting errors in diagnostics stating that the account executing the code (our service account, since that is what is needed for the Unity Scheduler) does not have rights to modify the object. I am guessing this is a security attribute issue as we do have security attributes configured for that class which prevent anyone but system administrators and employees viewing their own records from modifying/saving changes.
Oddly enough, the "create" permission seems to be just fine for the service account as there are now a bunch of recently-created, inactive objects in the DB with no attribute values.
This was never an issue for us before and the security attribute settings were configured back when we were still running 17, at which time the script worked just fine.
My guess is that something changed with the way the security attributes and/or service accounts function which is preventing the code from executing correctly. This is a major issue for us as there is NO way to modify security attribute settings for a specific account (that I can find) and there is also NO way to add a service account to a user group (such as our administrative one) that would have rights to modify the object via the security attribute configuration.
I'm at a loss as to how to proceed and would really appreciate some input from anyone who has run into this issue themselves or any Hyland folks who could possibly shed some more light on the issue.
Sincerely,
Adam
