With commit 7b165cd5, it was incorrectly assumed that PDT notifications
sent by PayPal could not be verified with the suggested method
(dedicated to PDT notifications) because they were missing some required
parameters. The code was thus adapted to have their verification done
with the method already in place for IPN notifications, as it seemed to
do the job. It turns out that the PayPal sandbox account that was used
at that time was not properly configured, and that PayPal was then
sending IPN-like notifications instead of actual PDT notifications,
which is the reason why the swap of methods worked.
Actually, once the account is properly configured, PayPal sends
correctly populated PDT notifications that must be verified with the
method dedicated to PDT notifications, as the one dedicated to IPN
notifications stops working in that case.
With this commit, the method used to verify the origin and integrity of
PDT notifications is replaced by the one that was previously removed.
The method is however implemented in a more defensive manner to:
1. accept and process the notification without verification if the
account is not properly configured on PayPal.
2. silently discard the notification if the acquirer is not properly
configured on Odoo. We then rely on the IPN (webhook) to confirm the
transaction.
task-2744043
closesodoo/odoo#83659
X-original-commit: 7367f543498810bbdb018aa3566c7afed5684436
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
In master, the tax template consistency test
is broken since 8fb53c53c3
Fix this to make sure we add an exception for
that new computed field as it should not be in
the template.
closesodoo/odoo#83724
Signed-off-by: Florian Gilbert <flg@odoo.com>
Recently, a lot of the network infrastructure code was rewritten. A lot
of this new code doesn't account for the possibility of being on an
external website, and so network requests made with relative URLs would
not make their request to the odoo server but to the server serving the
external page which would fail.
This commit fixes that by replacing the regular rpc service with one
that will add the correct prefix, as well as patching the
"browser.fetch" method to do the same. Additionally, the localization
service is now less fault-tolerant, and won't silently fall back to a
default configuration if it cannot get the translations from the server,
as such, the tranlsations route is made available cross-origin, which
has the added bonus of making translations available to the embeded
code.
opw-2677184
closesodoo/odoo#83690
X-original-commit: 5ec64d15197e8d6cc7b115aeaca99aa49de0f151
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Samuel Degueldre <sad@odoo.com>
With [1] in 13.0, the blog post layouts were reviewed. At the same time,
new demo data was introduced. By default, with demo data, you have now
two different blogs. The JS tour was adapted so that when you create a
new blog post, a step explains you have to select the blog you want to
create the post in with the dialog that opens. The main problem that
this PR aims to solve is that all users start without demo data and thus
with only one blog... so with the current tour, the users are blocked
very early in the tour as they do not have the dialog to select the blog
in which to create their blog post. The simple solution that was chosen
is to set the step as "auto", meaning it will only be used in runned
tours (like via python tests), allowing to still test the blog selection
dialog in our python test. Users will not be guided via a tip for this
specific modal but this is not a problem as this is very straightforward
to understand in the case the user explicitely created multiple blogs
before creating blog posts.
This commit also review commit merged at [2] which made that python test
more robust by not relying on the demo data. That was here improved with
explanations.
However, allowing the tour to go further than the blog post creation for
the user... revealed that the rest of the tour was still blocking the
user. The very next step is to modify the blog post title. That step was
simply not possible to consume. Indeed the tour system asks for a click
event on the title... which is never detected because our old editor
removes all click handlers on that specific top-level editable area. The
cleanest way of fixing that is actually to not wait for a click but wait
that the user actually types text. For this purpose a feature was
introduced in 14.0 with [3] (even if unfortunately, that commit was not
well split). Unfortunately again... that 14.0 feature is currently buggy
during test tours as choosing the "input" consumeEvent alongside the
"text" run method... changes the behavior of that "text" run method when
the affected element is a contenteditable element. That should be fixed
but this will be done in a further update. Meanwhile, this commit
chooses to use the consumeEvent 'mouseup' which circles around both
issues.
[1]: https://github.com/odoo/odoo/commit/bb0cdec4594fab8c22265ed8af0c2d431a263b72
[2]: https://github.com/odoo/odoo/commit/f16f2e212a30352ead86c2f876be02b5c5e23b07
[3]: https://github.com/odoo/odoo/commit/a34cd7c662b3753d630d83793ffcb53b4a0a92d2
Bug revealed by testing task-2728994
closesodoo/odoo#83721
X-original-commit: ca82efe0c7b9a5e98d5c9623b3ae0f1b88fc8091
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Purpose of this commit to add format_type option in daterange
widget.
So, In this add format_type option in nodeoption which convert
actual formatType to given format_type in option and add test
case for that feature.
task:2710539
Closes: #81630
Related: odoo/enterprise#22994
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
** = hr_timesheet,rating,sale_timesheet,sale_project
Purpose of this commit to improve generic UX of project app.
So, In this commit done the following point:
- change the label for 'planned_hours' field in project task form view.
- change demo user access right to project user instead project admin.
- display the rating_status and rating_status_period fields under the 'customer
ratings' feature in the settings.
- add 'project_id', 'mail_template_id', 'rating_template_id' fields in project
task search view.
- add open and closed filter in project search view.
- display 'assign to me' button secondary when user set on task.
- add tooltip for 'date_deadline' field in project form view.
- replace create_date field by write_date in rating views.
- change context of billable time stat button action.
- improve search view of project task.
- hide rating stat btn when satisfaction is 0%.
- change name of task create when SO confirmation.
- change name of project create when SO confirmed when there is only one SO
line contain service_tracking is 'only_project'.
- add id field in tree view of project task as option hide
task-2710539
closes: #81630
When a user clicks on 'could be used in' in the page properties after
chaing the URL, a list is displayed in a popup. This popup was
not properly rendered:
- the content could not be scrolled through, it was thus truncated
- the popup appeared behind the technical modal that kicks in on small
screens
Now the popup is better positioned, a scrollbar is available to access
its content when it is too long and on small screens it is displayed on
top of the technical modal, making it visible on small screens.
task-2092269
closesodoo/odoo#83693
X-original-commit: e2f1f4967a2dd4d730895e924f0c7ca02e23a17b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Jitendra Prajapati <jpr@odoo.com>
Co-authored-by: Benoit Socias <bso@odoo.com>
*: web_editor
Steps to reproduce:
- Activate the cookie dialog from the website settings
- Remove the backdrop from the cookie dialog
- Add some blocks to the cookie dialog in the website editor
until the dialog height is bigger than the page height.
Result:
The cookie dialog is not scrollable, so it's impossible to reach
the "I agree" button and close the dialog, leaving the user stuck
at the first page.
I check if the popup content is higher than the window. If it is, I
give priority to the popup scroll over the page one. I had to
overwrite the _showElement method to call _setScrollbar after
the content rendering, in this way I can get its correct height.
I also try to update the scrollbar each time a block in the cookie bar
has been changed and each time the window resize. This is optimize, so
if the overflow isn't changed from the last time I tried to update the
scrollbar no action will be taken. In this way you can always see the
whole popup without refreshing the page.
Also I have to set 'pointer-events' to none only if the popup is
smaller than the page itself (to interact with and scroll the
page behind), otherwise the popup won't be scrollable. I did
this by adding a class "s_popup_overflow_page" if the popup is
higher than the page and I adapted the pointer-events
property accordingly.
opw-2660786
closesodoo/odoo#83691
X-original-commit: 022a4486a99d855a3c6e2cef326bb3b0c5e66db9
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, it was not possible for a Buckaroo acquirer to
accept asynchronous notifications for payment updates. This is
important because, without them, an acquirer can only rely on
synchronous notifications (i.e. redirect requests from the provider's
checkout page) which can be unreliable and do not allow receiving
status updates, should payments take a bit longer to be confirmed by the
provider.
This commit adds a webhook controller whose route can be configured in
Buckaroo Plaza (backend) to send asynchronous notifications.
task-2687586
closesodoo/odoo#82922
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Co-authored-by: Lucie Van Nieuwenhuyze <luvn@odoo.com>
PURPOSE
Cleanup "Pay Now" notification template and their usage in "Send by email"
flows. Cleanup overall notification by email flow: rename methods, remove
outdated code, improve code clarity, prepare future improvements.
SPECIFICATIONS
Cleanup "Pay Npw" template: move buttons on the top, add subtitle, overall
cleaning of the content. It now looks more like the standard notification layout
with some model-based tweaks for invoices / SOs / POs, with less view-based
content.
Improve recipients computation: do it in batch, add more information when
fetching notification recipients information (follower status, lang, ...). Add tests.
Cleanup MailThread API and docstrings for notification methods. Improve flow
of values through notification methods. Make their purpose clearer.
Provide some master fixes for corner cases spotted while working on this
PR.
In any case see individual commits for more details as otherwise this message
would be a long concatenation of various purposes.
LINKS
Task-2712450 (Mail/Sale: Improve 'Pay Now' notification template)
Task-2726501 (Mail: Propagate message values in post methods)
Task-2732660 (Mail: Remove duplicate layout field on composer)
Task-2710804 (Mail: Clean Mail.Thread API)
Task-2739294 (Mail: Batch recipients fetch and improve its usage)
closesodoo/odoo#82167
Related: odoo/enterprise#23326
Related: odoo/upgrade#3142
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
PURPOSE
Allow to somehow decorate notification emails headers with a subtitle holding
the record name and some main informations.
SPECIFICATIONS
Next to access button in "Pay Now" notification email, display a subtitle
for some of the main "Send by email" based email flows. It should be something
like 'Invoice REF/01 \n35€ due 11/2022' for account.move or equivalent for
sale.order models.
Task-2712450 (Mail/Sale: Improve 'Pay Now' notification template)
Part-of: odoo/odoo#82167
When creating a new user, add a default signature if none is given. It
should be a simple one like
```
--
<user_name>
```
Implement it using an editable computed field based on name. That way users
can set it explicitly as void, but changing user's name sets a default one
when it is not set.
Task-2712450 (Mail/Sale: Improve 'Pay Now' notification template)
Part-of: odoo/odoo#82167
In this commit we get the old "Pay Now" behavior back that gives a standard
link to followers. It is done manually on sale order as it implements portal
rules. Follower group for notification layout is therefore activated.
Task-2712450 (Mail/Sale: Improve 'Pay Now' notification template)
Part-of: odoo/odoo#82167
Purpose of this commit is to add potential groups but de-activate them by
default. Indeed each group require about 20 queries for rendering and
sending. If no specific behavior (access button, content) is made for this
recipient group it can be included in lower-version of the group.
Specifications
* de-activate portal group in mail as it has no additional rights compared
to customers;
* add follower group but de-activate it for the same reason;
* activate portal group in portal_mixin and include links to the record in
notification emails, using standard mail/view link. ACLs are managed in
each specific model, generally based on followers;
Update a test in test_mail as it was playing with public and portal users
that are now not really differentiated when sending notification emails.
Better have more real-life scenarios with portal and internal users.
Task-2739294 (Mail: Batch recipients fetch and improve its usage)
Part-of: odoo/odoo#82167
Purpose of this commit is to improve notification recipients computation.
Code cleaning
* make it batch enabled. Currently it works only for a single record. It
should evolve towards real multi computation, allowing to prepare post
and notification in batch;
* better manage multi users. Now when several users are linked to the same
partner, we try to find an internal user or fallback on share user. This
is cleaned compared to a distinct done previously;
* support recipients without subtype (pids + records) as a new case to
include follower computation;
Improvements
* include follower status if linked to records (is_follower can be used
notably in link computation to redirect to the portal);
* fetch partner lang directly in the SQL query. While fetching partner data
let us add its lang. That way it will be easier to improve lang support
in layouts;
Task-2739294 (Mail: Batch recipients fetch and improve its usage)
Part-of: odoo/odoo#82167
Add a constraint directly at db level ensuring no duplicated notification
exist on partner / message pair, if partner is set. Partner can be void notably
with SMS notification process which may target numbers directly.
Task-2710804 (Mail: Clean Mail.Thread API)
Part-of: odoo/odoo#82167
Purpose is to have a white background like templates used in SO, invoices, ...
Task-2712450 (Mail/Sale: Improve 'Pay Now' notification template)
Part-of: odoo/odoo#82167
Purpose is to remove custom styling and use the 'Pay Now' notification layout.
Extra table is removed from template body (table with order name, 'sent by'
footer, ...) and only main content is kept. Some extra padding is removed.
Action now uses the 'Pay Now' email layout to add the access button, company
logo, footer, ... meaning it is now more standard.
An override of recipient groups and access button is also performed in order
to align header with email purpose. Link redirects to the /cart page (instead
of classic portal SO view for customers) and is labelled as 'Resume order'
(instead of 'Validate and Pay Order' used in portal).
Task-2712450 (Mail/Sale: Improve 'Pay Now' notification template)
Part-of: odoo/odoo#82167
* = sale, purchase
PURPOSE
Purpose of this commit is to improve the 'Pay Now' notification template
used notably when using the "Send by email" button on
* invoices
* sale orders
* RFQ and purchase orders
SPECIFICATIONS
Global specifications
* remove gray background that is around the white content (aka have an
email with an uniform white background);
* move button on top of email like other notification templates (top-left
and company logo is top-right);
* fix various small wording issues;
* fix signature usage;
Technical specifications
Remove custom definition of access links and labels in 'Pay Now' notification
template (``mail_notification_paynow``). It is now done at model level through
the ``_notify_get_groups`` that is generic to notification emails. This allows
to remove QWeb override in purchase and sale notably. Displaying access links
is now controller by the ``has_button_access`` value. Model computes links,
access and labels while view only displays what is requested. That way any
template can use those values instead of being defined in a template subject
to user changes.
Sale / Purchase
Overrides of those modules is not necessary anymore since button labelling
and URLs are managed at model level.
Purchase "specific" buttons for Accept / Update dates are now email layout
actions, like used in other modules like HR or Project.
Continuation of odoo/odoo#76418 .
Task-2712450 (Mail/Sale: Improve 'Pay Now' notification template)
Part-of: odoo/odoo#82167
This field is a duplicate of email_layout_xmlid and is actually never used.
Followup of odoo/odoo#76418 .
Task-2732660 (Mail: Remove duplicate layout field on composer)
Part-of: odoo/odoo#82167
* = account, purchase, sale
Purpose of this commit is to add signature only if really asked. A variable
is available for that purpose (``email_add_signature``, recently renamed from
``add_sign``). We also correctly check signature is not void or pseudo-void
using tool ``is_html_empty``. Indeed editor may generates pseudo-void content
like ``<p><br /></p>``.
As signature is not added when a template is used (see composer code) we ensure
it is defined in mail templates used in "Send by email" flows. Indeed we cannot
know if a template already has a signature or not. To avoid having twice a
signature no signature is added in email notification layout when a template
is involved.
Continuation of odoo/odoo#76418 .
Task-2712450 (Mail/Sale: Improve 'Pay Now' notification template)
Part-of: odoo/odoo#82167
In order to make fields a bit more explicit, let us rename "add_sign" to
"email_add_signature". It indicates it is linked to the email notification
process, adding the signature depending on the notification layout itself.
This is done on both mail.message and mail.compose.message models. It is
also updated as rendering value parameter used in notification emails.
Task-2712450 (Mail/Sale: Improve 'Pay Now' notification template)
Part-of: odoo/odoo#82167
Purpose of this commit is to make ``get_access_action`` private as it is not
necessary to expose it directly. Website management is also made explicit
using a ``force_website`` parameter instead of relying on context key of the
same name. This allows to better understand the method code flow.
Contains also some code fix / improvements :
* Website forum: update code to better skip the frontend redirection if the
forum is not active and frontend is not forced;
* Website slides: respect force website parameter in redirection;
Task-2710804 (Mail: Clean Mail.Thread API)
Part-of: odoo/odoo#82167
A method that actually runs on recordsets should not have a model decorator.
Even if there is no issue this is may be confusing.
Task-2710804 (Mail: Clean Mail.Thread API)
Part-of: odoo/odoo#82167
Purpose is to support portal parameters in ``_notify_get_action_link``. This
method generates a ``mail/view`` link that may redirect to frontend e.g. with
portal. We already support parameters coming from auth_signup and tokens from
portal. Supporting pid / hash allowing to post on documents using the frontend
chatter is the next step to generic links. This is just adding them to the
accepted like, not changing any current behavior.
Task-2712450 (Mail/Sale: Improve 'Pay Now' notification template)
Part-of: odoo/odoo#82167
If we call ``MailFollowers._get_recipient_data()`` with pids parameter being
set to None there is a crash that is easily solved( list(None), should take
list fallback before hand).
Task-2739294 (Mail: Batch recipients fetch and improve its usage)
Part-of: odoo/odoo#82167
Purpose of this commit is to add tests for recipients fetch. Purpose is to
assess current behavior before going into some cleaning or refactoring.
Notably when dealing with
* forced recipients (pids, aka 'additional recipients' in composers);
* subtype-based computation (internal, subtype follower);
* multi-users per partner (notably as a result of partner merge);
Future improvements will modify this method. Adding some low level tests
for it will ease development and checking differences.
Some tests are also regrouped in the same test class to lessen noise.
Task-2739294 (Mail: Batch recipients fetch and improve its usage)
Part-of: odoo/odoo#82167
Purpose of this commit is to add tests for language-based tweaks of email
notification layouts and composer usage. Purpose is to assess current
behavior before going into some cleaning or refactoring. Notably
* check layout content is translated;
* check "view document" button is translated;
* check action buttons are translated;
* check content based on templates is translated;
This is currently mainly available through the "lang" context key being
correctly set. Partial support of translations when posting based on template
is tested (content and model description but not notification layout).
Failing support in mass mail mode is tested. Future improvements will be
done in order to improve language support.
Note that ``MailTemplate.send_mail()`` email sending method language support
is tested in ``test_mail_template`` file. Those tests are updated to share
a common base with new tests about language setup.
Task-2712450 (Mail/Sale: Improve 'Pay Now' notification template)
Part-of: odoo/odoo#82167
PURPOSE
Purpose of this commit is to cleanup flow of values going through message_post
and its sub methods until email generation for notifications.
SPECIFICATIONS
Ensure some values are given directly when creating message linked to post
methods to avoid browsing message when value is not known. Notably make
signature propagation (add_sign) more explicit in message_post and its sub
methods (notify, log, ...).
Prepare future language related improvements by allowing to force company and
lang values for rendering context. Also add ``is_html_empty`` tool method to
use it in notification templates. It will be used notably to check for empty
html blocks, e.g. user signature.
Rename some internal variables to better understand their purpose.
Finally update some outdated and/or badly indented docstrings.
Task-2726501 (Mail: Propagate message values in post methods)
Part-of: odoo/odoo#82167
PURPOSE
Purpose of this commit is to clean notification email values generation
while keeping possibility to override and tweak values. It now has clean
hooks on base mail value and final mail values.
SPECIFICATIONS
Base mail value are values independent from recipients. It allows notably
to tweak values depending on current record without having to browse and
access record for every recipient, saving unnecessary computation.
Final mail values are recipients-dependent and are the values that will be
use to create the final ``mail.mail``. With a mechanism of optional additional
values + hooks for base and final values it should be possible to keep any
custom behavior already implemented with a cleaner interface and code flow.
See notably odoo/odoo@b1a5bf95f8 for example of why some code exist just
for hook purpose.
As a side note, light variable renaming is performed (email -> new_email)
to avoid shadowing email.
Task-2710804 (Mail: Clean Mail.Thread API)
Part-of: odoo/odoo#82167
PURPOSE
Global purpose is to rename some methods and add some docstrings to clean
API of notification methods used in mail thread. Notably use _notify_thread
prefix for main methods, and _notify_by_'mean' for tool sub-methods.
SPECIFICATIONS
Remove unused arguments coming from old implementation and usage. They were
introduced notably for performance reason when cache was more often invalidated
which is not the case anymore. Anyway when parameters are unused it is always
better to remove them.
Remove ``notify_by_email`` parameter in ``_notify_thread``. It is only used
in channels to avoid notifying people of some automated notifications. The
same behavior has been cleanly implemented at odoo/odoo@018820d .
Rename methods, starting with ``_notify(_records)`` to ease their grouping
and understanding. Add some additional prefixes like ``_notify_by_'mean'``
and ``_notify_get_recipients`` for recipients related computation. Add some
docstrings, notably when parameters usage is not clear.
Some linting is also performed in updated actions, just to lessen styling
issues notably on runbot.
This commit should not change anything functionally as it contains only
some renaming and docstrings updates as well as some outdated parameters
removal.
Task-2710804 (Mail: Clean Mail.Thread API)
Part-of: odoo/odoo#82167
Purpose is to better isolate MailThread related methods in those huge files
containing lot of code. Better have them located in a sub-section in order
to have all mail code at the same place.
Task-2710804 (Mail: Clean Mail.Thread API)
Part-of: odoo/odoo#82167
Update some counters at latest runbot results, just to have updated counters.
Note that some counters are somehow not deterministic, hence not updating
everything.
Task-2712450 (Mail/Sale: Improve 'Pay Now' notification template)
Part-of: odoo/odoo#82167
Before this commit the step about the slider to adjust the padding was
only consumed on click, which does not happen if the slider is used in a
drag'n'drop operation as expected.
After this commit this step is consumed on mousedown so that the
drag'n'drop operation is also taken into account.
task-2728994 (was task-2675252)
closesodoo/odoo#83692
X-original-commit: 42ce224fbe97f8d99ca5feec6d271412ce0647e1
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Before this commit the tip of the cover selection step was drawn outside
the display.
After this commit the tip of the cover selection step is within the
display.
task-2728994 (was task-2675252)
X-original-commit: 04df7addb41600e458495caa512342e9840e1259
Part-of: odoo/odoo#83692
website{_*}: website, website_blog, website_sale, website_slides
Before this commit if several steps were referencing the same trigger
(e.g. "+New" button in website) only one was displayed, but all were
consumed when it was clicked.
Because of this the tour steps on "+New" were active even when its menu
was opened.
After this commit only the displayed step gets consumed if the step is
marked as 'consumeVisibleOnly: true'.
It cannot be done implictly on all steps because of [1].
This new marker is set on all steps referencing "+New".
The tour steps on "+New" now also require their menu to not be opened.
[1]: https://github.com/odoo/odoo/commit/5e888f8a6ccf9996b3231db6bf314d045619109e
task-2728994 (was task-2675252)
X-original-commit: 0fa40e37e596798665a098ee999f49749b6012a2
Part-of: odoo/odoo#83692
Before this commit the tour only proceeded if the first image was
selected.
After this commit the tour proceeds if any image is selected in the
media dialog.
task-2728994 (was task-2675252)
X-original-commit: 92d7ad6d1c0b773a4a400b84bfc8d93c6980850b
Part-of: odoo/odoo#83692
Before this commit tips could be revived after being destroyed if a
resize event occurred, because the resize was being debounced and could
trigger a request to rebuild the bubble mode of the tip.
After this commit the resize debounce is cancelled if the tip was
destroyed in the meantime.
However another unidentified reason still manages to trigger an
asynchronous re-creation of the tip after destroy() is called, even
though all timeouts are cleared.
The following remaining sequence has been identified:
- mouseenter.anchor is triggered: but this is disabled during destroy
- it calls _to_info_mode() which registers the timer_in timeout: but
this timeout is cleared during destroy
- it calls _build_info_mode() which registers the _transitionEndTimer
timeout: but this timeout is cleared during destroy
- it calls _onTransitionEnd() which calls _updatePosition() which
revives the tip
Therefore an additional guard is added to prevent _updatePosition() from
being executed if destroy() was called.
Note that the mouseleave > to_bubble_mode chain being symmetrical to
this one, it is likely that it could also happen.
task-2728994 (was task-2675252)
X-original-commit: 635675398c153e123e62dd30a35ba23a29503c70
Part-of: odoo/odoo#83692
The currency rate could be different if the invoice date is different that the accounting date
Steps to reproduce:
1- Install l10n_ar
2- Create two different currency rate for foreign currency (i.e: Dollar) with also different Date
3- Create an invoice setting the currency as foreign currency (i.e: Dollar)
Current behavior before PR:
In page "Journal Items" could see that each account line use the currency rate defined by the accounting date,
however the currency rate filed (which is not visible) is defined by the invoice date.
Desired behavior after PR is merged:
Use always the accounting date to set the currency rate
+ CLA signing Augusto Weiss
closesodoo/odoo#83689
X-original-commit: 21692f28fd1db7097e1d4c23ce7dcbaa76936449
Signed-off-by: Josse Colpaert <jco@odoo.com>
This reverts commit f22364c32ac1438ededd611578b64a69186d7c9c.
- go to a partner
- click on the button "Sale"
- Create a new order
--> Issue you see all product archived (and all the python logique run
with active_test = False)
Since the original issue would be reintroduced, this commit apply the
active_test:false only if the search field partner_id is used.
closes#83600closesodoo/odoo#83669
X-original-commit: 825bb5f770f3abccadd3db3c4a57b25c3d9c35ed
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Co-authored-by: Nicolas Lempereur <nle@odoo>
Current behavior:
When using variant in PoS the price was not always correct
Steps to reproduce:
1. Set up items with modifiers (Modifier type must be of type variant creation mode : never, where adding a modifier leads to a different price than with the base item e.g. base item is 10 USD, modifier is 5 USD, total price is 15 USD;
2. Activate Product configurator and make sure it's a Bar/Restaurant in the PoS settings
3. Select the items with the modifier;
4. Leave the table and come back to the table
5. Change the quantity of this product
6. The price is back to the base price without the modifier
opw-2696529
closesodoo/odoo#83444
X-original-commit: d959dfada11a72d6bc275b35f5eeb06b045a0dea
Signed-off-by: Masereel Pierre <pim@odoo.com>
While updating financial reports to help avoid misconfiguration,
slightly update the coa to fix some wrong account types or name.
Tax id #2585627closesodoo/odoo#83268
Related: odoo/enterprise#19835
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Change the type of the account 5585 to be current
liabilities instead of non-current as it makes more sense.
Task id #2585627closesodoo/odoo#83266
Related: odoo/enterprise#19833
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Before this commit we could print the product labels of a picking from a
picking, but we couldn't print only the lots/sns. This commit adds in
this ability. Because we want to be flexible with this label printing
(i.e. have the option to choose between printing zpl or pdf + 1 per
unit or per lot/sn), we include it in the general "Print Labels" button
with additional wizards.
Note that we assume:
1. If there are no lot_ids in the picking => default to only product
labels wizard (i.e. this also means if a picking that only creates
New Lots/SN, lots/sns will not be printable until picking is
validated.)
2. Lots/SN PDF labels will only be in the 4x12 label format
3. Batch pickings can also print lot/sn labels
Part of task: 2494740
Related ENT PR: odoo/enterprise#23323closesodoo/odoo#82389
Related: odoo/upgrade#3202
Signed-off-by: Arnold Moyaux <arm@odoo.com>
When printing a done MO with a non-tracked finished product that doesn't
have a product barcode, an invalid zpl file is created (i.e. there is
no end to the label in this case). Instead of an invalid label, we now
write "No barcode available" to have a valid ZPL and to match what
happens in the PDF version of this label.
Part of task: 2494740
Part-of: odoo/odoo#82389
Previously the PDF product labels were not printing to any standard
label size/format. This commit makes it so they match the 4x12 format
(same used by Product Labels). Because of the dynamic number of labels
that may be printed (i.e. units have 1 label printed per 1 unit), this
template is much more complicated than previous template. Note that we
expect these labels to ALWAYS print in a 4x12 format (i.e. we keep all
logic contained within 1 template to avoid custom report/wizard python
code).
Also, this commit removes the logic for printing labels for products of
not 'Done' MOs since this didn't seem to be a possible situation (report
appears to always print blank in this case).
Part of task: 2494740
Part-of: odoo/odoo#82389
kwfx