Another attempt to fix submit rule evaluation for non blocking labels
New change screen changed the logic for submit status evaluation
by moving it partially to the client side. The change can be submitted
only when all needed labels have max scores and there is no labels exist
with min score. The computation of rejection is based on `rejected`
attribute in LabelInfo class. This attribute was set in two places:
1. As outcome of submit rule evaluation (with blocking functions)
2. In setLabelScores() to render the result for non blocking labels
After overriding of rejected attribute for non blocking labels it was
not possible any more to differentiate on the client side if one
particular label was rejected for information purpose only or because
it was blocked.
5a32a6dc15b73d412645598648ac089eacf29b65 was trying to solve it by
not overriding the rejected attribute in setLabelScores(). The
consequence of doing it was however, that custom labels with min
score were rendered not as rejected but as disliked.
This change introduces the `blocking` attribute in LabelType class to
carry out the missing information to the client to perform the correct
submit status computation. Now the rejected attribute can be overridden
for custom non blocking labels and rendered correctly.
Bug: Issue 2453
Bug: Issue 2497
Change-Id: Ic5092342b0e2153eb43f5e06fda4fcac4699844e
5 files changed
