Skip to content

[19.0][IMP] base_tier_validation: validation progress indicator#35

Open
bosd wants to merge 1 commit into
OCA:19.0from
bosd:19.0-imp-base_tier_validation-validation-progress
Open

[19.0][IMP] base_tier_validation: validation progress indicator#35
bosd wants to merge 1 commit into
OCA:19.0from
bosd:19.0-imp-base_tier_validation-validation-progress

Conversation

@bosd
Copy link
Copy Markdown
Contributor

@bosd bosd commented May 13, 2026

Summary

Make it possible to tell at a glance how close a document under validation is to being fully approved.

Server-side

  • New validation_progress Integer (0..100) on the tier.validation abstract mixin. Computed as approved_reviews / total_reviews * 100, rounded to int. Returns 0 when there are no reviews. Reuses _validated_states() so subclasses that override approved-state semantics keep working.

Client-side (embedded reviews widget)

  • Bootstrap progress bar rendered in the widget header next to the Reviews collapse title.
  • Percentage computed live in JS from the already-embedded review_ids data, via a new getValidationProgress() helper on the OWL component — no extra RPC.
  • SCSS scopes the new layout under .o_tier_validation_progress_header so title + bar sit on one row with a sensible max width.

Why both server-side field and JS computation?

  • Server-side field is needed for list views (bridge modules: account.move, sale.order, ...) to use widget="progressbar". Those follow up as separate per-bridge PRs.
  • JS computation in the widget keeps the embedded view reactive without a server round-trip every time a review toggles.

Test plan

  • New test_validation_progress: create two tier definitions, request validation (expect 0%), validate one tier (expect 50%), validate the other (expect 100%).
  • Manual: open any validated record with multiple tiers; the bar in the Reviews widget header reflects how many have been approved.

Heads-up on overlap

This PR touches static/src/components/tier_review_widget/tier_review_widget.xml and .scss, which #23 also modifies (Bootstrap 3 -> 5 class rename). Whichever lands first wins; the other will need a trivial conflict resolution on class names (panel-heading -> card-header). The progressbar additions are class-agnostic and survive either way.

Follow-up PRs

  • per-bridge: widget="progressbar" column on account_move_tier_validation, sale_order_tier_validation, ...
  • pie / circle widget as a richer alternative — separate draft PR if/when wanted.
image

Make it possible to tell at a glance how close a document under
validation is to being fully approved.

Server-side:

- New `validation_progress` Integer (0-100) on the `tier.validation`
  abstract mixin, computed as `approved_reviews / total_reviews *
  100`. Returns 0 when there are no reviews. The computation reuses
  `_validated_states()` so subclasses that override the approved state
  semantics keep working.

Client-side (embedded reviews widget):

- Render a Bootstrap progress bar in the widget header next to the
  "Reviews" collapse title. The percentage is computed live in JS
  from the already-embedded review_ids data (no extra RPC), via a new
  `getValidationProgress()` helper on the OWL component.
- SCSS scopes the new layout under `.o_tier_validation_progress_header`
  so the title + bar sit on one line with a sensible max width.

The server-side field is what bridge modules will use to add a
`widget="progressbar"` column to their list views (account.move,
sale.order, ...). That work lands as separate follow-up PRs per bridge.

Test: create two tier definitions, request validation, validate one
tier (expect 50%), validate the other (expect 100%).
@OCA-git-bot
Copy link
Copy Markdown
Contributor

Hi @LoisRForgeFlow,
some modules you are maintaining are being modified, check this out!

@OCA-git-bot OCA-git-bot added mod:base_tier_validation Module base_tier_validation series:19.0 labels May 13, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

mod:base_tier_validation Module base_tier_validation series:19.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants