We have utilized something similar in our instances. We actually approach it from both directions, first by putting the fields "scope" in the code (usually an "if" statement checking for project and/or issue type), and second by adding a field context. I have had much better luck scoping the context to Projects rather than issue types.
In your scenario, there is one other thing to check, and that is to see whether or not the global context still exists. When we use the context to scope scripted fields down, I always remove/overwrite the global context so that only the scope context exists. I have not actually checked in the search results like your screen-shot, but what I did do was do a before context/after context count of the number of references in the logs after a re-index. Based on the numbers I saw, the context helped significantly and was scoping properly.
An additional note as to why we use both methods: We have some rather large JIRA instances and noticed that even though we were scoping to a specific project/issue type within the code, the script is still executing (you can see this by adding a log statement before the scoping code) and during the re-index process causes a lot of unnecessary time and system resource usage. By adding the field context (when properly configured), the script never executes for issues that didn't meet the context criteria.
Thanks.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
If you want to use scripted field only for specified type you should to define it into code.
Because values for scripted fields are calculated at every reindexing.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.