- Create a SO, keep it as draft
- Click on 'Send by Email'
The name of the attached PDF file contains `_draft`.
This doesn't really make sense anymore, since the SO will be set to
'Sent' right after sending. Therefore, if sending a second time,
`_draft` won't be added to the filename.
opw-1930282
closesodoo/odoo#30367
- Activate debug mode
- Go to the Accounting Dashboard
- In Vendor Bills, click on 'Journal Items'
A crash occurs because of the concatenation of a `bool` and `str`.
In this case, the `action['help']` is `False`.
closesodoo/odoo#30351
Before this commit, the condition and the field on which it applied were wrong
That is, when both the user and the partner were inactive, the message saying that
the partner was still active displayed anyway
After this commit, we show the message only when the user is inactive but its
directly related partner is still active
OPW 1928247
closesodoo/odoo#30337
The content id of an attachement can contains a @, therefore
image contained in emails where sometimes escaped by html_sanitize
as if they were emails adresses.
Task: 1915251
closesodoo/odoo#30326
- Activate multi-company
- Create 2 S2S payment methods (Payment Flow: Payment from Odoo), one
for each company
- Connect as a regular user to `/my/payment_method`
The user has access to both payment methods, while he should only have
access to the method of his company.
opw-1920483
closesodoo/odoo#30558
- Install website_sale and website_sale_delivery
- Activate 'Terms & Condition' on the payment page
- Process a shopping cart
On the payment page, the 'Terms & Condition' checkbox is unchecked, but
the 'Payment' button is enabled.
Both `$checkbox.change` and `_onCarrierUpdateAnswer` set the `disabled`
property, and conflict.
We keep on the HTML node an object with the list of disabled reasons.
opw-1923459
Co-authored-by: Nicolas Lempereur <nle@odoo.com>
closesodoo/odoo#30504
On mobile the frontend menu navbar is an hamburger menu that open on
click.
If the option "Customize > Main layout | Affix Top Menu" is
enabled, there is two menu:
- one at the full top of the page
- one affixed to the top of the viewport (only shown if we are at least
scrolling 300px away from the top of the page)
But there is a side effect: when scrolling if the menu at the top of the
page is opened, it will be automatically closed => this makes sense to
avoid having two menu shown on the same page but is an odd behavior.
With this commit, the behavior is changed and when the menu is opened in
the top, the affixed menu is not shown (it only works if the top page
menu has no opened dropdown).
opw-1920310
closes#30564
use cases fixed:
1) go in the journal items, filter on unreconciled lines, pick just one and click on 'Action > reconcile', the manual reconciliation widget opens but you directly get the rainbowman and you can't do anything. It's not possible to reconcile the selected entry with a writeoff (to clear a customer account, for example).
2) go in the journal items, select 2 receivable lines for the same amount but that don't have any partner set then click on 'Action > reconcile', the rainbowman directly shows without processing the reconciliation.
To fix those issues, we now clearly bypass the regular methods in case we have active_ids and active_model == 'account.move.line', since they weren't adapted anyway.
also implement real error message when selected lines don't have the same company or account (currently it's displaying a rainbowman): see error messages in 'reconcile()' in account_move.py
OPW #1919727 and #1930957
Co-authored by wan-odoo
closesodoo/odoo#29771
In the invoice list view, select one or more invoices
click on the action > register payment
In the wizard, put an amount inferior to the sum of invoices amount
Do a write off
Before this commit, the write off was ignored and the invoices not marked as paid
After this commit, the write is written, and the invoices marked as paid
OPW 1920839
closesodoo/odoo#30465
Fine-tuning of commit 92b4e2e866,
itself a performance fine-tuning of commit b7e2d47596
which added progress bar support for selection fields.
However it assumed that every record had a value in the selection,
whereas False is (nearly) always a possible value.
opw 1916472
closesodoo/odoo#30322
The follower's list has an ancestor (the o_chatter_topbar) that has a 33px size.
Thus it has not been given any max-height, so that it can overflow
that 33px limit.
But it also means that it can overflow the screen, without any scrollbar,
so long lists are unreadable and unusable.
We set the max-height to a reasonable value, allowing for scrollbars.
opw 1922062
closesodoo/odoo#30211
Before this commit, in the config bar (Sales or Invoicing) when you configure a payment
acquirer, it was deployed in test mode, and not in production mode. Note that, the config
bar wizard asks for the production credentials.
Now, when you configure a payment acquirer, from the config bar, the acquirer is deployed
directly in production mode.
opw-1918412
closesodoo/odoo#30319
Currently, a partner is considered a portal
if he has no users
or
if at least one of his users is portal.
This causes problems if an employee has two users,
one portal, one employee
and gets notified in a thread (e.g. @ Marc demo):
The email sent won't contain the action buttons (e.g. view opportunity)
because the employee is considered as portal.
A partner of an employee can have multiple users
linked if at some point two partners were merged,
and the partners had each a user, one a portal
and the other an employee.
This revision changes this behavior,
to consider a user as not portal (employee)
if one of its users is not a portal (an employee).
This is uniform with to the behavior of the
`share` field of `res.users`,
which is `True` when the user is part of the group employee.
```
user.share = not user.has_group('base.group_user')
```
opw-1914103
closesodoo/odoo#30314
- Set valuation to FIFO
- Make a PO for a product
- Validate the picking
- Execute the Inventory Valuation report
- Apply group by Category
- Click on the 'Valuation' info button
A traceback occurs because of the usual `group_by` context key which is
kept.
opw-1918915
closesodoo/odoo#30313
Open studio to modify the widget displaying a relational field.
The report_layout widget can be selected, say, to display payment terms.
Obviously it doesn't make sense.
We remove its supported field, as the field is not generic
(indeed there is only one use for it in the codebase).
opw 1919369
closesodoo/odoo#30303
Define a field on a model as:
- o2m to res.partner
- the field's column, hence its name, has capital letters in it
(studio does that)
create two objects of that class, each one linked to a different partner with the new o2m
merge the partners
Before this commit, the object linked to the second partner, was deleted
This was because merge partner sql requests did not quote the column name
After this commit, the second object still exists
OPW 1925060
closesodoo/odoo#30300
The 500 page has `session.is_frontend === undefined` as it has its own
whole HTML template.
In that case, the ajax.loadXML is not done, making the tour crash when
visiting a 500 error page.
This is needed for #29957 that has a test tour on 500 error page.
closesodoo/odoo#30240
Since multi-website, we COW (copy on write) views when editing a view on a
website.
This is causing 2 issues related to module install/update:
1. During a module install, when creating an inherited view, it will create
that view as expected on the generic tree.
But that generic tree may not be used on website(s). Indeed, if the view
was edited, we are now using a copy of the view instead of the original
XML view (with an xml_id).
That copied view won't get the new inherited view in its view tree.
Now, we correctly copy the new view under every specific view tree (if
exists).
2. During a module update, when updating a view, it will only update the view
having the xml_id, so the generic one.
But most of the time, the generic view is not used as it was usually COW'd
and the specific view now replace the generic one.
Now, we also apply the update on the COW'd view. Note that only unmodified
field will be updated, this behavior basically mimic the noupdate behavior
on view's ir.model.data.
Step to reproduce for bug 1:
- Install website_sale module
- Go to a product page and then enter edit mode
- Make a modification to trigger COW, eg edit the information area under the
price "30-day money-back guarantee".
- Now install website_sale_comparison module
- The product page won't have the comparison button as the comparison view
inheriting the product view was created on the generic tree and not copied
on the specific tree (COW'd before the comparison module install).
Step to reproduce for bug 2:
- Repeat first 3 steps of bug 1
- Now make a modification in a view from the XML file in
website_sale_comparison module and update the module
- Only the view with the xml_id is updated, not it's COW'd views. This mean
that only the generic view is updated and not the specific one(s) really
used on the website.
task-1920487
closesodoo/odoo#29956
Before this commit, a generic view tree could be valid but impossible to copy
on a COW specific tree.
This was because when looping through inherit_children_ids to copy them, they
would be sorted by the ir.ui.view sort order (name, priority, id).
Indeed, when applying view inheritance and reading a view arch, children are
sorted by (priority, id).
Thus, if sorting the children by (name, priority, id) was different than
sorting by (priority, id) and the children view would conflict in that new
order, the COW would raise an error "can't find DOM element"
Step to reproduce:
- Create a parent view with just a DIV in arch
- Add a child view that add something inside that DIV
- Add another child view with a name alphabetically lower than the other
child and that replace the DIV by something else, like a SECTION
- Everything works as expected, when reading the parent view arch, the first
child is inserting something into the DIV and then the second is replacing
the DIV
- Now try to trigger the COW on the parent view by writing something on it in
a website context
- It will crash as the child views will be copied in another order, sorted
firstly by name.
- Indeed, when reading parent view, the second child will be copied first as
it's name is lower than the first, it will then replace the DIV by a SPAN.
When trying to copy the other child view that is supposed to insert
something into the DIV, the DIV will not be found and it will crash.
When using the 'Auto-Complete' feature of a vendor bill, oldest vendor
bills are suggested first.
This is because the `_order` uses the `vendor_bill_id` and the
`purchase_order_id`. In the view, we have a mix of positive, negative
and null ids, therefore this can't work.
We sort on the date and the name instead, which gives a more reliable
result.
opw-1925910
closesodoo/odoo#30299
To reflect the latest accounts and taxes
Update nl.po files to help translators
A future commit will translate the missing entries
closesodoo/odoo#30297
In the background layout footer, it happens that the content is over a
zone that must stay blank. That's why w've added a left-padding to the
footer.
OPW-1928366
closesodoo/odoo#30296
The field `sale_order_template_id` is only defined on `sale_management`, so
calling that method without `sale_management` would crash (traceback).
The method was in `sale_management` in the first place but commit
34c47eecd3 happened and some mistakes were made
that day.
PR: #30000closesodoo/odoo#30294
Before this commit, changing the value of the HOST variable didn't work because
it wasn't correctly used everywhere.
Moreover, the `web.base.url` was not correctly set: it is set during
authenticate, but when calling it from the console instead of from a request,
which is the case for tests, it is not able to grab and set the URL as needed.
PR: #30000
Using read_group outside of the loop make the sum computation in
PostgreSQL instead of Python, and avoid the ORM to fetch fields of
records to compute a sum of one field.
closesodoo/odoo#29825
In multicompany,
Have company B with a different currency than company A
With a shared product catalog
Open the inventory valuation report for company B
Before this commit the stock Value is expressed in company A's currency,
even though the value itself is correct
After this commit, the stock value is expressed in the right currency
OPW 1912511
closesodoo/odoo#30242
When displaying a video, with the browser window at a certain size, or
resizing it (or opening developer tools) we could the following error:
"ResizeObserver loop limit exceeded"
This can be reproduced in chromium just with this JS code:
window.onerror = function(e){ console.log(e); };
document.body.innerHTML = '<div><video controls src="v.webm"/>';
The issue only happen if:
- the video server does not support HTTP range requests
- the controls are displayed on the video
- browser size is in problematic size/resized to problematic size
And the error is raised in window.onerror but not displayed in the
developer console.
With this change, we ignore these errors until fixed in chromium.
chromium bug tracker: https://crbug.com/809574
opw-1928512
closes#30239
Task #1910927
Purpose
=======
When confirming a sale order with event tickets, a modal is supposed to be shown to be able to
confirm the event registration.
That modal was not shown anymore.
To solve it, we split the '_action_confirm' to run the actual business of the event_sale module,
which is '_update_registrations', and moved the action returned in the regular 'action_confirm' method.
closesodoo/odoo#29997
- Fix the position of 'Add to menu' toggle button in new page dialog
- Properly align tip icon in the welcome message
task-1895287
closesodoo/odoo#29403
- The method `_get_available_payment_input` that returns the available
payments acquirers and the payments tokens for a specific user never
returns the payments tokens linked to a non s2s payment acquirers.
This is wrong, the payments tokens should always appears no matter
what are the acquirers' payment flow.
The payment flow is used only to specify where the customer should
input his credit cards details, either on Odoo or on the payment
acquirer's website (or popup).
Once a token is created, it is safe to process it since no credits cards
details are stored on the Odoo database.
closesodoo/odoo#30258
Display a BoM.
On BoM lines, there is an attachment feature that creates a mrp.document,
which is basically a container for an attachment.
This commit fixes the view which displayed 'no attachment' when there were some
and vice versa.
It also fixes the computation of the number of attachment: the displayed view is
on mrp.document, but the computation is done on ir.attachment.
As a result if there are other unrelated attachments (such as digital files)
they would be counted but not displayed.
opw 1923441
closesodoo/odoo#30208
Nicolas Martinelli