Method `get_day_work_hours_count` can return 0 if no attendance is found
in the calendar. Therefore, we must make sure to not divide by zero,
otherwise, boom boom.
Closes#22900
opw-1815095
The change in 3ae382f8d3a caused a similar error to ef91c141f6.
So the tour failed in enterprise because account_taxcloud caused a
customer tax to be added to the "Orange Butterfly" product.
Since the method `_get_leave_intervals` assumed that field `tz` is always filled in.
There is a case in default function, when `self._context` had key `tz` but its value was `False`,
which may causes null value of field `tz` and lead to mismatch interval between leave and payslip
This is more a architecture fix than a bug fix. With this commit, it is easier to modify the behavior of the dialog using the super function. like this: this._super.apply(this, arguments).opened(...)
PR #23255
Due to this commit: 3267e76520
Steps to reproduce the bug:
When registering a payment for a customer invoice in an other currency than
the company currency and marking it as fully paid, it raised an error:
"Wrong credit or debit value in accounting entry !".
Reason: counterpart_aml['debit'] and counterpart_aml['credit'] were both incremented
and it violated the constraint credit*debit=0
opw:815465
The function _prepare_invoice_line_from_po_line has not been
designed to compute in a right the quantity for a line in an
in_refund invoice. So it has no sens to display the field purchase_id
for a refund vendor bill.
Closes#23095
opw:816717
In case the discount product is misconfigured and therefore not loaded
by the POS, a traceback appears when applying a discount.
Add a comprehensive error message instead.
opw-817527
Several issues:
- If product `product_product_consumable` was deleted, an error is
raised.
- The default values are inconsistent with the fact that
`module_pos_discount` is `False` at POS creation.
- The domain should ensures that both `available_in_pos` and `sale_ok`
are `True`, otherwise the product won't be loaded by the POS.
opw-814426
The test_mimetypes and base_import modules need various files for their
tests. Before this commit some of those files (.ods, .odt, .xlsx, .docx,
.zip) were not included in the packages.
Fixes#22778
Commit a0f8ee92c3 solved the use case where
a quotation was created through the website shop and where the default quote's
template's require payment should be transmitted to the quote.
However, this commit made the field readonly
This present commit solves both problems by assigning a default to the problematic field
rather than computing it
OPW 817510
Commit 985c224 introduced a way to properly uninstall these two modules,
however if a user were to reinstall them the views would stay inactive,
in the case of sale_management this would mean some menus were missing,
in the case of account_invoicing this meant that not even the top-level
menu would not appear, effectively misleading users into thinking the
module was not installed.
The solution is to create a post_init_hook (to ensure that all
potentially missing menus are already installed) that activates the
previously deactivated menus.
Fixes#23245
Before this commit:
User timezone would be taken into account when displaying message date on
chatter. It would always display the hour in the server format (UTC).
Now, we correctly use the user timezone to format the date being sent by the
server.
This closes#22812
The POS recomputes order lines when the pricelist changes. This is
different from the sale app on purpose: in a usual POS flow the customer
and thus pricelist is selected after taking the order.
But users commonly use a 'Miscellaneous' product when they are selling
something that is not in their POS system. The user can select this
product and manually set the price. When now a customer is
selected (even if the pricelist has not changed) these miscellaneous
order lines get recomputed. So now the cashier is forced to input
these prices again.
To avoid this we keep track of lines that have had their price changed
through the UI and we don't update them.
opw-817353
When validating a vendor bill, we want the product
with expense policy set to be reinvoice on the open
sales order matching the analytic account of the invoice
line. Applying the same mecanism for customer invoice
does not make sense, as we might confirm a SO and validate
its invoice, we don't want a new SO line to appear (avoid
loop).
Unfortunately, since a long time, this is possible in Odoo,
and really make no sense. We should only take negative
analytic lines (coming from vendor bills and expense, not
the customer invoice) into account for adding SO line.
This commit correct this problem to avoid having
many null SO line created on customer invoice validation.
All test cases are correctly written, but there was no
check to prevent this mecanism to be apply on customer
invoice.
Purpose
=======
The warrant cost formulae has been modified at 5d22170.
Instead of using the (remaining) warrant costs formulae, use the corresponding field instead.
Issue:
domain="[('date','=',time.strftime('%%Y-%%m-%%d'))]"
is converted into a domain equal [('date','=','%2017-%12-%12')]
instead of [('date','=','2017-12-12')]
Odoo 11 comes with unified features for Project Tasks and Project
Issues. Specifically, issues were retro-fitted into tasks, and saw their
specific features added to the features of tasks.
During this refactoring, the portal controller for issues was superseded
by a unified portal controller for tasks, via
623ea43268
One case was lost in the process: portal visibility of
tasks/issues/things that are individually followed by customers, without
the customer following the project itself.
This is important for `transversal` projects, such as a "Helpdesk"
project common to all customers, where each customer only sees their own
issues.
This commit restores the feature, previously added to issues by
1cc8252a95
Note: this clearly requires a proper regression test, to be added soon.
When sending notification from the frontend, if a template is rendered
for it and the user has the group "website.group_website_publisher" he
will get inherit_branding adding on elements things like:
data-oe-id="42" data-oe-model="ir.ui.view" data-oe-field="arch"
but the chatter system has feature automatically redirecting an element
that have attribute "data-oe-id": this caused for example that a
link notification towards the forum would instead be redirecting to
editing the view of the notification.
This fix distinguish the inherit_branding in the chatter feature and
ignore them.
opw-813333
closes#23225
- Enable multi-company: without sharing products and partners
- Create 2 companies (company1 and company2)
- Create 2 users one for each company
- Create inventory transaction (receipt) by user1 in company1
- Create inventory transaction (receipt) by user2 in company2
- Using user2 run inventory valuation report with 'At a specific date'
option.
You got read access error for product.product.
This is due to commit 5c5098f740. We should apply the `ir.rules` to
the query.
opw-816663
- Create a custom field
Field Type: monetary
Tracking: Always
- Install any module
A crash occurs in `_instanciate_attrs` since `attrs` is `None`.
In some special cases, the instanciation of the attrs of a field is
delayed at the very end of the setup. For example, in case of a Many2one
for which the comodel is not yet loaded.
Therefore the override of the method should take this case into account.
Closes#22922
opw-815185
Before this commit:
1. When enabling 'List View of Variants' on a product page, it would not
replace the variant normal view as it should since the code being replaced
is included in the code replacing it.
2.The badge specifying the price difference between the variance and the
product base price would be calculated by taking the price_extra of the
variance attribute and converting it in the user currency which was not
correct if a pricelist was set on the product variant because the price diff
would then be (the variant price set on the pricelist) - (product base price)
Note: this is about the 'List View of Variants' mode, not the normal mode
which list variant attribute and not variant itself
3. The strikethrough amount was not in the user currency
Step to reproduce:
- Enable variants & pricelists
- Enable multi-currency and activate 'COP' as second currency (you may want
to change the currency symbol on edit mode since it is also '$')
- Go to iPad Retina Display product page in shop
- Enable 'List View of Variants' in 'Customize'
- Both Variants selection mode are visible (bug 1)
- The third variant shows '+$ 50.40' which is the diff between the
strikethrough prices (in fact the sum of the price_extra of the product
variant attributes, +50,40 on the 32GO attribute in this case)
It should show '+$ 40.32' since the price change from $600 to $640.32.
This is bug n°2
- Change Public Pricelist currency from USD to COP
- Back on iPad page, change between the 3 product variants, you will see
the $ price strikedthrough instead of the COP one:
Strikedthrough: 750 (it should be 1 714 491,47)
Price: 1 371 593,17
This is bug 3
- You can notice the bug n°2 being more visible since it shows
'+$ 115 213,83' instead of '+ 92 171.07'
- Remove the iPad Retina from Public Pricelist and add iPad Retina 32Go
variant to it with a fix price of $1 000 000.
- '32Gb, 2.4GHz, White' variant cost $1 000 000 but shows '+ 115 213.83'
instead of '- 714 491.47' since the base price of Retina is
'1 714 491.47'.
- You can play with the pricelist price for this variant up and down, the
diff price shown in the badge will always be 115 213.83 since it will
always calculate it by summing all the variant's attribute price_extra
and then converting it to the user currency.
This closes#14094, closes#22553
When creating an extra move, the price_unit field was not copied. It is
normal since the field is copy=False following rev[0].
But there was a side effect: let's say you order 1 product @ $10 and you
receive 5. The received quantity field on the purchase order line is
correctly set to 5 and the valuation inside the stock is correctly set
at $50, but on the picking there is one move line of 5 and a move a 4
and of 1, instead of one of 5. Note that in v10, the pack operation
would be split between the original move and the extra move, but in our
case the extra move is merged back in the original move, so we don't
need to split the move line. The split mechanism is there only when
working with moves without picking[1].
The issue here is that the moves are not merged because they do not have
the same price unit (5 and 0). We thus copy the unit price when creating
the extra move.
When creating a backorder, the price_unit field wasn't copied either.
It's not important when working with the classic flows (the link to
purchase_line_id is kept), but to be consistent we also copy it.
[0] https://github.com/odoo/odoo/commit/a4740861d3fdbecc8b1171b7d2072697e8a36258
[1] https://github.com/odoo/odoo/commit/561b3461a020021d911999cb41154f158b069a1d
When X is adding Y in a discuss channel, the recieved notification was:
- if read in discuss: from Y, "joined the channel" (no information who added him)
- if read in email: from X, "joined the channel" (misleading, think X was the
one joining the channel)
The problem comes from the author_id in the first case and the email_from in the
second, both containing a different value.
Also correct a bad api.multi parameter
Christophe Simonis