customField.update() not writing to history / activity log, what do I need to do?

[david-guild]

TLDR:

Need to do "something" so that CustomField.updateValue() will write out change logs to the history/activity tabs.

Background:

I have written a groovy framework to handle various post function tasks via a single post function call.  e.g.: Instead of several post functions, a single post function.

Most of the "tasks" center around updating / clearing different custom fields.  Most of these fields are visible to the user, but are not editable.

IssueService:  I originally implemented IssueService to carry out the DB write functions (via validateResults / .isValid() methodology).  Unfortunately, IssueService would not always write to the field due to the field not being "editable".

This behavior did not change even when I set the "user" to a service account with global admin privs.

I could not find a way, using Issue Service, to guarantee that a field got updated regardless of field level permissions.

CustomField.updateValue: This works great and puts in the various values regardless of whether the user can "edit" a customField.

Problem: CustomField.updateValue() does not write to the Activity/History logs. 

So, I am kind of stuck.  I really want to use IssueService as it feels like the correct implementation, but it's not reliable.  If I could fix that, great.

Or, I can use the CustomField.updateValue() if I can do something "else" that will force the activity / history log to reflect the changes.

Suggestions welcomed ....

Thanks in advance.

[Craig Haynal · Accepted solution]

Have you tried using IssueManager?  Its updateIssue() method will record the changes in history without all of the validation imposed by IssueService.

[david-guild]

Sorry I missed this message.  No, I have not tried IssueManager as I thought that was closely tied to IssueService. 

Is there anything, anywhere that describes the architecture and the differences between services such as this?

[Craig Haynal]

Unfortunately I'm not aware of an architecture summary.  The javadocs sometimes have comments explaining the intended use of these classes, but they mostly only useful as a reference.  All I can suggest is looking around the community and the web for related examples and referring to the javadocs as validation that an approach is valid (or to find out if its deprecated).  I do think IssueManager will likely be a good solution for your use case since it lies closer to the middle of the stack than the options you have pursued thus far.  Best of luck on your project!