Mass Mailing campain cannot use Mail Templates anymore (the user now
has to duplicate a previous Mass Mailing if he wants to start a new
one with a mail body which looks like the old one).
So this menu became useless and confused the users. Mail Templates are
a technical feature which is used by other module to send automatic
emails and these can be edited through debug mode in the Settings app.
Resolve#14148.
Without this patch, when a product was added to cart, if this addon
was installed, it always landed in English in the SO.
This happened because the context, containing the current language,
was being aborted here (`context=None` instead of `context=context`).
This commit closes#14340
When a picking is partially available, and the company works in 'just in
time', they often need to re-check the availability of some products
just before sending them.
In 8.0, it was totally possible, to recheck the availabilty of products.
To fix this, we just add a button when the picking state is 'partially
availbale', which does exactly the same as 'Reserve', but is secondary
and contains the label 'Recheck availability'.
Updated the deployment documentation, to inform developers about
the new location of the odoo-wsgi.py file that's needed
go deploy odoo as a wsgi application
Closes#14337
This reverts commit 897290dd3f.
It seems it breaks other use case, since this was fixing more a
usability thing (need to click back on code view to save code view
changes) it is better to revert than to add drawback.
A better fix should be introduced, or the solution would be to not fix
it and have a warning indicating what needs to be done.
opw-693052
Commit a572b8115c removes the inverse function of the `date_planned`. This
is necessary to avoid unexpected changes of the scheduled dates.
However, this removes the ability to set the scheduled dates of all
lines at once.
This commit introduces back the functionality thanks to a new button.
This way, the functionality remains without unexpected behavior.
Backport of rev: https://github.com/odoo/odoo/commit/2cf80e00752c68e443b0cd442ee50f7d6daaa455
opw-692873
A misleading behavior occurs with the recomputation of scheduled date.
Here is the use case:
- Create a PO with 2 products
- For the product 1, set the scheduled date to today + 7 days
- For the product 2, set the scheduled date to today + 14 days
When saving, the scheduled date of product 2 is reset to today + 7 days.
This is of course unexpected, but moreover, a different behavior can
happen depending on how the scheduled dates are modified. In the
previous case (both products have now the same scheduled date), one can
observe 2 situations.
Case 1.
For the product 2, set the scheduled date to today + 14 days and save.
In this case, the scheduled date of product 2 is not reset.
Case 2.
- For the product 1, set the scheduled date to today + 8 days
- For the product 2, set the scheduled date to today + 14 days
In this case, the scheduled date of product 2 is reset to today + 8 days
when saving
The reason of a different behavior in the 2 situations is that the
scheduled date of the PO is changed in case 2 and not in case 1. Since
the scheduled date of the PO is changed, it triggers the inverse
function `_inverse_date_planned`.
When saving, it is not possible to know whether the scheduled date of
the PO was changed on purpose by the user or recomputed. There are 2
solutions to get a consistent behavior:
- Force the scheduled date of each line to be the same than the
scheduled date of the PO. However, this makes the scheduled date of
the line useless.
- Do not change the scheduled date of the lines when the schedued date
of the PO is changed. However, this removes the ability to reset
automatically the scheduled date of the all lines at once.
This is the second solution which is chosen with this commit.
opw-682934
opw-684063
Closes#12904
Backport of rev: https://github.com/odoo/odoo/commit/4326d864d83125abc8f82dfb0089021abf22f9ca
opw-692873
This is an oversight during the port of
3de53fa165
in the forward port revision
3a2147d95c
In the revision 3de53fa165,
the code has not only been moved,
but the variable passed to the method `rereserve_quants`
argument `move_ids` changed as well.
This has been missed during the port of the revision.
This leads to the invalid computation of the `done` quantity
in the pickings in some cases were the quants need to be
re-reserved.
opw-690244
When Anglo-Saxon accounting is activated:
- Use two different accounts for Input/Output for Stock Valuation
- Create a vendor bill ==> by default, the Input Account for Stock
Valuation is used
- Validate the vendor bill
- Refund the vendor bill
When the refund is created, the Output Account for Stock Valuation is
used. There is actually no obvious reason to use this account instead of
the account originally used.
opw-691571
- Create two expenses
- Group them in one expense sheet
- Remove one item from the sheet (trash icon)
- Save
The expense is completely deleted.
opw-693548
- Remove 'optional' informations in small screen
- Disable ecom popup on xxs device
- Don't disturb customer during checkout, we remove the footer and extra right
column during the checkout step, address step and payment step.
Confirmation page - remove useless label
Don't center total in xs width
Don't display wizard in xs width
Remove dublicate border in xs width
Show sorted by label
task-28865
When getting the price from a account.move.line, the uom set
on the line must be taken into account.
Before the fix:
-Set anglo-saxon accounting
-Create two units of measure Box and Mot where 1Mot = 10Box
-Create a stockable product with Box as unit of reference and set with
real price and perpetual
-Create a SO with a Mot of this product
-Confirm the SO and create the invoice
-Validate the invoice
Bug:
In the journal of entries, only one box was counted for the debit and the credit
instead of 10.
NB: The function _get_anglo_saxon_price_unit must return the price unit of the
product in the unit of measure of the account.invoice.line.
opw:693075
It seems Paypal does not always send the same responses on auto-return
even when PDT is off. Although not reproducible on a Paypal sandbox,
sometimes the system auto-return to /payment/paypal/dpn without any
meaningful POST data. This seems to only happen with new accounts
that use the 'Hermes' web application of Paypal.
The correct thing to do would be to add a new field on the paypal
payment provider for PDT token and make the PDT flow available
to users; but this is a stable branch and this fix is already
sufficiently delicate. This shall be done in master though.
From this revision on, users can then activate PDT on their paypal
account, set the PDT token as an ir.config_parameter value (WITH
GROUP RESTRICTION SET TO ADMIN/SETTINGS GROUP!!!) and the system
will process these requests correctly.
test_sale_stock_lead_time.py compares dates and expect them to be the same.
Sometimes, the dates would differ by a second, because they are generated at
different moment during the execution.
This commit adds a tolerance of 1 second when comparing the dates.
(and changed from comparing Datetime strings to comparing timedeltas)
test_sale_stock_lead_time.py compares dates and expect them to be the same.
Sometimes, the dates would differ by a second, because they are generated at
different moment during the execution.
This commit adds a tolerance of 1 second when comparing the dates.
(and changed from comparing Datetime strings to comparing timedeltas)
qsm-odoo