get the latest issue according to a custom field then calculate value for another custom field

Question

in my project opn creating an issue there is a scnerio;Here are the details

I have 2 custom fields and let's say custon_field_A and custom_field_B. A is a single select and B has to be a calculation as number from the latest issue according to A.

A selectable (single select) values are;

TKT
TBA
TKS
TIS
TMA
TMS
TPR
TTA

Let's say While creating issue when I make select from "A" according the value. then I have to find the latest record with the value of "A" then also I have to get the value "B" but I have calculate as +1 and make it as selectable for "B"

Lets say If my last record were;;

A=TMA  and B=103

So While creating a new issue if I select again value A=TMA then B has to be equal=104

Radek Dostál · Answer

If you want to avoid concurrency problems, script jobs would be the go-to in my opinion: https://docs.adaptavist.com/sr4js/latest/features/jobs/custom-jobs

Scripted fields would be too heavy, because each issue would have to calculate itself incessantly often, so this would be a huge performance hit.

Listeners might work, but would be prone to concurrency problems. (Multiple issues being created at the same time, two different listener processes may read the same value+1 and then you get 2 issues with same value.)

Workflow post-function same as a listener, concurrency.

Behaviours are going to be affected by concurrency the most as the user spends far more time with the screen open, rather than a listener taking a few millis.

So I would guess a CRON job, e.g. every morning/evening, that filters out issues where the custom field not null, sorted by created ascending, that iterates over the issues, reads the value of both A and B; uses a map to store distinct value:counter; so that each issue in ascending order gets it's corresponding index.

Since it's a job it won't affect general daily/peak hours performance, and it can store the result in a regular field so the value is indexed and can be used in reports/plans/boards, etc.

As for the code, well, https://library.adaptavist.com is usually a good start.

Cem Tuğrul · Answer

Yeah I have script runner with the latest version. I am just trying to setup this logic safely. Because when my issue created it does not mean that I have to calculate and make it selectable (B) what I need is that B has to be correct number (it is kinda a counting)

As your explanation If I have totally 80 issues (and each of them 10)

TKT
TBA
TKS
TIS
TMA
TMS
TPR
TTA

So When my new issue created and selected as "TKT"

THEN  "B" has to be =11  automatically.

Maybe I can setup a trigger ,etc . But as I have mentioned what is the best logic way that I can start

Radek Dostál · Answer

So basically you want that if A is not null (="Value of A"), then B is a sum of issues containing the specific value of A.

Example:

A = TMA

B = issue count where value of A = TMA

A = TMB

B = issue count where value of A = TMB

// EDITED

I realized later on you can't use calculated fields because in your case you need to set the value and store it as is, so calculated fields wouldn't do this at all.

Soooo I still think you would need a plugin, and ScriptRunner has behaviours https://docs.adaptavist.com/sr4js/latest/features/behaviours with which you could get the issue count on the screen and "insert" the value in the background based on other existing data.

However, there's another problem, that being concurrency and it being prone to break if indexes are missing / not properly distributed across the cluster.

Basically behaviours can execute groovy code in the background while you are on issue screens, that way, can do a jql search, and then set a value for a specific field. All based on what the user does on the screen itself and what fields he changes and what he changes them to. Behaviours can do a lot of stuff dynamically in the background.

I don't know if there is any alternative to SR in this regard, it's the only thing I know that might come close to something like this use case.

Or maybe remove the field from create/edit screens and have a job running periodically setting the value for the field. It can filter out issues, sort them be key or created, that way you know the order they were created in. Avoids concurrency problems altogether and won't use a wrong value if the indexes are missing/partial.

Or it could be a workflow post-function on create (though that still poses a concurrency issue and index reliance).

Maybe that a periodical background job might do it? If it runs on a CRON, say, for example, twice a day? Sounds like the perhaps most reliable way of getting "correct" data without concurrency risks.