Before this commit, RTL on frontend was only enabled for connected user.
To have RTL, we add the direction on the element, and the RTL version of
the stylesheet for the applicable languages are generated thanks to rtlcss.
opw-1892757
closes#28434
Odoo 12.0 does *not* officially support any python version below 3.5,
but no effort had been made to gracefully announce this to the end user
if they were to run Odoo in an unsupported python version.
This is done because Odoo 12.0 uses py3-only constructs which can
and will raise different errors if ran in python 2.
With this patch, Odoo will display an appropriate error message and won't
launch at all unless it is being run with python 3.5 or greater.
closesodoo/odoo#28502
Suppose you are editing a SO to add a new line. Depending on the configuration,
a sale order line wizard may open (e.g. if packages are activated).
This wizard is a form view, opened from the tree view of the sale order lines.
We have commit 8e5156938a
that adds extra fields from the originating view.
(However it doesn't work if the other view is inlined, so we modify this part to
add the extra field even in this case.)
Then we need the field info from the origin view in the target view;
we do so by extending the former with the content of the latter.
opw 1904337
closesodoo/odoo#28441
Stock moves show a detailed operations icon if the tracking, locations, or
consignment allow to be configured.
However it did so on a per move basis, only displaying it if the considered move
has some of these features.
This fix makes it that the "detailed operations" icon is always displayed if at
least one group of group_tracking_lot, group_stock_multi_locations, or
group_tracking_owner is active, or the move is tracked,
unless the move picking type already does show detailed operations.
opw 1893106closesodoo/odoo#28072
Create an automated action to create a new activity on update of a record
(e.g. a CRM lead).
At update, many fields recompute may be triggered, triggering as many write.
Thus it would generate many activities.
We simply do nothing if we are in a recompute.
Coauthored by rco
opw 1904156
closesodoo/odoo#28498
c5dc0b2f39 disabled send button on composer sent.
But this is only needed for chatter composer, other composers directly
send the message and are not refreshed asynchronously.
So for other composer, the send button worked one time but then was
disabled and the only way to sent was ENTER (on basic composer) or
CTRL+ENTER (on extended composer).
With this fix, disabling the button is done only for chatter composer.
Also the behavior of not clearing the message if there was an error is
introduced back.
Without change in code, added test fails with:
"Should keep unsent message in the composer on failure" (result: "")
"Send button should be re-enabled on message post failure" (result: true)
issue found when checking opw-1904029
closes#28475
- Create a SO
- Paid the SO using a transaction
- Create an invoice from the SO
=> The invoice will now be reconciled automatically with the payment transaction
Was task: 1890029
Was PR #27390
Before that, with "post at bank reconciliation option" activated on bank journal, the following scenarii did not work as expected:
1. When creating an invoice, making two payments for it, and then matching only one of them with a bank statement
=> the invoice was marked as 'paid' while it should have staid 'in payment' until the second payment gets a bank statement.
2. When directly reconciling a bank statement with an invoice for its full amount
=> the invoice staid in "in payment" state, while it should have been "paid"
[IMP] account: add tests for the aforementioned cases
closesodoo/odoo#28428
Sometimes, a sale.order in the SALE state doesn't have a confirmed date,
which can cause a traceback. To avoid this, when confirmation_date is
null, use the write_date, which is never NULL when sale.order is in sale
state.
In migration, we will try to populate the confirmation date with
the mail.message subtype. As ultimate fallback, we will take
the write_date.
closesodoo/odoo#28296
Create an accrual leave, and set it e.g. by employee tag.
For each employee having the tag, a child allocation will be created.
When doing so, it will prepare the values for these creations.
However the relevant fields for accrual leaves were missing from these values.
opw 1906476
closesodoo/odoo#28492
1. Create a payment term with:
- 50% due now
- balance due in 14 days
2. Validate an invoice with this payment term and partner Agrolait
3. Create a payment from Agrolait with the 50% due
4. Add this outstanding credit to the invoice
It is reconciled with the balance due in 14 days instead of what is
due now. Because of this e.g. the Aged Receivable report will show the
customer being overdue with a payment.
This issue was first fixed in 9.0 at
adad192cc0. It was then reintroduced in
saas-11.4 at d3d2612061. This commit
adds a test to avoid regressions like this.
To fix the issue this sorts journal items by their Due Date if there
is one. Otherwise we use the date from the journal entry as before.
Note that before this commit journal items were not sorted at all by
the two 'sorted' statements. sorted returns a sorted recordset, it
doesn't modify the recordset it's called on.
opw-1906665
In a multiple company account, when creating an event without
company, the emails sent contain "Send by False" as footer, this
PR correct that by disabling the footer in case there is no company
opw-1894825
Let's assume a form view with field A and B (a one2many list), with
a column with attrs column_invisible depending on A.
If the user sets A manually, everything works fine (the column is
hidden/shown directly). However, if A is updated by an onchange
(e.g. depending on the number of rows in B), it doesn't. This
rev. fixes that issue.
Related to Issue: 1851451
Co-authored-by: Priyanka Kaakdiya <pka@odoo.com>
Add a check to see if we're in test mode that returns an InsufficientCreditError to avoid failing other tests if partner_autocomplete server fails
closesodoo/odoo#28324
web_editor dirty elements are saved by calling the ir.ui.view `save()` method.
As this method is called through call_kw _rpc on the ir.ui.view model, self
is binded to the view which has the `id` sent in the request.
In some cases, when editing a field for example, the id sent is the id of the
field's record (eg: product.template for price field).
In that case, the view binded on self will be the view with the id of the
field's record being edited.
If there is no ir.ui.view with the same ID as the field's record, self won't
exists.
This misbehavior resulted in no error luckily since we only use self to call
ir.ui.view methods without ever using self properties.
Since multi-website 47b00c5d53 overrided the `save()` method and used self.key
it was crashing when the self record did not exists.
This commit will fix that by doing the multi-website check only when it is a
view and not a field that is being edited. (We know that if xpath is set)
opw-1904637
Step to reproduce:
- Go to a product on ecommerce, eg product.template 13013
- Edit the product price field, the oe-id attribut is 13013
- Delete the ir.ui.view that has the same ID than the product (13013)
- Save -> It will crash since self is binded to "ir.ui.view(13013,)" but it
does not exists and we try to access key
closesodoo/odoo#28469
Steps to reproduce the bug:
- Let's consider three products P1(in Unit), P2(in kg), P3(in Unit)
- Create a BOM kit for P1 whit 1kg of P2 and 1 Unit of P3 as components
- Create a SO with P1 and validate it
- Go to the shipment and validate
Bug:
An error was raised saying:
The unit of measure kg defined on the order line doesn't belong to the same
category than the unit of measure Unit defined on the product. Please
correct the unit of measure defined on the order line or on the product,
they should belong to the same category.
PS: The quantity delivered on a SO line must only be computed for the product
defined on the SO line. Otherwise with a BOM kit, the sum of all its components
was done instead.
opw:1905223
closesodoo/odoo#28460
* web, web_editor
The logic which chose if the user text color was supposed to be used as
bootstrap "dark" text color or bootstrap "light" text color
(https://github.com/odoo/odoo/commit/8b2dbd1441d6713d9072db03e8d3cb6c2246410f)
was fine when using the default theme with default bootstrap but was not
working as intended in some themes.
This commit also introduces a more accurate and complex method to
determine the correct contrasted color in most cases.
closesodoo/odoo#28468
When a user accesses a PO through the portal thanks to an access token
(without being connected), the product image on each order line is
rendered using the image placeholder with a size of 48x48.
This raises a 403 Forbidden at image retrieval since the access token is
not passed as a parameter. This commit corrects that behavior by sending
the resized image along with the rendering of the template instead of an
url.
Another solution could be to generalize the access token check to any
model in:
https://github.com/odoo/odoo/blob/12.0/odoo/addons/base/models/ir_http.py#L303-L311
But this seems overkill regarding this specific error.
opw-1902741
closesodoo/odoo#28479
- Configure custom payment instructions
- Create a SO, send it by email to the client (do not validate)
- As the client, open the link received by email and 'Accept & Sign'
- Click on 'Pay Now', choose 'Wire Transfer'
The page reloads and shows the message:
> Pending... The order will be validated after the payment.
along with the custom payment instructions. However, no communication is
provided for the payment.
First, the `reference` is never set when calling the
`payment_confirmation_status` template, as it is done in
`portal_invoice_page_inherit_payment`. Moreover, in this workflow, the
reference is never set on the SO because of an incorrect filtering in
`_set_transaction_pending`.
opw-1906464
closesodoo/odoo#28466
Following commit b43151c11c
The order of the pricelist items on the interface was made deterministic, but
there was still a problem with the actual computation because the SQL was
created manually and used a different order than the _order of the model.
Moreover, it is better to use id DESC instead of ASC to make sure the
automatically created default rule matching everything is actually applied last.
PR: #28476
Some code is in charge of setting the same min-height for all items of
a carousel to the natural height of the tallest item, once the page is
loaded. This code was not working correctly in the case the natural
height of this tallest item depends on the height of one of its inner
image, as we have to wait for the image to be loaded in that case.
closesodoo/odoo#28159
When there is a language and its base language translation files in a
module, in 12.0 an empty translation in the language translation file
will not fallback on the base language.
eg.
fr.po : {'one': 'un', 'seventy': 'soixante-dix'}
fr_BE.po: {'one': '', 'seventy': 'septante'}
=> the translation in fr_BE will be {'one': '', 'seventy': 'septante'}
but before 7288b477 it would have been {'one': 'un', 'seventy': 'septante'}
With this commit, an empty translation is no longer created so does not
override base language.
Also the intention of d84b795b0a that was also lost is restored by
upserting only noupdate==false translation, and inserting the other
ones.
opw-1904638
closes#28297
Since the opt out per mailing list, the intermediate model was used
to list all the recipient of a mailing list. The side effect was that
importing new contacts into mailing list was not possible anymore.
Also, creation of a new contact into a mailing list was made indirectly
by creating a new many2many record between contaxct and list, which was
not really user friendly.
This commit restores the mailing contact model as the view of the mailing
list recipients. In other terms, the contact import is restored.
An opt-out computed field as been added to be able to filter on opted out
contact inside the mailing list recipients view.
This opt_out field SHOULD NOT be used in a form view as it need the active
mailing list id in the context in order to be computable and searchable.
This field has no sense without this active mailing list id context.
Task ID 1891228
Linked with blacklist and opt out per mailing task (ID 33224)
Closes PR #27632
On mobile (specifically in landscape orientation as the height of the
viewport is narrower), the content appear over the bottom toolbar
instead of going below.
Solution is in 2 parts:
* raise the toolbar way above the content
* make the toolbar opaque
closesodoo/odoo#28429
In some cases, and for historical reasons, the groupby property can be
expressed as a string (for example, 'stage_id') instead of a list of
strings (for example, ['stage_id']).
However, the support was not complete. A crash could happen in some
cases. For example, if there is a group_by: 'stage_id' property in the
context of an action, it works in list view, but adding that view to the
dashboard would result in a crash, without this commit.
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#28408
Before commit 60f143c8e7, the dashboard
parameters did not use the parameters from the action, so some important
information could be lost.
However, in this same commit, the action context overrides the context
from the user defined views, which means that some information is lost.
For example, customized group bys are ignored.
This commit fixes the issue with some careful context manipulation.
Some special care was done to remove the groupby from the action context
if it is not empty, because that same logic is used in views.
Introduced by: 3d46887d38
Before this commit, creating an invoice from a SO always chose
the payment_method=all when the number of invoice linked to the SO >0
OR all the lines of the SO were with invoice_policy = 'order'
After this commit, creating an invoice from a SO just choose the payment_method=all
when the number of not canceled invoice linked to the SO > 0 AND when there are at
least one downpayment in the SO
SO:
Steps to reproduce the changement of behavior:
- Create a SO for 10 units (invoicing policy based on ordered quantities)
- Create the invoice for 10 units (from SO) and validate it
- Change ordered quantities to 5 units
- Click on create invoice on the SO
The payment method chosen was delivery instead of all. So choosing the default option
lead to a user error saying: there are no invoicable line instead of creating a credit note.
opw:1904258
closesodoo/odoo#28426
In some cases, and for historical reasons, the groupby property can be
expressed as a string (for example, 'stage_id') instead of a list of
strings (for example, ['stage_id']).
However, the support was not complete. A crash could happen in some
cases. For example, if there is a group_by: 'stage_id' property in the
context of an action, it works in list view, but adding that view to the
dashboard would result in a crash, without this commit.
As empty arrays are considered truthy, the call to `/web_unsplash/get_app_id`
would always be performed even if no Unsplash images.
closesodoo/odoo#28421
Before this commit:
Reserved column appeared with 0 qty when Delivery Order goes to done Stage
After this commit:
Hide Reserved column when Delivery Order goes to done stage.
This task is related to #1888361Closes: #27223closesodoo/odoo#28409
Nicolas Lempereur