Jira Database Custom Fields get silently populated when other fields are updated. Bug or feature?

[Monika Danielsson]

My setup: three JIRA Database Custom Fields, from three tables, A, B and C. A contains an id, B contains one row for each A-id, with a unique B-id, and C contains 1 or more rows for each A-id, with different strings. 

• Afield: defined by "select aid from A". "None" allowed.
• Bfield: defined by "select bid from B where aid={customfield_a}". "None" not allowed.
• Cfield: defined by "select cname from C where aid={customfield_a}". "None" is allowed. 

I create an issue and set Afield. Bfield gets immediately set to the corresponding B value, which is perfectly ok. Cfield is "None" which is also as expected. I save, and look at the issue again. All is well.

But...

When I click the "edit pen" on Afield, and then clicks the "V" button to set it (because I wanted to keep it as is; I didn't really want to edit it), Cfield gets set, to the first matching value the plugin could find in the database. This is done silently, nothing in the change logs for the issue hints about when it is set, and this is done even for projects which doesn't even have Cfield defined in their field lists or screens. Note also that the change isn't visible until you reload the page, so there's no way you can see what happened and correct it.

I can accept (and even like) the fact that Bfield is set, if it for some reason wasn't; it isn't supposed to be empty. But is there any explanation why Cfield - despite it actually being allowed to be empty! - is - silently! - set in this scenario? To an arbitrary (or not; it seems to be the first) value? If there is such an explanation, please tell me! 

[FlorinM · Accepted solution]

Hi Monika,

I would say that the Cfield behavior is a bug rather than a feature, so we'll be looking to fix this. If it was "None" it should keep it that way. 

The Bfield behavior, however, is more of a convention. If Afield changes, Bfield now has an invalid value and a list of (new) possible options to choose from by itself. It has to decide what value to take, given that it cannot keep its old value. Moreover, if it was a multi-select it could select more than one value from the list. The convention was that it should select the first valid value, so that the behavior is consistent with single and multi select lists.

Regards,

[Monika Danielsson]

Thank you! Yes, it's the Cfield thing that concerns me, really. Setting something that's not allowed to be unset is ok even if I'd prefer it to be noted in the change logs to make it traceable.

[FlorinM]

We will consider this as well when fixing the issue.

[Monika Danielsson]

Would there be a guess on if/when this might be changed? We have a few more things that should be implemented using custom fields, but since they are also one-many relations, I am a bit reluctant to add them as is.

[FlorinM]

The issue is planned in our next sprint which starts on monday. I do not have an official release date for the next version, but I guess it should be about 2 weeks. If this is a blocker for you, just drop us an email at jira-support at kepler-rominfo dot com and we can provide an early access version when the issue is resolved.

[Monika Danielsson]

Thank you! No, it's perfectly ok; we can use what we have until then. And many thanks for the quick replies!

[BenP]

@@Florin Manaila, can you share the issue URL here? I'm interested to find out when the fix is out. Thanks!

[FlorinM]

Hi @Ben De Pauw, The ticket is on our internal tracker, so I cannot link it. However, the fix was implemented and will be out with the next release (3.0.2). You can "Watch" the add-on on the marketplace; it will probably send you notifications with new releases: https://marketplace.atlassian.com/plugins/com.keplerrominfo.jira.plugins.databasecf

[BenP]

Thanks :)

[Monika Danielsson]

Thank you!