[19.0][IMP] base_tier_validation: name the assignee in the "to validate" banner - #24
Merged
Merged
Conversation
Contributor
|
Hi @LoisRForgeFlow, |
OCA-git-bot
added
mod:base_tier_validation
bosd
changed the title
bosd
force-pushed
the
19.0-imp-tier-pending-banner
branch
from
May 13, 2026 15:57
0f7c115 to
086ed4d
Compare
Contributor
Author
|
Now one can see exactly who it is waitiing on, when doing a sequenced validation: Before: After: |
…nner
The yellow banner shown above a tier-validated document used to read
This Record needs to be validated.
which is generic in two ways: it does not say which model the
record belongs to, and -- more importantly -- it does not say *who*
is expected to act. Users in our rollout consistently asked
"who's holding this up?" even though that information already
exists on the underlying ``tier.review.todo_by``.
Rework ``_get_to_validate_message`` to surface the pending tier's
``todo_by`` inline so the banner reads, for example:
Pending validation by John
Pending validation by Group Accountants
Pending validation by Mike, Jane (and 2 more)
When no review has reached ``pending`` yet (e.g. the defensive
``waiting`` edge case, or downstream code calling the method on a
fresh record), fall back to the existing model-name phrasing:
This Sale Order needs to be validated.
Plumbing:
- ``_compute_to_validate_message`` now depends on
``review_ids.status`` and ``review_ids.todo_by`` in addition to
``validation_status``, so the banner refreshes when a tier reaches
pending or when the assignee changes.
- The ``tier_validation_label`` template now actually renders the
``to_validate_message`` field (long-defined on the abstract model
but never previously wired into the template, which carried its
own hardcoded text).
- ``todo_by`` is reused so every review type -- individual user,
group, ``res.users`` / ``res.groups`` field, Python expression --
is handled by one path and stays consistent with the Reviews
table below.
Tests:
- ``test_19c_to_validate_message_names_assignee`` -- after a tier
reaches ``pending``, the banner contains the assignee and not the
generic phrasing.
- ``test_19d_to_validate_message_falls_back_when_no_pending`` --
with no pending review, the banner falls back to the model-name
phrasing.
bosd
force-pushed
the
19.0-imp-tier-pending-banner
branch
from
June 5, 2026 20:36
086ed4d to
6c8ea00
Compare
Contributor
|
/ocabot merge minor |
Contributor
|
On my way to merge this fine PR! |
Contributor
|
Congratulations, your PR was merged at 732e49c. Thanks a lot for contributing to OCA. ❤️ |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
The yellow banner shown above a tier-validated document currently reads
…which is generic in two ways: it does not say which model the record belongs to, and -- more importantly -- it does not say who is expected to act. Users in our rollout consistently asked "who's holding this up?" even though that information already exists on
tier.review.todo_by.This PR makes the banner read, for example:
…sourced from the same
todo_bythe Reviews table already uses, so individual users, groups,res.users/res.groupsfield reviewers and Python-expression reviewers all render uniformly.When no review has yet reached
pending(defensive edge case -- e.g.waitingstate, or downstream code that calls the method on a fresh record), the banner falls back to the existing model-name phrasing:Plumbing
_get_to_validate_messagenow picks the lowest-sequence pending review and embeds itstodo_byinto the body._compute_to_validate_messagenow depends onreview_ids.statusandreview_ids.todo_byin addition tovalidation_status, so the banner refreshes when a tier is promoted or when the assignee changes.tier_validation_labeltemplate now actually renders theto_validate_messageHtml field (which has existed on the abstract model since v14 but was never wired into the template; the template carried its own hardcoded text).Tests
test_19c_to_validate_message_names_assignee-- after a tier reachespending, the banner contains the assignee and does not contain the generic phrasing.test_19d_to_validate_message_falls_back_when_no_pending-- with no pending review on the record, the banner falls back to the model-name phrasing.Notes
_get_to_validate_message_nameis unchanged and still hooks any downstream override (custom phrasing per model). The new code only changes what's rendered whentodo_byis available.next_review(the "Next: " sub-line) is left as-is. It's complementary information -- the new banner says who,next_reviewsays which tier. Removing it is out of scope.CC @LoisRForgeFlow