Message-ID: <1295164042.16010.1711714736651.JavaMail.appbox@confluence> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_16009_1366033427.1711714736650" ------=_Part_16009_1366033427.1711714736650 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html Problem uploading an issue that has required fields

Problem uploading an issue that has required fields

You may experience some problems working with issues, which have= required fields or fields, which only accept certain values. This may be t= he result of the workflow actions upload mechanism implementation.

=20

For example, when you make a workflow change =E2=80=93 all changes withi= n this workflow action are treated as one big change (including the field v= alues changes). If you make two workflow changes without upload between the= m =E2=80=93 they will be saved as two big changes, and once you start uploa= ding them, at first JIRA Client will try to upload the first, and then the = second.

=20

So, if in the first workflow action you set field =E2=80=9CX=E2=80=9D to= 1 and then in the second you set the same field to 2, once you start uploa= ding, at first it will be set to 1 when the first workflow action will be u= ploaded, and then to 2, with the second. This is useful in some situations = =E2=80=93 for example, when you have no internet connection and need to do = some complicated action =E2=80=93 like moving a sub-task from one project t= o another. First you have to change issue type, then do the move, then chan= ge the issue type again =E2=80=93 all these three actions will be done one = by one once you try to upload them.

=20

In some cases it may cause a problem. For example, you try to do the wor= kflow action, but there is a problem there (missing or incorrect required f= ield), so it doesn=E2=80=99t go through. Then you provide the missing (or c= orrect) values and try to upload again. What happens, JIRA Client treats th= ese actions as two successive changes. First it tries to upload the workflo= w action again with its own changes (and missing or incorrect values), whic= h fails because the fields are missing. So it doesn't get to the second cha= nge, which has the correct values.

=20

You can switch this mechanism off and make JIRA Client treat successive = changes as one big change and only upload the latest values. To do that, yo= u can add a parameter to the System Properties:

=20

upload.finalstatemode=3Dtrue

=20

This parameter will also work for Move in the new version of JIRA Client= .

------=_Part_16009_1366033427.1711714736650--