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.
SAP sends out emails that only contain a PDF part, without a text or
html body, e.g.:
X-Mailer: SAP NetWeaver 751
Content-Type: application/pdf; name="Afleveringsbewijs.pdf"
Content-Transfer-Encoding: base64
Content-Description: Afleveringsbewijs
Before this patch, this single non-text part was parsed into the body of
the final message, as if it was a text part.
Making the check for the main part more restrictive solves the issue, as
there is no reason to assume that a non-multipart content is
necessarily of text/* type. This PR also includes a regression test.
Closes#21102
During the generation of data in kanban view, there are no rounding when
computing the amount differences. It might lead to amount differences
lower than the currency rounding, which should not be displayed.
It also fixes the case where the amount is -0.0.
opw-782962
Closes#17840
- Create a user B with 'Barcode' and 'Security PIN' set.
- Log in the POS with user A
- Scan the barcode
The PIN is not asked and the user is switched.
Closes#20760
opw-781360
Before this commit, when reconciling with a tax included line,
the journal entries were wrong as the amount taken into account was the one that was **already** computed with tax
e.g:
TAX: 20%
amount of the line (tax included): 1
tax amount: 0.17
base amount: 0.83
what was sent to the server was the basea amount, and since python re-computes the taxes
it reapplied tax included 20% on 0.83 instead of 1
After this commit, we send the right amount to the server,
at the small price of semantics change in the meaning of "amount"
OPW 783933
closes#21189
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
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
It seems that Authorize.net returns an 'Error' status when transactions
fail (note that it can also return an Ok status for different types of
failures).
This is incoherent with the way the authorize requests are processed,
since an Error resultCode will raise a ValidationError, rollbacking the
complete cursor transaction. This makes little sense, since there should
be a trace of the payment.transaction in the backend (preferably with an
explanation for the failure).
This fix adds an error processing step to the response handling of
authorize.net - while before, it was assumed that an 'error' result
meant an issue in communication/setup, now it is treated as an error
in payment and the payment.transaction status is set accordingly.
I've added a test for this and it was green (pinky promise), but this
particular test suite is deactivated (or perhaps only on nightly, I need
to check the nightly process with @nim-odoo).
When you import a record in Odoo, you can specify an id without
prefixing it by the name of the module. e.g. 'project_project_x'
The result of this is an empty string as module name.
(This value is valid for a required field...)
Plus, when you check metadata, you see 'false.project_project_x'.
Now, the default module name is '__import__' instead of an empty string.
We already have similar behavior with '__export__' triggered by
'export_data' method.
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
That operation was previously forbidden because it could be potentially costly as we may end up having to recompute the 'amount_residual' and 'amount_residual_currency' fields on a lot of account.move.line.
Basically, we now authorize it and manually handle the update of that field via a manual SQL query.
Was PR #19204. Was task 32125.
Remove the condition checking that the postal account field of bank accounts only accepts mod10r-verified references, as not all banks use such references (example: UBS).
Most field widgets are synchronous, but some of them have to do extra
work before being ready (for example, the pad widget, or widget which
needs to lazy load JS/CSS files). Because of that, the new views have
been well tested with synchronous widgets, but not completely with async
widgets.
Some code depended upon the fact that the widget was ready immediately
after being created. This was incorrect, and is fixed in this commit,
by adding a new hook that is called in (basic) views after a widget is
ready (meaning, start and willstart are done)
Most field widgets are synchronous, but some of them have to do extra
work before being ready (for example, the pad widget, or widget which
needs to lazy load JS/CSS files). Because of that, the new views have
been well tested with synchronous widgets, but not completely with async
widgets.
Some code depended upon the fact that the widget was ready immediately
after being created. This was incorrect, and is fixed in this commit,
by adding a new hook that is called in (basic) views after a widget is
ready (meaning, start and willstart are done)
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.
Example of failing request:
```
rpc.query({
model: 'link.tracker.click',
method: 'read_group',
args: [[links_domain, ['create_date', '>', interval]], ['country_id']],
kwargs: {groupby:'country_id'},
});
```
The RPC request built contains the following:
```
args: [[["link_id", "=", 1]], ["create_date"]]
kwargs: {groupby: "create_date:day", domain: [], fields: []}
```
This will be interpreted server side as:
```
model.read_group([['link_id', '=', 1]], ['create_date'], groupby=['create_date:day'], domain=[], fields=[])
```
2 arguments match `domain` and `fields`, which causes a crash.
opw-781300
- Open an event registration page
- Fill form for 2 persons => redirection to /shop/checkout
- Click Review Order => open /shop/cart
- Change quantity from 2 to 1
- Finish checkout process
- Login to backend, confirm SO
Two tickets are confirmed instead of one.
opw-783945
With this commit, we change the behaviour of the web client with respect
to spaces in char fields. Most of the time, starting and ending spaces
have no value, and worse, make the data not so reliable.
After this commit, field char will trim by default (so, if the user input a
char as ' abc ', the string 'abc' will be sent to the server instead).
Note that this only applies when the value of the field is changed. If
someone open a form view, then switches to edit mode and save, nothing
will change.
This is the desired behavior most of the time. However, in some rare
cases, this is actually harmful. For example, if we trim the
'decimal_point' field, it will not be possible to enter a whitespace as
decimal separator. In those cases, we introduce a new attribute 'trim',
which allow the developer to desactivate that feature.
It regularly happens that people do not close their POS session for a
long time. When too many orders are linked to a session, the session
closing duration can therefore take a lot of time to execute. This leads
to timeout issues.
We add a label on the POS session Kanban view if it has been opened for
more than 1 day.
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.
on pricelist, open a pricelist form
click on one country group [country group form opens]
click on a pricelist again
Before this commit, a traceback appeared, saying the pricelist record was null
YET the pricelist's form on which we clicked before opened.
After this commit, the form of the pricelist opens, and no traceback is thrown.
OPW 783896
[FIX] web: test circular many2many
closes#21148
Remove weird special case: when the first field of the first line of a one2many
is empty, replace this first field by the comma-separated names of the lines,
and discard the other lines.
*board,sale_timesheet
This rev. changes the API of load_views, as it now assumes that
the given context has no longer to be evaluated. This is more
convenient that way, as we can now call load_views with contexts
that are dict, and not instances of the Context class.
instead of createView. This allows to log info like RPCs or
uncaught Odoo events even if we are not in a view.
Also remove the logLevel param from MockServer as it wasn't really
used.
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]).
Thibault Delavallée