Description of the issue/feature this PR addresses:
Creation of backorders only when needed
Current behavior before PR:
- When the option "No Backorder" was selected, a backorder was created then cancelled.
Desired behavior after PR is merged:
- When the option "No Backorder" was selected, no backorders are created.
( Task ID : 46981 )
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#27624
- The docstring for the method `create_backorder(self)` was updated to a more convenient one.
- The kwargs `backorder_moves` was remove since it was useless.
Before this commit, when the user chose to not make a backorder, a backorder was created then immediatly canceled.
This behaviour is now changed as in such a case the backorder is simply not created anymore
- The docstring for the method `create_backorder(self)` was updated to a more convenient one.
- The kwargs `backorder_moves` was remove since it was useless.
Before this commit, if a JS module caused an error while being
evaluated, the error was silently swallowed (and only logged in debug
mode, in the extra information about the state of all modules).
With this commit, we always log the error in the console. Note that
this only applies to JS execution errors. If a file has invalid
javascript structure, then a parsing error will happen, even before the
module system has the possibility to do anythin.
closesodoo/odoo#27836
Before this commit, it was not possible to map one tax to multiple taxes
in the point of sale, just as it is in the account module.
This commit implements fiscal positions that can map to various taxes
on POS.
Furthermore, id adds test to secure that somewhat implicit feature on which
several localisations seem to depend upon.
A typical use case if one tax is not replaced but complemented by another.
**Description of the issue/feature this PR addresses:**
- Taxes can only be replaced in POS.
- Not complemented by a peer tax.
- Behavior not aligned with backend fp mapping.
**Current behavior before PR:**
- Tax cannot be mapped to several taxes (aka: complemented: "to itself and other") on POS
**Desired behavior after PR is merged:**
- Tax can be mapped (aka: complemented) to various taxes on POS
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
@xoe-labs
closesodoo/odoo#26415
Usecase to reproduce:
- Create a BoM that create more than 1 finished product
- Use a routing
- Open the BoM structure report
The operations time from the routing are multiplied by the quantity show
on the report.
It should not happen since routing's operations are not by unit.
If a user create a BoM that produce 50 finished products then the
operation time is always the same when the user produce between 1-50
units. It then double from 51-100,... (workorder use the same process
for the expected duration).
This commit fix this behavior by using a rounding up on the
quantity asked on the report / BoM product quantity.
It also take care of the workcenter capacity.
opw-1890005
Previously broken symlinks would cause a FileNotFoundError
exception in the filesystem watcher thread spawned when using the
--dev=reload argument.
This problem appeared when using emacs to edit python files while
they are being watched by an odoo instance for changes. Emacs
creates a broken symlink as lockfile in the same directory as the
python file that it edits.
This commit makes the filesystem watcher silently ignore any
FileNotFoundError that occurs when it tries to open a file.
Fixes #21214, closes#21215
The reconciliation widget must provide visibility on black lines having an account in
a different bank journal.
Example using Paypal:
Invoice:
Receivable: debit=x, credit=0 matching_number: A
sales : debit=0, credit=x
Payment transaction:
Paypal : debit=x, credit=0 matching_number: B
Receivable: debit=0, credit=x matching_number: A
Statement line payment:
Bank : debit=x, credit=0
Paypal : debit=0, credit=x matching_number: B
The file stock_config_settings_views.xml is not mentioned in the manifest, and
it is wrong as the model `stock.config.settings` which does not exist anymore
closesodoo/odoo#27540
When sending notifications by batch one notification email can be send
up to 50 people. For one mail_mail entry to handle 50 emails can be sent
as those are sent independently for each recipient.
In some cases a bounce may occur while the whole batch of recipients is
not completely mailed. In that case the mailgateway will update the
notification status to bounced. When the cron finishes to send the whole
batch of emails it tries to update the notifications of all recipients.
However as a notification has already been updated due to the bounce we
face a concurrent update, meaning the transaction is rollbacked.
Emails have been sent but notifications are not considered as sent as they
have not been updated accordingly. Next time the cron runs it will send the
same batch again, with probably the same bounce and rollback. We could
therefore face an email loop.
This commit fixes that by setting notifications to a transient exception
state. Notifications are locked, meaning bounced will have to wait for the
transaction to finish before updating them. That way the cron can run
safely on the whole batch and we avoid having emails loop. It has an impact
on query count as a search and write is performed in the send process.
This commit is linked to task ID 1893054. Done in collaboration with
@Xavier-Do .
The code ignored return of return when computing the delivered quantity
of a so line (in this part of the code, if a move has a destination
location set a customer, it'd be a return of return of a delivery).
We now update the delivered quantity is the return of return as the
`to_refund` flag enabled, meaning the user ticked the option to update
the quantity on the so line.
opw-1884683
Linked to task 1887993, related to the de-magic-ification of the "admin"
user: currently data files are "executed" as the root user, re-linking
relevant records to the admin user is a PITA (e.g.
97b82ff7c1).
Just executing all demo files as the admin is not feasible (some things
a regular user literally can't do), but the ability to execute entire
data files as a specified user or with specific context keys set, and
furthermore override that at the function/record level, is useful.
This:
* refactors some of convert_xml to prep for the rest
* cleans up and fixes the handling of uid/context to use them in record
and function tags and properly inherit them from data parents
* cleans up some of the rng & conversion code (unused features, dead
code, broken features, …)
closesodoo/odoo#27383
* ir_set and url were accepted by the RNG despite ir_set having been
removed back in 2015 or so and <url> having possibly never existed in
the first place (could not find any reference to an <url> element
outside of sitemap qweb templates)
* <assert> was essentially deprecated/removed in 2015 with the v9
accounting having stopped running account_assert_test.xml, which was
the last file using the tag so far as I can tell. The file itself
remained as dead code until 2018
Use the same pattern as for the envs: a stack of noupdate values pushed
and popped around data nodes.
Avoids re-parsing the same noupdate attribute on every node execution,
and completely removes the need to pass the nearest data node to every
_tag_ function.
* add tests for uid/context on record & function & root nodes (odoo,
data, openerp) "inherited" by record & function
* add rng validation to the test cases to ensure technical
capabilities are matched by validation capabilities (which was not
the case as we could validate nonsense and import stuff which didn't
pass validation or something)
* extact uid/context into its own rng pattern
- add uid support to record validation
- add uid support to root nodes validation
- fix uid support on function validation: was typoed to @id, which
is not used anywhere in function tags loading & makes no sense
as far as I can tell
* replace get_uid/get_context by get_env & reimplement the whole mess:
build a stack of environments from the root nodes (each root node =
one env in the stack, though the exact same env can be present
multiple times if none of the root nodes has a @uid or @context) and
leaves can build upon this "ready made" environment for their own
uses or use it as-is.
As a result, all uid/context should now properly transfer from the
root nodes to the leaves needing them
* fix support for context on functions: was not actually implemented
as the context was not propagated into the old-style API call
* add uid support to record & context is now inherited from env
* add _tag_ methods for root nodes (remove some of the parse special
casing)
* remove unnecessary/useless returns
* remove cr & uid (there's an env)
* remove mode argument from callbacks (redundant and confused with
self.mode)
* try to cleanup menuitem callback a bit
* make second callback param not optional (because it's not)
- Activate the `group_website_multiimage` in the website settings
- Add several images on a product
- On the eCommerce, click on the second image, then the first one
The click on the first image doesn't work.
This is because `t-att-data-slide-to="0"` is removed from the attributes
(probably because evaluated as falsy).
opw-1884368
Co-authored-by: Nicolas Martinelli <nim@odoo.com>
Let's assume a one2many editable list containing a many2one field
(e.g. in a sales order, the product_id m2o in order_line o2m), and
the scenario where the user clicks on 'Create and Edit' in the o2m,
and then presses ESCAPE in the opened dialog.
Before this rev., it crashed because the 'navigation_move' (cancel)
event wasn't stop propagated by the form renderer (the one of the
dialog), and thus bubbled up to the list editable renderer, which
asked its basic model to discard a record it didn't know.
Note: same fix as in 8445baa (done in saas-11.3), but with a
simpler test.
Task 1878254
If resetting a background color was the only edition that was done on a
page and that this page was saved, the change was not properly saved
as the page was not marked as dirty.
Closes https://github.com/odoo/odoo/pull/27625
task-1879524
Let's consider an aged partner balance with a period of 30 days as of
2019-02-08. The specific dates used in the report are:
``` python
bisou = datetime.strptime('2019-02-08', "%Y-%m-%d").date()
for x in [0, 1, 30, 31, 60, 61, 90, 91, 120, 121]:
print(x, bisou + relativedelta(days=-x))
0 2019-02-08
1 2019-02-07
30 2019-01-09
31 2019-01-08
60 2018-12-10
61 2018-12-09
90 2018-11-10
91 2018-11-09
120 2018-10-11
121 2018-10-10
```
However, the current periods generated are incorrect:
```
{'name': '0-30', 'stop': '2019-02-08', 'start': '2019-01-09'}
{'name': '30-60', 'stop': '2019-01-08', 'start': '2018-12-09'}
{'name': '60-90', 'stop': '2018-12-08', 'start': '2018-11-08'}
{'name': '90-120', 'stop': '2018-11-07', 'start': '2018-10-08'}
{'name': '+120', 'stop': '2018-10-07', 'start': False}
```
There is a clear inconsistency between the name of the period and the
date used. Moreover, the name is misleading: 0-30 includes the -0 date,
while 30-60 doesn't include the -30 date.
After the fix, the name and the periods are consistent. We also change
the first period to 1-30 since including 0 would mean to include amounts
which are not due yet.
```
{'name': '1-30', 'stop': '2019-02-07', 'start': '2019-01-09'}
{'name': '31-60', 'stop': '2019-01-08', 'start': '2018-12-10'}
{'name': '61-90', 'stop': '2018-12-09', 'start': '2018-11-10'}
{'name': '91-120', 'stop': '2018-11-09', 'start': '2018-10-11'}
{'name': '+120', 'stop': '2018-10-10', 'start': False}
```
opw-1886633
closesodoo/odoo#27294
The stock refactoring between version 10.0 and 11.0 changes lots of views
in the inventory app. The picking form view lost in the refactoring the
'note' field.
This commit put it back in the view under the 'Additionnal info'. It was
not been removed from the pdf reports
closesodoo/odoo#27658
In Firefox, the input behavior and visual representation (navigation, caret
placement, value selection, etc.) was broken when using a datepicker (easily
reproductible on date and datetime widgets).
This was due to the `focus` event being stopped on the input, which doesn't
seem to be correctly supported by Firefox.
The deleted code was supposed to toggle the picker when the field was clicked
(see odoo/odoo@89093a1) (toggle on click and disable focus) but the lib
correctly supports on focus without extra code.
This also fixes the fact that the datepicker was not open on focus (only on
clicked). In some tests where the field was the first in the form view, it is
now correctly autofocused.
Forward-port: not useful from 12.0 because the code has changed with BS4 and
this has already been applied in odoo/odoo@6692919 and odoo/odoo@c63630d.
Closes#23438closesodoo/odoo#27657
When there are many values, the axis would be unreadable.
We also added a margin so that the values would be displayed entirely,
as opposed to cropped in the middle of a word.
opw 1890109
closesodoo/odoo#27656
65;5401;1c
Line contains the value returned by a select clause on inventory lines.
postgresql result returns None instead of False when no value is set.
Avoid having a stock_histories_by_group dict with a key to None
Having a None value is problematic as the key is used based on the read_group
result returned by the super call above.
e.g. grouping the inventory history by lot numbers, while some moves have no
inventory, used to produce a KeyError
Closes#27591
Since this module is not bridged to website_sale_delivery, there was no support for changing the freeshipping line
when changing the delivery carrier
Now it has, at the price of ugly code
OPW 1871526
closesodoo/enterprise#2651
Steps to reproduce the bug:
- Create Product P: with BOM type - Kit and BOM components > Set - Invoicing: on delivered quantity
- Create PO with P and confirm - shipment 1 will be generated
- Cancel the PO - shipment 1 - will also get canceled
- Reset the canceled PO to quotation and confirm it - new shipment 2 will be generated
- Validate the shipment and receive product KIT
Bug:
Check PO - 'Received Qty' was not updated
Inspired from: https://github.com/odoo/odoo/commit/c2dfdc3081764a492a94024f1fb57e15636b04c9
opw:1889303
closesodoo/odoo#27622
If a user creates a paperformat, he should be able to modify it too.
Employees have no reason to modify the paperformat though (nor create).
Having a malicious employee modifying an existing report may be dangerous.
[CLA] signature for stijnh92
Fixes#26292closesodoo/odoo#27444
Purpose: improve understanding of project model as well as their
daily use. This is done by improving tooltips of some fields
according to business logic.
This commit is related to task ID 1885507 and closes PR #27019.
On Safari, when editing the template of a mail.mass_mailing,
clicking the "Read more" button (or any button that can
have a link to the website) didn't open pop up to set
the URL of the website.
PS: inspired from https://github.com/textAngular/textAngular/issues/762
opw:1889643
Martin Trigaux