-
-
Notifications
You must be signed in to change notification settings - Fork 532
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[17.0][IMP] base_tier_validation: Merge module with base_tier_validation_waiting #800
[17.0][IMP] base_tier_validation: Merge module with base_tier_validation_waiting #800
Conversation
Hi @LoisRForgeFlow, |
Some background info... Since sequential validations are supported in the base module. It makes sense from an user perspective to only sent out notifications to the validator if it is thier turn in the sequence to review. Before this pr (and without the waiting module) it was only possible to sent out and notification when a record was created. A reviewer in the end of the sequence got the e-mail notification before it's turn. The merge of into the base module. Should make it more clear to users/functional consultants. As well as easier to maintain. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense.
Functional test locally. LGTM 🍾
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
first code review; I will test it for functionality.
reviews = self.filtered(lambda rev: rev.status in ["waiting", "pending"]) | ||
if reviews: | ||
# get minimum sequence of all to prevent jumps | ||
next_seq = min(reviews.mapped("sequence")) | ||
for record in reviews: | ||
# if approve by sequence, check sequence has been reached | ||
if record.approve_sequence: | ||
if record.sequence == next_seq: | ||
record.status = "pending" | ||
# if there is no approval sequence go directly to pending state | ||
elif not record.approve_sequence: | ||
record.status = "pending" | ||
if record.status == "pending": | ||
if record.definition_id.notify_on_pending: | ||
record._notify_pending_status(record) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm uncertain whether it's advisable to update fields within a computed function
if those fields are not explicitly defined as computed (field status
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NOTE: Please let me know your comments regarding my comment on computed fields not being defined as computed explicitly. Could this be causing cache inconsistency?
tbh, I'm a bit overasked by this..
Maybe it is not the ideal situation. (yet, I'm unaware of any alternative method to implement this).
Well, we've deployed this code succesfully in production. W/o any problems.
Judging from the experience it is okay..
But happy to learn from the more experienced dev's.
c280d4f
to
194f9a5
Compare
Co-authored-by: Carlos Lopez <celm1990@hotmail.com>
194f9a5
to
395c4a2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Functional test locally, LGTM 🍾
This PR has the |
I tested these changes, but I have some doubts. For example, I have three reviews for three specific users: Before this commit: After this commit: Please let me know if I understood the functionality of the module correctly. |
Yes, I think you understand the functionality correctly. Another use case is that U3 could be upper management. And only wants to be bothered with messges which made it past the previous tiers. I'm under the impression you have the functionality and use case correct. flowchart TD
A[U0 validation request] -->|Notification message: request to review sent to U1| B[U1 Approves SO]
B -->|Notification message: request to review sent to U2| C[U2 approves SO]
C -->|Notification message: request to review sent to U3| D[U3 approves SO]
D--> E(The End\n Record = validated)
|
While out of scope of this pr, we might want to look into who is receiving the "approved messages". |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for clarifying. I unchecked "Notify on Creation" as per your suggestion to reduce emails. However, I noticed that other users are still being notified when reviews are requested. I suspect this is happening because of followers. So, LGTM .
By the way, in the other PR(Improve UI), you can add these fields as optional="show"
😅
NOTE: Please let me know your comments regarding my comment on computed fields not being defined as computed explicitly. Could this be causing cache inconsistency?
Oopsie, I answered on the comment above, but it does'nt show up down here. @OCA/tools-maintainers I think this one is ready for merge.. |
@LoisRForgeFlow @pedrobaeza, could you take a look at this PR? What do you think, is it possible to merge? |
@kittiu Can you please review as well? |
@gurneyalex Can you take a look as well? 🙏 |
@oca/edi-maintainers Can we please fasttrack this one? 🙏 |
Oops, used the wrong handle to fasttrack this one.. @OCA/server-ux-maintainers seems to be the correct one? Or @rousseldenis Do you have super powers here as well? |
Nope. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Functional review, in general I think this is a great proposal, thanks! Some comments below:
- This field seems to be a bit misplaced:
- Time to add the sequence handler widget?
- There are multiple notifications with the same message. This one is not a blocking comment as I know this was an issue before this change too, but with this sequencial approval it becomes more noisy.
The UI Improvements are made in follow up pr.
Great Suggestion..
I agree, The messages and the content could be improved. @LoisRForgeFlow Are you ok to merge this one as is? |
@bosd Yes, I think we can merge as is, and continue the improvements on followup PRs. I don't want to hold this because of my lack of time to review |
/ocabot merge minor |
What a great day to merge this nice PR. Let's do it! |
Congratulations, your PR was merged at 4600958. Thanks a lot for contributing to OCA. ❤️ |
As proposed as an idea in:
#787 (comment)
This is the PR for the migration of base_tier_validation_waiting into the base module
base_tier_validation_waiting
.Please fasstrack, as v17 is not deployed yet in production, this is the best time to introduce this refactor.
To the contributors/authers/reviewers of the migration pr..
@celm1990, @nguyenminhchien, @bofiltd, @moitabenfdz, @sonhd91, @Dranyel-Bosd, @BT-jcolmeiro
Can you please review?