Commit 6494f51171 introduces an access token to read images inside an
email. This avoids access errors when accessing the email through a
proxy (e.g. Gmail). That implies that all images are added as
attachments.
When going through the usual media dialog, the form is submitted to
action '/web_editor/attachment/add', creating the attachment. However,
the copy or the drag and drop of an image completely fails. Indeed,
the same method `_onImageUpload` is called, but with a completely
different argument type: `attachments` is a `FileList`, not a list of
attachments.
To solve this, we only call `_onImageUpload` on a the custom `onUpload`
callback, which is not triggered during a drag and drop or a copy. Any
image included thanks to these methods will be post-processed in the
`create` method of `mail.message` (`base64_to_boundary`).
Unfortunately, it's not possible to simulate an actual drag and drop or
a copy, so we cannot add a test.
opw-1840237
opw-1840411
Recently, rev. c0809dd41 removed a protection in the reload of
Kanban views with progressbars. This protection ensured that the
manual reload of the progressbars was only done when one of the
records of the Kanban view was updated (and not when a column, or
the whole view was).
However, removing it highlighted a bug linked to the manual reload
of progressbars, which messed up the list of ids in the
environment. As a consequence, for instance, if the user archived
the records of a column, and then opendc a record in form view,
it couldn't use the pager anymore.
Besides fixing this bug, this rev. re-introduces the protection,
and refines it to prevent 2 useless RPCs when the whole Kanban
view was reloaded.
opw~1841276
opw~1841342
New records (with a NewId) are not necessary in the cache, but should
not be prefetched.
This check has been omitted during optimisation in b0c08a6846.
opw-1843566
opw-1843636
opw-1843683
opw-1843548
opw-1843629
opw-1843657
Closes#24595
* 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
Users will be more likely to look for a module named email marketing
than they would be searching for a module named mass mailing.
Task #1825294Closes#23634
The goal of this change is not to be able to search a location_id/warehouse_id
but to properly make these fields "dummy": only used to put some keys in context
from the search view in order to influence computed field.
Use case:
In function _compute_quantities_dict, the quantity available for a product is computed
according to the warehouse or the location. But to compute this quantity, the specific
warehouse or location must be in the context.
Steps to reproduce:
- In the tree view of product.product, write the name of a warehouse W
- Click on dropdown menu "Search warehouse"
- Click on W
Expected behavior: the quantities available for W are displayed.
NB: search=lambda operator, operand, vals: [] must be written to
ensure these fields to be searchable. Otherwise "Non-stored field
product.template.warehouse_id cannot be searched." was logged.
opw:1839961
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
When we change the the uom of a product, a user error is triggered if
there are already moves created for this product. But if the product is
archived, the call to mapped('product_variant_ids') doesn't return any
product ids, so no moves are found and you can change the uom.
To fix this behaviour that can lead to bad configurations, because
quants and moves won't be in the same unit than the product's one.
- Go on the partner form view
- Click on the stat button 'Invoiced'
- Create an invoice
The partner is not filled in.
Overlook of 1f277a3572
opw-1839867
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).
Use case to reproduce:
- Create a BOM with a byproduct tracked and a routing
- Mark the last workorder as done
- by products move line are not created
With the wizard produce (MO without routing) move lines
are created. Thus there is an inconsistency.
It happpens because workorders and produce button do not use
the same function. commit 1a09bcc622
already fix it for production wizard however it forgets workorders
process.
opw-1838707
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
When creating an activity, the date saved will be the choosen one in the
tought in the client timezone.
But when displaying the counts of activities Late/Today/Future, the date
is tought out as the one in the server timezone.
Thus we would have activity today/future/late not corresponding with the
date in the current timezone.
This is solved in this change and follow what was done in 72254129.
A second change is made so the default "Due date" is today in the
timezone and not today in UTC date.
opw-1837894
closes#24554
- Create a bill for partner A of an amount X
- Create a bill for partner B of an amount Y
- Validate both bills
- Select both and register a payment by check.
Two payments are created with the same amount in words: X + Y.
In this specific case, we recompute the amount in words automatically.
note: this commit reintroduce the fix c52b18e65 which was lost after
changes in 10.0 (line was removed then brought back with 416d07f0b).
opw-805842
closes#24569
Before this commit, the compare button from the customized view "Alternative
Products" would create the URL by joining `alternative_product_ids` which are
ids from product.template.
But the route /shop/compare is supposed to receive variants (product.product)
IDs.
Thus, it would try to search given product.template IDs in product.product
records.
It would then show incorrect items or no items at all if the ID does not exist.
Now, we create the URL with the first variant (product.product) of the
product.template.
Obviously, the first product.product is arbitrary but we can't retrieve all the
variants ids, it would most of the time returns too many items.
opw-1840321
In a situation where there's a negative quant next to a positive one,
they should be merged when the scheduler runs or when the user open its
inventory view. However, if in the meantime the user reserves and
unreserves, there may be some issues.
The system will only reserve on positive quant ;
the system will unreserve on the first encountered quant (even negative)
The issue is the second part of the early break condition:
float_is_zero(available_quantity, precision_rounding=rounding):
The issue here is `available_quantity`. In a reservation scenario, it
represents the maximum quantity we can reserve across quant. It is
useful so we do not lose time loopin over quants where nothing will be
available. In an unreserve scenario however, it represented the same
thing, which is wrong. In the case you reserved all the quantities,
`available_quantity` will be 0 we'll loop only on the first quant where
we won't do anything.
As the code doesn't check the success or failure of the unreserve, move
lines were unlinked while the reserved quantity on the quants were not
updated, resulting in the desynchronization of the move lines/ reserved
quantities.
This continues the work done at [1] to track down the "cannot unreserve
more than" errors.
[1] cce6030c0d
Assume a one2many field inside a form, displaying field A in its
list view, and a field B in its (dialog) form view. Moreover, there
is an action button in the dialog, which updates the value of B.
Before this rev., B wasn't correctly reloaded when the button was
clicked, because the BasicModel reloaded the fields on the list
view (i.e. field A), whereas it should reload the fields in both
views.
This fix is twofold. First, we force the viewType to 'form' when
the record is reloaded, instead of the default ('list'), so that
fields in the form view are correctly reloaded. Second, when we
open the form view in the dialog, we add the fields of the list
view to the dict of fields of the form view, so that the form
is aware of those fields and can ask the model to reload them
(still without displaying them).
Fixes#24189
When the virtual machine used to build MS Win package takes too much
time (to build or to test the build), a warning is logged and the VM is killed.
Before this commit, the PID of the process was passed as an argument to
the warning method, causing a traceback.
Instead of searching for ids in the whole cache, search for the ones we will potentially prefetch.
Example: imagine you have 1K records in cache, and only 3 records in your prefetch set. Instead of retrieving the 1K records that have a value in cache, retrieve which of the 3 records that have no value in cache.
The precision digit on the produce lines is not set to the product unit
of measure one. That can lead to a lost of precision when a small values
are set in the manufacturing order and not in the produce wizard.
OPW-1838077
When moves of a MO are generated, they are rounded up to the decimal
precision of the rounding, what is not done in the wizard.
So to keep it consistent, we also round up the quantity to consume in
the wizard.
If document viewer is opened from chat window and when document viewer is opened then focus
remains on it's modal, pressing escape should set focus back to chat window's input element,
if file selecor dialog is opened and if user press ESCAPE on file selector dialog to cancel file selector
dialog then it should not close chat window instead it should set focus on chat window input and on
second ESCAPE key chat window should be closed
also increase z-index of document viewer dialog so image remain on top of cht window
OPW: 1777937
When an internal locations has its `scrapped` field set to True,
reserving will increment the quant's `reserved_quantity` while
unreserving will bypass the reservation mechanism (as in a supplier
location). This leads to a desynchronisation between the
partially_available/available move lines and the quant's
`reserved_quantity`, leading later on to "cannot unreserve more than
available" errors.
To prevent this kind of issues, there's a `should_bypass_reservation`
method set on the location that we *should* use everywhere, it was
implemented by [0]. Sadly, this line was not adapted since its
implementaton in [1].
Co-authored by len-odoo <len@odoo.com>
opw 1837900
[0] e1cea2640f
[1] 0469d2e712
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
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
When creating a transfer from:
Dashboard > Planned Transfer
The scheduled date is not configurable as explained in commit:a57a290bd89bee0c50c9c1b03e7185c0497e89ed
opw:1838620
Nicolas Martinelli