Purpose
=======
Currently if a project doesn't use pads, the created and duplicated tasks will initialize/copy them. That could be a real issue when migrating customers if we create a task for all the existing issues, since the models have been merged.
Specification
=============
Avoid this falsy behavior. We're forced to crappy fix with a context key as the project.task model 'inherit' from pad.common.
Before this commit, saving a file being watched by watchdog
(--dev=reload) with vim (and possibly other text editors) would
crash the server via a KeyboardInterrupt error.
This happens because vim, emacs cause multiple filesystem events to
happen when saving a single file, the FSWatcher registers these events
as multiple SIGHUPs which in turn calls restart() multiple times in a
very small amount of time which makes the KeyboardInterrupts completely
shut down the server
This is fixed by only calling restart() if odoo.phoenix is False, since
catching a SIGHUP sets it to true.
Fixes#21178
Special thanks to @odony for the help :)
* In Python 3 xlwt apparently does not support writing bytes values ->
try to decode assuming the value may be base64-encoded, this is more
or less the behaviour for CSV exports.
This will most likely not allow the export anyway as Excel cells are
limited to 32k data characters, which accounting for base64
expansion means ~24k worth of data, but that is a pre-existing
issue.
* Also removed support for way outdated browsers from
content_disposition: the Safari case is for Safari 5 (circa 2012)
but versioning apparently changed since then and modern Safari
report their "external" version number rather than the webkit
version number => the current Safari reports version 11, and gets
routed to the "does not support unicode file names", which is
further bugged in Python 3 as it %s's bytes, leading to a resulting
filename of e.g. `b'res.partner.csv'.csv` (with the prefix and
quotes).
* The IE case is for IE8, which has long been unsupported by the web
client.
This commit implements the same fix already made in commit https://github.com/odoo/odoo/commit/a5ca63c83beafd9a060ac58d3b4c6a9a987b28df, but this time applied to the tree view of the sale order lines, instead of the form view.
Without this fix, if you add new lines in the sale order by using the tree view (instead of the form) you can get the following error:
```
Odoo Server Error - Validation Error
The operation cannot be completed, probably due to the following:
- deletion: you may be trying to delete a record while other records still reference it
- creation/update: a mandatory field is not correctly set
[object with reference: product_id - product.id]
```
The error is because the "product_id" value is not sent to the server. The "product_id" value is mandatory for sale order lines.
To reproduce the issue, you need to reproduce the following scenario:
- create a new sale order and save it
- edit the sale order; you should be able to edit inline the sale order lines (by the tree view)
- create a new product, being sure that the field 'product_id' is readonly (field 'product_updatable' is False).
- try save the sale order
See detailed explanation of the issue in description of commit https://github.com/odoo/odoo/commit/a5ca63c83beafd9a060ac58d3b4c6a9a987b28df.
PR #21211
When the result packaged is changed on a move line, we should not change
the reservation of quants, because result_package is not related to
reservation, only package_id is used during the reservation.
We also changed the copy of move_line when we split a move line to put a
part of it in a package. By copying the move line and set the
product_uom_id in the default values of copy function, we mess the
reservation, because there is no quant reservation made for the move
line even if the move_line has a product_uom_qty. So we set the
product_uom_qty to 0 when copying the line, and then write the
product_uom_qty which will call the quant reservation
Fixes#20784
When using this module, the default behavior is to generate timesheet.
This timsheet is linked to a project and a task and there is a
constrain that verify that the task and project are set on model.
If another module (like l10n_fr_hr_payroll for example) tries to
create holidays.status without a project and task, it causes a
traceback.
This commit adds default values for these fields in order fullfill
the constrains.
Notice that the order of the imports in the __init__ is important
because the columns have to be created on the res.company before the
status is initialized.
Usacase to reproduce:
- Plan MO with 2 unit to produce.
- Produce 1 unit
- Update the quantity to 1
-> Traceback
active_move_lot_ids should have been changed to
active_move_line_ids during the forward port to 11.0
from this commit d62b307597
Use case to reproduce:
- Create a BOM with a component product tracked by SN
- Create a MO for this product and reserve it.
- Plan WO and process it.
- Register the same lot than the reserved one.
-> Error message: you can't use twice the same serial number
It happens because WO use temporary move line that should not
be considered as a real object. However it exists is a constraint
that trigger if two move lines share the same SN for the same product.
It's a wanted behavior that a real move line share the same SN that
temporary move lines.
This commit prevent real and false move lines comparaison.
Otherwise, when rendering the 'Product' template it crashes when calling
the 'get_price' method.
Indeed, we need to add products as a Product model instead of as a plain
JS object.
Use case(stock_picking.py):
- Sell a product which has tracking enabled
- Reserve the stock on the delivery order and assign to all stock.move.line a lot/serial, but leave the qty_done zero
- You will get an error message which is not correct
(stock_quant.py)
Give more information about the source of failure
opw:783828
Since odoo/odoo@da136d8 the modifiers in the widget attrs are parsed.
`stringify` thus needs be to used when displaying them in the debug tooltip (to
avoid to display [Object object]).
Before this fix:
A readonly monetary field was not updating
its currency symbol when selecting another currency.
Scenario:
1. Activate multi-currency with $ (default) and €
2. In hr_expense, go to My Expenses to Submit
3. Create a new expense
4. Select 'EUR' as currency
=> Unit Price is correctly updated with €, but not Total.
With this fix:
Total displays the correct currency in edit mode.
Explanation:
Monetary fields in readonly are relying on _formatValue() to
display their value.
_formatValue() uses this.formatOptions.currency, which stores
the currency at loading of the field. We must update its value
whenever there is a change of currency.
opw-783378
Steps to reproduce the bug:
Setup Authorize.net test account, then go to My Account from portal
and select "Manage your Payment Methods" and add a new card.
Bug:
It raised "Please fill all the inputs required."
opw:782716
The rev. odoo/odoo@93bf26a modifies the way kanban record defines their size.
Kanban dashboards used to define a fixed size and reset it when grouping.
This fixed size should in fact only be set for ungrouped kanban as the column
size is fixed.
Before this revision, unlinking a module which has been uninstalled at
least once would raise an Exception because base_module_uninstall
contains a field model_id which is required. The unlink method of
ir_module_module would try to set this field to NULL which is of course
a constraint violation.
This is fixed by manually unlinking the respective base_module_uninstall
records before the unlinking of the ir_module_module record itself
Fixes#20720
DO NOT FORWARD-PORT
Since the stock valuation refactoring, the price_unit on out move are
negatives. This brought an issue when _anglo_saxon_purchase_move_lines
tried to get the amount of the accounting entry in the stock received
account when validating a credit note for a return: as the price_unit
total resulted in 0, the entry was taken from the price difference
account.
Fixes#20840
opw 781836
When building the enterprise packages, some data files were ignored.
With this commit, the demo data and missing xslt files are packaged.
This fixes#21045 and fixes#21015
That variable seems a remaining piece of old code that now doesn't
have any use and makes to compute twice the tax table each time
you print the report.
Closes#20569
Rev [1] was intended to be applied when changing the lot of the produced
product on the manufacturing order, somewhere along the line the code
was also called when setting the lot_id on the work order. When used in
this context, it broke the reconciliation between the reserved move
lines and the temporary move lines because a lot_produced_id was wrongly
set.
We fix the issue by only applying the code on prod move. This is done by
checking if the move is a production one through the stock move, because
there we are able to differenciate the raw material and production move,
not on the move line where production_id is always set.
[1] 471115b06aFixes#20964
Before this fix, when adding the attribute delete=0
on a listview, it was still possible to delete records
via the menu 'Delete' in the sidebar.
After this fix, this should not be possible to delete
records when delete=0.
The attribute delete was hard-coded to true, as there was
a traceback when it was set to false. It was simply due
to a misplaced closing brackets that was hiding an
assignment, which resulted to calling a method on undefined.
Before this fix, when adding the attribute delete=0
on a listview, it was still possible to delete records
via the menu 'Delete' in the sidebar.
After this fix, this should not be possible to delete
records when delete=0.
The attribute delete was hard-coded to true, as there was
a traceback when it was set to false. It was simply due
to a misplaced closing brackets that was hiding an
assignment, which resulted to calling a method on undefined.
Martin Geubelle