-
-
Notifications
You must be signed in to change notification settings - Fork 59
[16.0][IMP] sign_oca: add back to draft action button #124
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
base: 16.0
Are you sure you want to change the base?
Conversation
|
Hi @etobella, |
back_to_draft.mp4 |
|
the good in this approach the simple code the bad is that all signers will be emails even if some of them have already signed, this is bad because they may unsubscribe. but your opinion is welcome: |
|
needing to review this one and all merging and their similarities in 18.0 |
|
|
||
| def action_reset_to_draft(self): | ||
| self.write({"state": "1_draft"}) | ||
| self._set_action_log("to_draft") |
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.
What will happen if we have 2 signers and one of them has already signed?
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.
In fact that module can not help unless I cancel and then set it back to draft and then I set to sent,
For example if a customer and employee, and employee has signed then this workfow will make the email to be sent to the customer or all customers who are in the sign request even if one of them has already signed.
In fact this is the point I made the other PR for, that is making email to be sent only to who did not sign.
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.
But then, all signers should be reseted back, isn't it?
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.
not at all, the point was just sending the email to who signed will not make sense because if the open the link they find themselves already signed.
but their signature is there not changed, other signers if they sign that will be append to former ones.
To avoid unnecessary emails I select the people who didn't sign to receive the notification email.
But I confirm no partner have to sign a document they already signed as this will make them upset and the purpose of this approach to facilitate to them not to annoy them.
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.
But that is mainly the issue...
Let me explain myself. If we cancel the sign.request, all signatures should be invalidated and we might need to start over again and sign everything again.
At least this is the way I see it. For me, the main goal here is to resend the request to the missing signers, wouldn't be better to do that?
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.
@etobella
@victoralmau
and not change or update the state between canel, draft, and sent?
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.
IMO, no, the status should not be changed. As with other sections of Odoo, why shouldn't it be possible to resend an email to someone without having to change anything?
A button (only visible if sent and not signed) that does just that (sending an email) is the simplest and clearest interface.
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.
in fact that first PR is doing the same functionality #89
Can we transition to and continue conversation as that button you suggest is there and I don't change the state there too.
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.
Answered at #89, the approach I propose is neither this PR nor the other one.
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 will make it closer there, don't worry.
|
now this issue is solved after importing a function from my former PR, its in the 2nd commit now. |
In a competition with: #89
Only one is planned to be merged or we can take the best of both in one single thing.