Include details of rejected/aborted/timed out annotations in the export

[ianroberts]

Add a section to the export formats detailing which users (if any) have rejected, aborted or timed out annotations on each document.

For JSON this is a dict with properties whose values are a JSON list of ID numbers (for anonymous) or names (for non-anonymous) of the relevant annotators:

{
    "rejected_by": ["ian", "twin"],
    "timed_out": ["david"],
    "aborted": []
}

In "raw" mode this is added as "teamware_status" to the top-level doc_dict, for "gate" mode the "teamware_status" property is added under "features".

For CSV export it appears as columns teamware_status.rejected_by, etc. with the lists flattened to comma-separated strings exactly as with multi-valued fields from the annotations.

This functionality is particularly useful for project managers to identify "difficult" documents that may suggest additional training for the annotators.

[github-actions]

Jest Coverage

File	% Stmts	% Branch	% Funcs	% Lines	Uncovered Line #s
All files	83.8	83.96	64	83.8

File	% Stmts	% Branch	% Funcs	% Lines	Uncovered Line #s
All files	83.8	83.96	64	83.8
_jrpc	94.11	91.66	83.33	94.11
_ index.js	94.11	91.66	83.33	94.11	29-30,38-40
_utils	81.97	82.97	57.89	81.97
_ annotations.js	97.72	73.91	100	97.72	35-36
_ dict.js	88.88	83.33	100	88.88	3-4
_ expressions.js	80.08	82.35	80	80.08	...,188-190,201-218
_ index.js	73.6	100	14.28	73.6	...4-65,76-82,93-94

[ianroberts]

Question: as this PR stands it will always add the teamware_status section even though it will be degenerate {"rejected_by":[],"aborted":[],"timed_out":[]} in the majority of cases - would it make more sense to omit the whole teamware_status property from the JSON if all the lists are empty (making the JSON smaller) or leave it as it is now (meaning code processing the JSON doesn't have to worry about null checks)?

[twinkarma]

This looks good to me!

[ianroberts]

Thanks, I'll merge this and then make another PR for a new release.

[twinkarma]

Question: as this PR stands it will always add the teamware_status section even though it will be degenerate {"rejected_by":[],"aborted":[],"timed_out":[]} in the majority of cases - would it make more sense to omit the whole teamware_status property from the JSON if all the lists are empty (making the JSON smaller) or leave it as it is now (meaning code processing the JSON doesn't have to worry about null checks)?

I think it's ok to just always export the "teamware_status" field even if all the results are empty and as you said will probably help with null checking.