Skip to content
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

Merged

Conversation

bosd
Copy link
Contributor

@bosd bosd commented Jan 10, 2024

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?

@OCA-git-bot
Copy link
Contributor

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

@bosd
Copy link
Contributor Author

bosd commented Jan 10, 2024

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.
Merging of these two modules accomplish that.

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.
If the user decided to go to the document and make an attempt to do so. He was unable to do it.. Because it was not their turn yet..
Since there was no capability to get a notification. The user- had to visit the record now and then to see if it was their turn to validate.
This was a poor flow from usabulity point of view.
Easily fixed by the waiting module.

The merge of into the base module. Should make it more clear to users/functional consultants. As well as easier to maintain.

Copy link

@bofiltd bofiltd left a 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 🍾

Copy link
Contributor

@celm1990 celm1990 left a 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.

Comment on lines +81 to +95
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)
Copy link
Contributor

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).

Copy link
Contributor Author

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.

base_tier_validation/models/tier_validation.py Outdated Show resolved Hide resolved
base_tier_validation/models/tier_validation.py Outdated Show resolved Hide resolved
base_tier_validation/models/tier_validation.py Outdated Show resolved Hide resolved
base_tier_validation/models/tier_validation.py Outdated Show resolved Hide resolved
@bosd bosd force-pushed the 17.0-mig-base_tier_validation_merge_waiting branch from c280d4f to 194f9a5 Compare January 11, 2024 06:11
Co-authored-by: Carlos Lopez <celm1990@hotmail.com>
@bosd bosd force-pushed the 17.0-mig-base_tier_validation_merge_waiting branch from 194f9a5 to 395c4a2 Compare January 11, 2024 06:12
Copy link

@Dranyel-Bosd Dranyel-Bosd left a 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 🍾

@OCA-git-bot
Copy link
Contributor

This PR has the approved label and has been created more than 5 days ago. It should therefore be ready to merge by a maintainer (or a PSC member if the concerned addon has no declared maintainer). 🤖

@celm1990
Copy link
Contributor

celm1990 commented Jan 15, 2024

I tested these changes, but I have some doubts. For example, I have three reviews for three specific users:

R1 -> Admin
R2 -> U2
R3 -> U3
image

Before this commit:
When Admin approved R1, an email is sent to U2 and U3 notifying them that R1 is approved.

After this commit:
When Admin approves R1, an email is sent to both U2 and U3, notifying them that R1 is approved(as previous). Additionally, a new email is sent to U2 and U3 informing them that a new review (R2) has been created. However, for the purpose of this changes, if the intention is to notify only the next user (U2), I hope that only U2 is notified and that no email is sent to U3. This is because if U3 receives an email, they might attempt to review and approve, causing confusion as it is not their turn yet. we would revert back to the initial problem.

image

Please let me know if I understood the functionality of the module correctly.

@bosd
Copy link
Contributor Author

bosd commented Jan 15, 2024

Additionally, a new email is sent to U2 and U3 informing them that a new review (R2) has been created. However, for the purpose of this changes, if the intention is to notify only the next user (U2), I hope that only U2 is notified and that no email is sent to U3. This is because if U3 receives an email, they might attempt to review and approve, causing confusion as it is not their turn yet. we would revert back to the initial problem.

Yes, I think you understand the functionality correctly.
The main problem before, was that U3 got an invitation email to review.
But he coul'dnt review because it was not his turn yet.
Before this PR, he was unable to get a notification when it actually was his turn.

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.
Yet, I'm unable to determine from your feedback if the module passed the functional test.
Dunno if it is the case, but the notification settings might be a bit "misleading"/unclear.
In a sequential flow, I would reccomend to only check the Notify Reviewers on reaching Pending box.
Ignoring all the other notifications, this should happen.

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)
Loading

@bosd
Copy link
Contributor Author

bosd commented Jan 15, 2024

While out of scope of this pr, we might want to look into who is receiving the "approved messages".
To have it go to the original document owner makes sense. In case U3 is upper management, we don't want to bother him with all the back and forth happening in the tiers before.

Copy link
Contributor

@celm1990 celm1990 left a 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 .

image

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?

@bosd
Copy link
Contributor Author

bosd commented Jan 18, 2024

Oopsie, I answered on the comment above, but it does'nt show up down here.
If more improvements are suggested I'm happy to include them.
But as other mirgrations depend on this base module, ideally we would move forward.

@OCA/tools-maintainers I think this one is ready for merge..

@celm1990
Copy link
Contributor

@LoisRForgeFlow @pedrobaeza, could you take a look at this PR? What do you think, is it possible to merge?

@bosd
Copy link
Contributor Author

bosd commented Jan 25, 2024

@kittiu Can you please review as well?

@bosd
Copy link
Contributor Author

bosd commented Jan 25, 2024

@gurneyalex Can you take a look as well? 🙏

@bosd
Copy link
Contributor Author

bosd commented Feb 3, 2024

@oca/edi-maintainers Can we please fasttrack this one? 🙏

@bosd
Copy link
Contributor Author

bosd commented Feb 5, 2024

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?

@rousseldenis
Copy link
Contributor

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.

Copy link
Contributor

@LoisRForgeFlow LoisRForgeFlow left a 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:

  1. This field seems to be a bit misplaced:

image

  1. Time to add the sequence handler widget?

image

  1. 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.

image

@bosd
Copy link
Contributor Author

bosd commented Feb 8, 2024

Functional review, in general I think this is a great proposal, thanks! Some comments below:

  1. This field seems to be a bit misplaced:

image

The UI Improvements are made in follow up pr.
#804

  1. Time to add the sequence handler widget?

image

Great Suggestion..
Will add it, In this PR or the UI PR. In case this one gets merged first.

  1. 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.

image

I agree, The messages and the content could be improved.
Have been thinking about rewording the message to.. But decided to not do big chances for now.
Adding the reviewer name to which the review is requested from could be usefull.
But will also lead to confusion by request from a group or server action.

@LoisRForgeFlow Are you ok to merge this one as is?
So the other modules which depend on it can be refactored during the migration.

@LoisRForgeFlow
Copy link
Contributor

@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

@LoisRForgeFlow
Copy link
Contributor

/ocabot merge minor

@OCA-git-bot
Copy link
Contributor

What a great day to merge this nice PR. Let's do it!
Prepared branch 17.0-ocabot-merge-pr-800-by-LoisRForgeFlow-bump-minor, awaiting test results.

@OCA-git-bot OCA-git-bot merged commit de8ae97 into OCA:17.0 Feb 8, 2024
5 checks passed
@OCA-git-bot
Copy link
Contributor

Congratulations, your PR was merged at 4600958. Thanks a lot for contributing to OCA. ❤️

@LoisRForgeFlow LoisRForgeFlow mentioned this pull request Feb 8, 2024
23 tasks
@bosd bosd deleted the 17.0-mig-base_tier_validation_merge_waiting branch February 8, 2024 18:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants