Mercury can partially approve transactions in case a card does not
have enough credit available to cover the full amount.
Before this the payment amount was kept as the full purchase amount
leading to a difference between what Mercury charged and what Odoo
registered as charged.
opw-1840946
Before this patch the registry and cache signaling was only activated
for PreforkServer. In case Odoo was deployed in a multi process/multi
threaded architecture the signaling was not ensured, causing registry
de-synchronisation amongst threaded servers.
Commit bcd4c90 was intendend to make get_file handle uncaught/unserialized exceptions
in the context of a http request
The drawback is that when get_file received a serialized exception (route: /report/download)
the JS modal was empty in that case
This commit handles both the cases
OPW 1848606
closes#24794
This patches fixes the untested and broken draft of inetd and systemd
activation support in the threaded server.
This patch also fixes the loss of the process environment in the
`_reexec()` function when Odoo is respawning during the following events:
- SIGHUP signal is received
- one click install has been triggered
- code reload needed when using `--dev=reload`
The field quantity_done_store had the same label as the field product_uom_qty
on model "stock.move" and there were confusions in the pivot view of
"stock.move".
opw:1841097
Make an account move with two move lines.
In those lines' label, just hit the space bar, and post your entry.
Now, get the FEC report.
Before this commit, the EcritureLib field was empty
After, it has the value '/'
closes#24734
open a pos,
change cashier
hit F5
Before this commit, the previous user was set as cashier, forgetting about the change we made
This was because of two things:
- The original fix to do just this use case was pushed in v9.0 as e14ab69
- In v10.0 the commit 475027b
(For v11.0: a9caef0)
Was intended to update the res.users objects at their loading to ensure that their access rights were loaded too
But it did this using the wrong condition
After this commit, it reworks fine
OPW 1844006
related #24762closes#24764
Suppose we have a delta between two datetimes:
delta = dt1 - dt0
If delta is negative but less than a day, ``delta.days`` returns -1 (which is
compensated by positive seconds). In order to avoid this surprising effect,
use ``delta.total_seconds()`` to compute the number of days.
In case we define a field like,
<field name="my_domain" widget="char_domain" context="{'active_test': False}"/>
when selecting records the dialog should display all records (as asked by the
context), but it's not the case.
This commit ensure the field context is passed to the selection dialog.
opw-1831902
The field signup_valid is a non stored computed field based on signup_token.
The cache is filled with prefetched values, so in a loop the field is read from
the cache and not recomputed due to the missing dependency.
opw 1843442
This commits removes a disambiguation on the choices of the 'Adjustment Type' selection as 'in your favor' could be achieved by debitting the 'Collected Tax' account or creditting the 'Paid Tax' accounts (respectively for 'in favor of the Estate'). The choices now refers directly to the journal item where the tax is gonna be copied
Related to https://github.com/odoo/odoo/commit/c58ef14a01f600d75391f2a9c38bb2b30e0e2528
Related to OPW 1826242
Display a slide, enter fullscreen mode
Make the navigation bar appear.
Now, try to push on any button of the nav bar
Before this commit, none of the button work
This is because the fullscreen mode is handled by the browser, and won't let any non-fullscreen
elements be interactive
After this commit, the nav bar is part of the element that are in fullscreen
And the button work
OPW 1839503
closes#24522
In 9.0, stages of a job position in recruitment are not share by
default, there is a "New" stage and existing stages can be added in the
form view (since 780f46ae).
When creating a job position, the "New" is not working with the given
widget type.
This commit doesn't show stages in the form view until the record is
created.
opw-1839217
closes#24706
If the user configures a default `template_id` for
the `mail.compose.message`,
this template was used by the mass mailing to render the email,
and, among others,
it therefore used the `email_to` of this email template,
to render the recipients,
and it was configured empty or something else than `object.id`,
it did not used the `active_ids` passed in the context to the
`mail.compose.message` `create` call to compute the correct
recipients
To reproduce:
- In developer mode (?debug)
- Open the full mail compose message
e.g. in app sales, open a so, hit new message,
and hit the button to open the full message composer
- Set the template to the quotation template is not there already
- In the debug menu of the dialog, View > Set defaults,
- Click the radio button to all users, and the default to Use template = ...
- Then, try to send a mass mailing. It will fail because it cannot
compute the `email_to` values correctly because the `email_to`
of the quotation template is empty.
opw-1840287
- Set a specific expense account on an expense product
- Send an email to the expense alias
The specific expense account is not used; a default account is used
instead.
opw-1838174
In firefox, if we have a range on eg.:
`<input type="file">`
and we tabulate to get to it, we have the range over:
`<button type="button" tabindex="0">Browse…</button>`
which seems to be a "virtual" element inside the `<input/>` but this
magic element is "Restricted" and causes error such as:
`Permission denied to access property "nodeName"`
So this fix ignore errors when getting a range from current selection on
keyup.
opw-1819279
closes#24524
Open a pos session with a user A
Change cashier to user B
Make an order with invoice
Before this commit, the salesman of the order was user B
but the salesman on the invoice was A
After this commit, both invoice and order have user B as salesman
OPW 1844175
closes#24642
It seems that in v8 the internal reference (the code) of the product
was displayed in the sales details report of the pos
This commit put that field back on the report
OPW 1844776
closes#24641
Some IPs (like google-proxy ones) are not bound to a specific country.
Legacy Database used to set country_code to 'EU' for these one. geoip2,
on contrary, does not set the country. Read information from `continent`
attribute in this case.
opw-1844888
The transcoding of a mail (transforming CSS into inline styles on the
element nodes of the mail) used the form:
property:value;
So when a mail is saved, it would be eg. with `style="property:value;"`
and when it is being edited "property:value" is removed if available via
CSS stylesheet given the structure.
But the sanitize_style (introduced in bfe7aafa7) adds an espace before
the value (which is more pretty but was probably not choosen in
transcoding to decrease size of mail):
property: value;
so the inline style would not be removed when editing possibly causing
conflict with the editor.
With this commit, the sanitize_style doesn't add a space. It could have
been changed in transcoding but the code is already rather slow and we
don't want to use a regex replace or two string replace instead of the
current one string replace.
opw-1841107
The browser may throw an error when a big mail such as one with
hundreds thousands of tags is being transformed to have a style
more compatible with mail clients.
The error would be:
"Uncaught RangeError: Maximum call stack size exceeded"
This happens in jquery because we hare too many nodes (there is an
ongoing issue at https://github.com./jquery/sizzle/issues/403) so this
commit replace that part by a DFS traversal over DOM nodes.
There was also an issue that not having the option "style-inline" would
still cause some style code to be ran albeit it was intended not to be
solved in 55c7d2d5b0.
opw-1841107
closes#24550
* Avoid to invalidate the cache if no actual deletion has been
made when recomputing the taxes
* Avoid to create analytic entries to delete them right away
few lines further in the same method:
- Analytic entries are created at line 903
- account_invoice.py:751 `move_line_dict['analytic_line_ids'] = [(0, 0, line._get_analytic_line())]`
- account_invoice.py:840 `iml = inv.invoice_line_move_line_get()`
- account_invoice.py:886 `line = inv.group_lines(iml, line)`
- account_invoice.py:894 `'line_ids': line,`
- account_invoice.py:903 `move = account_move.with_context(ctx_nolang).create(move_vals)`
- Then, at line 907, they are deleted and others are created again:
- account_invoice.py:907 `move.post()`
- account_move.py:130 `move.line_ids.create_analytic_lines()`
- account_move.py:1258 `self.mapped('analytic_line_ids').unlink()`
- account_move.py:1262 `self.env['account.analytic.line'].create(vals_line)`
Deleting these analytic entries indeed implies the invalidation of the cache.
Besides, generally speaking, we should avoid to waste resources
by creating/unlinking records without a good reason.
When the reception route of a warehouse company is deleted by the user
e.g. My company, Chicago Receipt in 1 step is deleted,
and then changing the given warehouse `Incoming Shipments`
multiple times
e.g. from `one_step` to `two_steps` multiple time,
the reception route is created again and again and again.
This is because the reception route which is created for the
warehouse is not being assigned to the warehouse
as the `reception_route_id` once newly created.
opw-1836544
Steps to reproduce the bug:
- Create a SO with 2 lines and confirm it
- Set a Customer reference on the SO with "This is, a ref"
- Deliver it
- Create an invoice from it with all the invoicable lines
Bug: The name of the invoice was: "This is, a ref, This is, a ref"
Expected behavior: The name of the invoice is: "This is, a ref"
opw:1840738
Christophe Simonis