Modifying Keywords with custom Unity API applications work arounds

[Anthony_Boyd]

Hi,

I just ran across an issue with one of our custom Unity API applications that does keyword modifications.  I found the cause of this issue explained in the blog post "Modifying Keywords through the Unity API in OnBase 16" and saw the change that was being made to address this issue from within workflow with Unity Scripts but I'm trying to see what work around (if any) can be used for external API applications.  The quick fix would be to grant the modify keyword permission but in doing so would also allow users to modify the keywords (any keywords on the doc type) from within any client as well since they also have access and needs to retrieve these documents from within the OnBase client(s).  This custom application allows keyword modification in a controlled setting so they are only able to modify specific keywords.  Just trying to get some other ideas/thoughs if someone else has ran into similiar issues.

Thanks

Anthony

[Chris_Tucker]

We realize that this is a frustrating situation, and are actively looking into allowing security overrides. Since this enhancement involves elevating privileges, extra care has to be taken with its design and implementation to prevent introducing any security vulnerabilities. If you are interested in this feature, please contact your first line of support to be added to the SCR mentioned in Tyler's post. Your business cases will be used to help design this feature to meet everybody's needs.

I'd also like to add that the loss of history can be partially mitigated by adding a custom log message through LogManagement.CreateDocumentHistoryItem(). The message will appear in the document's transaction log, and can state that the current user is doing work on behalf of another user within an API application.

[Alex_French]

It looks like my first comment didn't make it... or now the second attempt to comment... so I'll try again...

I think I do understand Application Identities as currently implemented. They allow a layer of configuration to prevent outdated, malicious, or just uncontrolled use of the API.

But you don't have to setup their usage at all (so they don't break existing setups), and the current implementation doesn't enforce any different kinds of security after the connection is created.

I would suggest that a sensible way to close the previous security gap would be to allow external API a way to easily-but-intentionally override keyword modification privileges, *if and only if * the connection is made using an Application Identity, and maybe only if that Application Identity has a specific configuration choice to allow the override.

This would put individual installations in control, secure but configurable, compared to what I understand was implemented in 16, or the limited fix that I've heard about that will only affect some types of Unity scripts.

We will get in touch with Team M to be added to the SCR and make these suggestions. Thanks for suggesting that Tyler.

[Mike_Saville]

John's option is totally doable and would work. Just be aware that the "user" that modifies the keywords according to the document history would be the user you connect with via the API vs. the actual user who used the application.

[Prakash_Shanmug]

Just find the keyword that needed to be updated from application core

KeywordType keywordType = core.KeywordTypes.Find("Invoice #");

 // Create keyword modifier object to hold keyword changes

KeywordModifier keywordModifier = unityDocument.CreateKeywordModifier();

//Create a New Keyword

Hyland.Unity.Keyword newKeyword;

newKeyword = keywordType.CreateKeyword("1234");

//Get keyword record                          

KeywordRecord keywordRecord = unityDocument.KeywordRecords.Find(keywordType);

if (keywordRecord != null)

{

Hyland.Unity.Keyword oldKeyword = keywordRecord.Keywords.Find(keywordType);

keywordModifier.UpdateKeyword(oldKeyword, newKeyword);

}

keywordModifier.ApplyChanges();

these steps to modify Keyword works for me in OnBase16.