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
When a record is created in a different language than English, empty
translations are created using the _set_ids method for translatable fields.
l10n_multilang makes the account translatable, an empty translation is created
when the CoA data is processed.
After the CoA installation, l10n_multilang transfer the translations of the
account templates to the related accounts.
No need to create translation terms again, use _set_ids to update the existing
translations.
This will prevent a cause of translation duplication, forbidden in the future by
160d657704
opw-1832071
Closes#24158
Before this commit, we had the following issue with binary widget in a form:
Suppose we have a binary field with filename attribute set. When uploading a
new file 'temp.txt' with content 'Cg==', the displayed value is 'Cg=='. When
the changes are saved, the displayed value becomes 'temp.txt'.
It should always display 'temp.txt', which is what is fixed by this commit.
In addition to fixing this issue, we describe what is the expected displayed
value of a binary field. This is based on whether the attribute filename is
provided, and whether the record is in edit or read-only mode.
Fixes#21630Closes#24275
Co-authored-by: Nick Booker <nick.booker@opusvl.com>
When a move or move line is supposed to use the company currency, its currency_id field is empty. _compute_matched_percentage did not take this into account, causing the rounding method to sometimes be called with a precision equal to False, resulting in erronous and weird behavior (0 was considered different from 0, causing a division by zero in the following condition).
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.
_update_routes should work the same way than _create_routes,
it should return new value to write on the warehouse.
based on preliminary by Denis Ledoux
opw-1836544
This constraint was added during the Great Accounting Reform of v9, in
an attempt to help users avoid reconciliation mistakes.
It turns out that such mistakes are difficult to make in normal
situations, since the system only offers matching entries to reconcile,
so the constraint is largely redundant.
On the other hand, it does block legit cases of reconciliation,
such as those where a large number of lines with different partners are
reconciled together. This often happens when reversing a Journal Entry
that encompasses multiple customers, such as a POS closing entry, or a
manual entry.
To make the system more flexible, let's consider that when a manual
reconciliation breaks the "single partner" rule explicitly, it's for a
good reason, so we should allow it.
OPW: 1840437
Backport of 8e73023f68
When we edit a list view and change page before the change has been
savec, the saving and page changing will be done concurrently thus
possibly causing an error if the page is changed before the saved is
finished: the save will try to modify the page that is no more
displayed.
In this change, the list view editable wait for the saving to be
finished before reloading its content.
note: for 9.0 up to saas-15
opw-1839149
closes#24471
- Create a product named 'toto'
- Perform a call to `name_search`:
`self.env['product.product'].name_search('pouet', [], 'not ilike')`
Product 'toto' doesn't show up in the result list.
The domain should take into account that `default_code` can be `False`.
Note: the bug also occurs if the product is called 'trululu'.
opw-1837957
In the wizard for payment several invoices with one payment, there was a
error when making the previous fix: 29c6c06de7.
The patch still worked because of a particularity of readonly and
related on account.payment but the check_amount_in_words would possibly
not be set when it should have.
opw-1839720
closes#24476
The copy-paste feature of summernote was messy and led most of the time
to breaking the template you were trying to edit. While it is difficult
to solve as it mostly comes from the lib itself and that the lib is in
a complicated state as Odoo had to overridde part of its internal code
for its own purposes, this commit hopes to solve the problem by updating
only the copy-paste feature to the latest summernote version.
Of course, as summernote changed a lot meanwhile, it was not possible to
just take the up-to-date summernote file. This commit refactores the
up-to-date summernote clipboard code so that it fits the old summernote
version Odoo is using.
Note: the main problems occurred while using Windows/Mac and not Linux.
opw-1837818
- Create a message with 100k+ smileys
- Send it to a colleague you hate
- His (and your) web browser starts eating up all the memory
- Go cry to the technical guy because you can't use Odoo anymore.
On some browsers, like Chrome, the image rendering consumes a lot of
memory up to the point it makes it unusable.
opw-1831610
In firefox the range when doing CTRL+A is the first level content of the
contenteditable element, but this was not taken into account when
"remembering" the range after clicking on buttons or features of the
editor.
In chrome the selection begin with the first displayed element (so it
may not be a direct child of the editable and is taken into account in
the code).
opw-1824017
closes#24424
Steps to reproduce:
-Create company A
-Create company B
-Admin user with both companies but currently in company B
-Create Demo user only with company B
-Create fiscal position A to company A
-Create fiscal position B to company B
-Create vendor with fiscal position A with company A and the same vendor with fiscal position B in company B
-Create product and add the vendor created before
-Set like Create a draft purchase order
-Logging with Demo user
-Create sale order with one sale order line with route make to order
-Validate sale order
Bug:
The purchase order created by sale order had the fiscal position company A.
Backport of this commit: 5bb6517072Closes#23561
opw:1825098