Before this commit, you can set the question of a post like the post itself.
That will generate a traceback:
RecursionError: maximum recursion depth exceeded in comparison
Now we check that there is no recursion
This commit fix an access right issue when a user that belongs to account.group_account_user (and not to account.group_account_manager) imports a bank statement file.
Was PR #25041. Courtesy of Alexis De Lattre (Akretion)
Steps to reproduce the bug:
- Create two products P1 and P2 requiring a lot
- Create a BOM B for P1 and requiring 3 P2
- Set on B a routing with a work order
- Create an inventory adjustment with 2 lots for P2:
- Lot1 with 20 P2
- Lot2 with 10 P1
- Create a MO for 10 P1
- Start the production and create a current lot Lot3 in Current Production sheet
- Set as current Qty 5 with Lot3 as current lot and Lot1 as Product Lot
- Click on DONE
- Set as current Qty 2 with Lot3 as current lot and Lot1 as Product Lot
- Click on DONE
- Set as current Qty 3 with Lot3 as current lot and Lot2 as Product Lot
- Click on Done
Bug:
When you checked the produced qty on the MO in the Finished product sheet, it only displayed 5 instead of 10.
opw:1849796
Purpose
=======
In the website_sale.product_variants template, for the "checked" attribute in the radio input,
it must be " checked' if variant_id_index == 0 else None " instead of "' checked' if
variant_id_index == 0 else '' ".
For this moment, it checked the last variant because we get " checked="checked" " for the
first and " checked="" " for the others.
Specification
=============
Use None instead of '' for the checked attribute if it shouldn't be checked.
Purpose
=======
Currently, users have to retype email in the stripe payment popup.
For event registration, the email address must be typed 3 times (the first
for the registration information, the second for the billing information
and finally for the payment on the stripe popup)
Specifications
==============
As the email is already filled on billing information view, isn't
necessary to retype in the payment form.
Currently there are 3 ways of going out of the modal: clicking cancel
registration, hitting the close button or clicking outside the modal.
The latter one however does not trigger the close event for modals and
therefore buttons of event registration are not reset correctly. This
commit fixes that behavior by preventing to close modal by clicking
outside of it. Buttons should be used and flow is now fixed.
Closes#25174 .
The duration field on a workorder computes the total time spent on it.
The mrp_time_counter widget that is used to display it only computes the total
time spent on it by the currently logged user (ignoring the field stored value).
To help the user understand the inconsistency between the two values, we add a
help tooltip.
Since this really depends on the widget used to display the value, the tooltip
is directly put in the view.
opw 1854802
Before this commit one could choose any journal for the registering exchange rate differences.
That could lead to accounting errors down the line
After this commit, we apply a domain on the field, and there is no problem afterwards
OPW 1851616
closes#25101
The percentage computation of statistics only uses the consumed ratings
>= 1 (through `rating_get_repartition`), while the initial search of the
first 100 ratings doesn't have this restriction. It leads to an
inconsistency between the ratings displayed and the percentages
computed.
Moreover, if there are less than 100 ratings, the percentage might not
be a natural number => use of float and round.
opw-1854863
Before this commit, the complete list of orders of the pos session
was processed through the reconciliation mechanism to check if an
automatic reconciliation was possible (introduced in a controversial
'bug fix' at fe70f07, itself a backport of a master commit at
a2319b4). The goal of this auto-reconciliation was to avoid potentially
silent and numerous customer statements that could be reconciled
automatically.
This is mostly useless in a lot of cases, since a lot of users do not
set any partner_id value on the pos order - there is nothing useful to
reconcile. Going through the whole list of orders is time-wasting
(especially since the reconciliation method does not scale well).
Combine this with users who do not close their POS session often enough
and closing a session can suddenly take up to several hours to process
instead of several seconds with practically no obvious gain.
After this commit, only orders which have a partner set on them will be
auto-reconciled.
opw-1818838 and opw-1817172
Make one Payment
Reverse the entry of this payment.
Before this commit, only the lines in the receivable were reconciled.
The lines in the liquidity were'nt, leaving the two entries appearing
in some reports
After this commit, the four lines are reconciled two by two, even in the liquidity
account
OPW 1816641
closes#25026
If the `web.base.url` contains a trailing `/`, the replacement of the
`/unsubscribe_from_list` link won't work since the string to replace
will be `my_url//unsubscribe_from_list` instead of
`my_url/unsubscribe_from_list`.
Fixes#24731
opw-1848572
In 11.0, this change e9454e79 solved the use case of:
- opening the registration of a ticket
- discard
=> the page must be reloaded to register a ticket
A new report is that since 9.0, if we try to register 0 ticket we would
also have to reload the page.
This commit backports e9454e79 and solves the 0 ticket registration.
10.0 version of 9.0's #24966
opw-1851622
closes#24991
In 11.0, this change e9454e79 solved the use case of:
- opening the registration of a ticket
- discard
=> the page must be reloaded to register a ticket
A new report is that since 9.0, if we try to register 0 ticket we would
also have to reload the page.
This commit backports e9454e79 and solves the 0 ticket registration.
opw-1851622
closes#24966
Commit https://github.com/odoo/odoo/commit/2eb344f23b3a9daa8e7c7ddaead145a8b05b39bf changed the dependancies of l10n_fr_certification which is not acceptable on stable. Instead, the method to check is now moved in account module (to avoid duplicated) and it is called by l10n_fr_certification and account_lock module.
Module account_lock has been introduced by:
https://github.com/odoo/odoo/commit/2eb344f23b3a9daa8e7c7ddaead145a8b05b39bf
A new constrains appears on the lock dates: their must not be set
after the last day of the previous month.
Then, it breaks the test on closed period that set the lock date 'yesterday'.
Have a mrp.production that you cancel, and delete the finished products lines
Before this commit, the computation of the sale_name crashed because we did
an index selection on an empty recordset
After this commit, there is no crash
opw 1851217
closes#24923
Have a XMLReceipt with the line:
<barcode encoding="CODE39">123456789</barcode>
Print the receipt.
Before this commit, jibbrish characters were printed and also kinda 'broke'
the spacing between commands
e.g. If you add an EAN13 barcode below the code39 it would have failed to print correctly too
After this commit, everything prints correctly
OPW 1849284
ref: https://reference.epson-biz.com/modules/ref_escpos/index.php?content_id=128closes#24965
The number of characters must be taken into account to print the
barcode. With 13 characters -> EAN13, with 8 characters -> EAN8 else
-> Code128
Backport of 12b11c1e6f
opw:1849965
Somehow the function treated multiple records with
the new api translation from 9 to 10.
Steps to reproduce:
This applies to delivery orders and manufacturing orders. As an example:
Create an MO with 2 products on the BOM
Both products must have real time costing with FIFO
The first product on the bom must not be available
For the second product on the BOM, the standard_price must be different from the cost of the next quant to be consumed
Complete the MO, letting the first product result in a negative quant
Current behavior:
The standard_price of the second product on the BOM does not get updated.
Behavior after this fix:
The standard_price of the second product on the BOM gets updated.
Thanks to matt454357.
When a t-field element was in an editable t-ignore environement,
modifying it was leaving the edit mode style attached to it. This
was because of:
1) When the t-field element was changed, it was marked dirty but
also its parent editable container. Fixing this, only solves
the case where only the t-field (and not one of its neighbors)
is changed but it was worth fixing anyway.
2) Before saving an element, the potential 'o_editable' and
summernote classes were not removed of its descendant and were
thus saved.
Bug found with task-38069, merged in stable as it might occur there
too.
closes#1800442
Purpose
=======
Odoo sessions are expired when no action has been triggered
for the last 7 days. For kiosk mode, this doesn’t make sense.
It means that once a week, a person with the rights to the
employee under kiosk mode, has to come to the screen and log in again.
Specification
=============
Trigger an action to keep the Odoo session alive.
product.product inheritS from product.template, and they both
define the 'standard_price' field, but implement it differently;
- product: the field is a company dependent one (so non stored)
- template: the field is a computed one based on tis variants
For the first case, since the field is not stored in database, when
doing SQL query, we have to get the value from the table ir_property.
That is what purchase report does, but instead of searching on resource
'product.product', it does it on 'product.template'. There are
obviously no entries in ir_property table for 'standard_price' field
on product template. As consequence, the "product value" (cost)
is always null in purchase reporting.
This commit fixes that by modifying SQL query to get the good
value from ir_property table.
When installing the website with a lang different than the one set
on the user, the button unsubscribe in the mass mailing snippets
didn't work because the unsubscribe link contains the code of the
language. The function send_get_email_dict in model mail.mail didn't
expect this behavior and so couldn't set the right unsubscribe link
in the mail.
opw:1850696
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
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
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
Swapnesh Shah