JJUPIN sil post function sets custom fields which are invisible in the field configuration and on no screen

[onkeldom]

Hi all of you out there,

as the topic already tells you, I've got a slight - not yet fatal - problem with some simple post functions written in sil. These post functions used in our Human Resources project do some plain simple "copy/paste" stuff with slight alteration of the data, for example:

// Copies the values of From (d/h) and To (d/h) into From and To while chopping the time value
if ( issueType == "Absence" || ( issueType == "Health Related" && customfield_14000 == "Arztbesuch / Visit the doctor" ) ) {
    customfield_12700 = chop(customfield_10425,10);
    customfield_12701 = chop(customfield_10426,10);
}

just copies to date-time values into corresponding simple date fields, while chopping the time value off.

Or like this one:

if ( issueType == "Holiday Work" ) {
    if ( userInGroup("jira-users", customfield_12003) || userInGroup("jira-external-grp", customfield_12003) ) {
        summary = "Feiertagsarbeit von " + userFullName(customfield_12003);
    }
    else {
        summary = "Holiday work of " + userFullName(customfield_12003);        
    }
}

if ( issueType == "Weekend Work" ) {
    if ( userInGroup("jira-users", customfield_12003) || userInGroup("jira-external-grp", customfield_12003) ) {
        summary = "Wochenendarbeit von " + userFullName(customfield_12003);
    }
    else {
        summary = "Weekend work of " + userFullName(customfield_12003);        
    }
}

if ( issueType == "Vacation" ) {
    if ( userInGroup("jira-users", customfield_12003) || userInGroup("jira-external-grp", customfield_12003) ) {
        summary = "Urlaub von " + userFullName(customfield_12003);
    }
    else {
        summary = "Vacation of " + userFullName(customfield_12003);        
    }
}

if ( issueType == "Absence" ) {
    if ( userInGroup("jira-users", customfield_12003) || userInGroup("jira-external-grp", customfield_12003) ) {
        summary = "Abwesenheit von " + userFullName(customfield_12003) + " vom " + formatDate(parseDate("yyyy-MM-dd HH:mm", customfield_10425),"dd.MM.yyyy 'ab' HH:mm 'Uhr'") + " bis " + formatDate(parseDate("yyyy-MM-dd HH:mm", customfield_10426),"dd.MM.yyyy 'um' HH:mm 'Uhr'");
    }
    else {
        summary = "Absence of " + userFullName(customfield_12003) + " from " + formatDate(parseDate("yyyy-MM-dd HH:mm", customfield_10425),"dd MMM yy HH:mm") + " until " + formatDate(parseDate("yyyy-MM-dd HH:mm", customfield_10426),"dd MMM yy HH:mm");
    }
}

if ( issueType == "Health Related" ) {
    if ( customfield_14200 == "Krankmeldung / Sick note") {
        if ( userInGroup("jira-users", customfield_12003) ) {
            summary = "Krankmeldung von " + userFullName(customfield_12003);
        }
        else {
            summary = "Sick note of " + userFullName(customfield_12003);
        }                
    }
    else {
        if ( userInGroup("jira-users", customfield_12003) ) {
            summary = "Abwesenheit von " + userFullName(customfield_12003) + " vom " + formatDate(parseDate("yyyy-MM-dd HH:mm", customfield_10425),"dd.MM.yyyy 'ab' HH:mm 'Uhr'") + " bis " + formatDate(parseDate("yyyy-MM-dd HH:mm", customfield_10426),"dd.MM.yyyy 'um' HH:mm 'Uhr'");
        }
        else {
            summary = "Absence of " + userFullName(customfield_12003) + " from " + formatDate(parseDate("yyyy-MM-dd HH:mm", customfield_10425),"dd MMM yy HH:mm") + " until " + formatDate(parseDate("yyyy-MM-dd HH:mm", customfield_10426),"dd MMM yy HH:mm");
        }        
    }
}

which sets the summary according to the issuetype, the date-time and a user selected.

They are executed one after another and all of them specifically after the issue itself is created.

Strangely after everything runs through (without any errors), a bunch of custom fields, which are set to "not visibile" in all project field configurations and are not even present on any of the screens used in the project, are updated ass well. Those CF are not mentioned in any of my sil scripts.

Any ideas, what's the problem here?

Cheers,

Dom

[onkeldom · Accepted solution]

OK, sadly the guys from KEPLER ROMINFO (HUGE thanks for all your support/help via email!) did not paste the answer they gave me in here, I'll do it myself - just in case anyone else stumbles upon the same problem.

The behaviour described has its origin in a sil validator I used during the transitions. This validator did not change anything (just checking some fields), but since it relies on some more or less faulty JIRA API routines and copies the issue to perform those checks, it seems to have these side-effects.

Here's the original answer coming from Radu Dumitriu (KEPLER-ROMINFO):

Hi Dominic,

...

Moving to the technical details of it:

You remember that in validators / conditions / postfunctions we're using a copy of the issue, and not the issue itself. For validators / conditions the class responsible is this one: http://confluence.kepler-rominfo.com/javadoc/katl-commons/2.6.7/com/keplerrominfo/jira/commons/ivm/ReadonlyIssueVariableResolver.html

For postfunctions: http://confluence.kepler-rominfo.com/javadoc/katl-commons/2.6.7/com/keplerrominfo/jira/commons/ivm/DefaultIssueVariableResolver.html

This allows us to avoid saving the issue if script fails and to avoid changes in conditions, for instance.

Now: the problem arise at the copy-in. We're relying on some JIRA API routines which seems not to care if we do not do the save, plus (this is the bonus) some get* routines that have, it seems, side-effects (!). That means that we need to avoid / postpone calling them, and this is why I advised Florin to tell you that we'll address them in SIL 3.0, since I'm afraid to change too extensively this part in a short time (too sensitive, more tests are needed here).

Thanks for the patience (and sorry for the inconvenience it may have caused),

Radu Dumitriu

Again, thank you - KEPLER ROMINFO team - for your marvelous support.

[Rina Nir (AC)]

Hello Dominic,

1) I do not know what could be the cause of this. I can just confirm that I have similar post-functions and haven't had such an issue. On the other side, I know that the guys at Kepler Rominfo arevery responsive to email questions (jira-support@kepler-rominfo.com) then they are to the questions here- so it might be good to send them a query.

2) Looking at your code I could not help notice that you are using "bare" customfield IDs and not taking advantage of SIL aliases. You should definetly have a look at SIL aliases because not only will it render your installation moe portable, it will also make your code much more redable. Have a look here: http://confluence.kepler-rominfo.com/display/SIL/JIRA+instance-independent+programming

Rina

[Florin Manaila]

Short disclaimer: If the questions are tagged using the plugin-specific tag, we get email notifications so we respond here asap as well. Otherwise it's just a matter of coincidence that we stumble upon questions like this (like I just did) :)

[Rina Nir (AC)]

Well noted!

However- the tag to use in order to get to the right support is not always very obvious when you post a question...

[onkeldom]

Hi Rina,

thanks for the tip. I've contacted customer support ... we'll see what they have to say about that.

Thanks again for the hint considering aliases ... I should really use them, you're absolutely right.

Cheers,

Dom

[onkeldom]

Some short additional informations:

• The post functions are used within the initial transition CREATE -> OPEN
• The behaviour does not occur, when the first status is set to something different than OPEN ... maybe because of the additional post-function "Set issue status to the linked status of the destination workflow step" found there?!?

Seems really strange. I'll investigate a bit longer. If there is no other way or a better solution coming from one of you guys, I guess I'm just changing the first status after CREATE to something different than OPEN.

Still, this behaviour seems like a bug to me ...

[Florin Manaila]

That first step behavior is indeed strange. There shouldn't be anything special about the Open status. Does this only happen if there are SIL post-functions on the transition? Could you maybe remove the SIL post-functions (remove them altogether not just comment out the code) and see if this still happens? Just create a copy of the workflow and use that one for this test so you can revert back to the original.

As I said via email, it would help to know the types of the custom fields that get updated so we can try to reproduce it. Oh, and JIRA version as well.

[onkeldom]

Forgot to mention it in the Mail:

JIRA version 6.2.6 and all other projects / workflows don't show that behaviour. As soon as I add a sil post function the way I described in my main post, the problems occur.