I would like to second Yves on avoiding multiple versions for different Jira versions. It is really a headache for us.
@DamianKedzierski we use bridges in our plugins to make unified versions for Jira 7 and Jira 8. In bridge we basically encapsulate some Jira service / manager beans (those are the ones have different interfaces in Jira 7 and Jira 8) with 2 different adapters and selectively enable those adapter beans based on Jira version. I think it will be not helpful in this case since we are dealing with CustomFieldType interface and not a service bean. There is no way I can think of we selectively give Jira 2 different CustomFieldType implementations based on the version. Once we try to put NonnullCustomFieldProvider in our codebase it will basically not compile for any previous version of Java 8.10 due to missing Class.
If anyone have a good idea to how to make things backwards compatible in a single codebase I would really like to hear that because we really donât want to return back into creating and uploading 4 jars for a single version (x2 from Jira7/Jira8, x2 from Datacenter/Server) and managing 2 different branches.
@kubilay@yvesriel@a.belostotskiy We are currently working on the approach that would allow vendors to compile and run their apps across different Jira versions. We will keep you updated, as soon as tests will finish successfully .
Our use case which differs from other fields is mostly about Options. In the different Atlassian fields, the data stored in the custom field is simply the selected Option(s). So during a re-index, they donât need to call the OptionsManager as they simply index the value that they have. It doesnât matter to them if options have been added/removed in the mean time.
Now, in our use case, all Options are always added to our custom field data. So during a re-index (e.g. after Options have been addes/removed) we need to call the OptionsManager and index all their Option values into every issue matching the custom fieldâs context.
So, with the new API, we need to call the OptionsManager once to see if their is anything to index and let you know about it. Then, even when you only return to us what needs to be indexed, we still need to call OptionsManager again to do the real job. So in our case it amounts to doing the job twice.
Thatâs why itâs faster for our customers to not implement the new API.
We spent today trying to use the new âCustom field indexingâ page to check if our custom fields cause any problems, but without any success.
We usually test on non-clustered installations, and that screen is not accessible even using a DC license. (It would be nice if it were.) We updated our scripts to start a clustered test server (albeit with a single node), so we can access the stats page now. But it doesnât seem to be showing what it should.
We tried both blocking and background full-reindexing, but the data shown on the metrics page is not affected. It only shows system fields (which seems unlikely, we have lots of custom fields on the test database), âsnapshotâ and âtotalâ stats are identical, the âCalls to indexerâ column shows numbers much lower than our issue count, and the text at the top says âLast data update on node node_single: 25/Jun/20 3:43 AMâ. (The date seems legit, but the time is a long time before we even starting working on this.)
@yvesriel With 8.10 we added a new method to FieldIndexer:
void addIndex(final Document doc, final Issue issue, final CustomFieldPrefetchedData prefetchedData)
The default implementation will ignore prefetchedData, but as your indexer overrides it you may simply read the value from it without the need of recalculation.
Could you elaborate a little on single and multi select custom fields which uses contexts defined per project? Comparing for example 1 global context for 500 projects vs. 500 contexts for 1 project each? Does each context has their own index?
.
please keep us updated 