Conversation
… rebranding of Eficent to ForgeFlow.
…tified. A customer or supplier can be a follower of the object and should not receive internal messages about the tier validation.
Currently translated at 100.0% (74 of 74 strings) Translation: server-ux-13.0/server-ux-13.0-base_tier_validation Translate-URL: https://translation.odoo-community.org/projects/server-ux-13-0/server-ux-13-0-base_tier_validation/zh_CN/
Currently translated at 80.0% (60 of 75 strings) Translation: server-ux-13.0/server-ux-13.0-base_tier_validation Translate-URL: https://translation.odoo-community.org/projects/server-ux-13-0/server-ux-13-0-base_tier_validation/es/
…urchase modules installed
…er modules installed
- When use approve by sequence, still approve tier of the same reviewer - When using approve_sequence option in any tier.definition there can be inconsistencies in the systray notifications
Currently translated at 96.1% (73 of 76 strings) Translation: server-ux-13.0/server-ux-13.0-base_tier_validation Translate-URL: https://translation.odoo-community.org/projects/server-ux-13-0/server-ux-13-0-base_tier_validation/zh_CN/
This commit splits the state condition checking part into another method, allowing inheriting modules to override the conditions as needed.
By ordering only by sequence, the order is not deterministic when there are forwards, because the forwards are created with the same sequence as the forwarded reviews.
… after forward How to reproduce: * Create two reviews for the same model with different sequences and `Approve by sequence` enabled. * Request validation on a record. Let the user of the first review forward the first validation. Desired result: The new (forward) review is in state 'pending', and the remaining review is in state 'waiting'. Actual result: Both the new (forward) review and the remaining review are in state 'pending'. Suggested solution: _compute_can_review has to be deferred during the fowarding process. It was called explicitely afterwards already.
The `_get_tier_validation_readonly_domain` method returns
`bool(review_ids)` which is injected as a readonly domain modifier on
all form fields via `get_view()`. In Odoo 18, the web client does not
always include One2many fields like `review_ids` in the data spec during
form re-renders (e.g. after a status change or button click), causing an
OWL rendering error:
Name 'review_ids' is not defined
Replace the domain with `validation_status not in ('no', False)` which
uses the stored computed `validation_status` Selection field instead.
This field is always available in the form data spec and provides the
same semantics: fields become readonly when a validation process is
active (pending, approved, or rejected).
|
@leemannd can you check, please? |
|
Hello @imlopes can you squash a bit the translation and administrative commits? |
|
Why are there so many files removed in the |
|
@imlopes There is something wrong in your migration flow. You don't need to delete other modules in your migration because the steps keep only the specific module that you're migrating. |
| <span t-out="review.sequence" /> | ||
| </td> | ||
| <td name="td_requested_by" class="text-start"> | ||
| <span t-out="review.requested_by[1]" /> |
There was a problem hiding this comment.
Odoo 19's OWL stores Many2one as {id, display_name} objects
| <span t-out="review.requested_by[1]" /> | |
| <span t-out="review.requested_by.display_name" /> |
| <span t-out="review.todo_by" /> | ||
| </td> | ||
| <td name="td_done_by" class="text-end"> | ||
| <span t-out="review.done_by[1]" /> |
There was a problem hiding this comment.
| <span t-out="review.done_by[1]" /> | |
| <span t-out="review.done_by.display_name" /> |
|
Commit WIP migration can be squashed |
|
Hello @imlopes if you don't mind I would like to open a new PR to speed up migration process: Can you pls close this one? |
based on :
#12
and
#1