-
-
Notifications
You must be signed in to change notification settings - Fork 2k
[18.0][MIG] web_send_message_popup: Migration to 18.0 #3156
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
[18.0][MIG] web_send_message_popup: Migration to 18.0 #3156
Conversation
…to open directly the full featured message popup
* Intitial manifest changes * [FIX] small README tricks
@OCA/web-maintainers |
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.
Is it not possible to change the t-on-click of the "Send message" button? And use the Composer component directly instead of copying the functions to the Chatter?
@tarteo
In all seriousness I see where you're going with this, but no. |
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.
After some digging, what you can do is create a callback prop and pass the onClickFullComposer to expose it to the chatter. something like this in the setup function:
if (this.props.someCallback) {
this.props.someCallback({onClickFullComposer: this.onClickFullComposer});
}
This PR has the |
@tarteo |
@dreispt |
This seems a very aggressive language, don't you think? Reading the thread, it seems there are suggestions to improve the code. Have they been considered? |
@pedrobaeza @tarteo But at the end of the day, if merging this means doing that, well... I don't have a choice I guess. |
Glad to hear that it was just a joke. I think most of us thought otherwise. The written language + the lack of context makes it very easily misunderstood, so please take it into account for other times in the future. Thanks for the extra explanation about why not changing it. I lack a bit of knowledge in JS, but seems reasonable. What you have to do in that changes, is to put a comment over the code stating that reasons for doing it that way, as they seem not obvious - don't do that with every obvious thing - so other developers looking at the code (or you future you) remember why it was done that way and why a refactoring "reducing" code is not convenient, so you avoid the temptation next time of this being proposed to be changed again. Can you please add such comment and we proceed with the merge? |
b9914a9
to
427bc1e
Compare
I already suspected it was a cultural difference or language barrier. What I'm suggesting is not unorthodox, it's a common way to do it: https://github.com/odoo/owl/blob/master/doc/reference/props.md#binding-function-props It's even proposed if you use deprecated t-ref attribute:
|
But I'm fine merging it with the clarifying comments |
@tarteo And you're right about callback methods, they're fine! It's just a bunch of forth and back, it can get confusing and it doesn't sound right... @pedrobaeza |
/ocabot merge nobump |
Hey, thanks for contributing! Proceeding to merge this for you. |
Thanks everybody for the constructive technical debate! |
/ocabot migration web_send_message_popup |
Congratulations, your PR was merged at bcd9ad9. Thanks a lot for contributing to OCA. ❤️ |
Module migration from
16.0
straight to18.0
, cba with17.0
.Made sure
pre-commit
doesn't give warnings on import sorting (unlike some modules...).Massive .js changes, previous version (
16.0
) .js code was absolutely incompatible.