Some demo mass mailings are currently defined as being "in queue" in demo
data. This means they are about to be send by the mailing cron.
However we don't want demo data to send emails as
* most of those emails are fake (e.g. targeting example.com);
* real emails should not be sent (e.g. having by mistake a real email that
will be spammed);
* statistics resulting from those emails will not have any wow effect;
* on SaaS this consumes email quota, and produces quite a big volume of
unnecessary emails when people try the 16.0 version;
It is better to either have demo data of mailings done with traces, or keep
other mailings in draft. Otherwise the cron will send them. Flagging those
mailings is difficult, as emails are sent asynchronously and not during
install or update.
Even if this may lessen wow effect of some kanban view, better move mailings
currently "in queue" to "draft".
closesodoo/odoo#107904
X-original-commit: 0e11f4926be1800fc2b58feedcd81df24720ec19
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Cleanups and fixes/improvements extracted from another task
on the settings of sale.
* indentation
* code simplification
* privatize method not meant to be called by rpc
* double quoted strings for strings shown to users, single quoted for
technical strings
* translate onchange warning message
closesodoo/odoo#107897
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Steps to reproduce the issue:
- Accounting > Configuration > Journals
- Click on Journal
- View metadata of Journal
Bug:
Even if no modification has been made to the journal, it marked current time
in Latest Modification By/Date
opw:3089551
closesodoo/odoo#107875
X-original-commit: 47999e7b1c9a52059f84abaafeac388f2991a621
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
in account and hr module's manifest file non existing image path is specified in images key. removing this images key from manifest and remove empty images key from l10n_latam_check module
closesodoo/odoo#107346
Related: odoo/enterprise#34711
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Steps to reproduce the bug:
- Create a BoM with components
- Archive one of the components
Problem:
No warning is displayed for the user to inform that the product is
used as a component in a BoM
opw-3089104
closesodoo/odoo#107863
X-original-commit: 9b7c416387d93507b6f750aba58ad6233a59d512
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
**Issue:**
- Install CRM.
- Change language to French.
- From CRM, open a lead that has `Revenu espéré` thousands as value, e.g. 10 000,00.
- Try changing `Revenu espéré` by deleting one of the thousands digit.
E.g. 10 000,00 -> 1 000,00
- BUG: The modified value is not understood by the system.
**Solution:**
This is because the thousands separator from the French language is nbsp.
Coincidentally, the parsing logic assumes that the separator between the
currency symbol and value is also nbsp. So when inputting `1 000,00`,
the parsers thinks either `1` or `000,00` is the currency symbol.
We concluded that it's better to be less restrictive when parsing
monetary values. So, instead of making sure that the current input's
currency is compatible with the currency of the the field, we just
strip the non-numeric characters from beginning and end of the input
without validating the currency symbol, then parse the remaining
string as float.
This leads to a more user-friendly monetary input fields such that
inputting "DOGE 1,000,000.01" in a "$" monetary field will be
parsed as 1000000.01. NOTE that *no* currency conversion is performed.
**Minor breaking change:**
The second parameter `options` of the `parseMonetary` function is now
removed. Any existing use of that parameter is just ignored.
closesodoo/odoo#107862
X-original-commit: dc27f1f4c039bdbf84c55a4fb5364c6398c45949
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
**Issue:**
When the thousands separator is "nbsp" and the user inputs a value
that is "1 234", the parser will crash because the thousands separator
is different from what is manually inputted by the user.
This is problematic because when typing, it's very difficult for
users to enter "nbsp" character in their input.
**Solution:**
This change proposes that if the thousands separator is a whitespace,
we consider all whitespace characters from user input as thousands
separator. As a result, even if the thousands separator is "nbsp",
the system will successfully parse "1 234" as 1234.
X-original-commit: bffddcf015da9cf514fc25cc7f839e923e470d94
Part-of: odoo/odoo#107862
**Issue:**
- Set the decimal point to "," and the thousand separator to ".".
- In a float or monetary field, enter "=1.000,1+2.000,2"
- BUG: It's evaluated to: 30003
**Solution:**
Problematic evaluation steps:
```
-> parseNumber("=1.000,1+2.000,2")
- thousands separator are removed and decimals are converted to "."
so the string becomes "=1000.1+2000.2".
-> parseNumber("1000.1") + parseNumber("2000.1")
- since "." is the thousands separator, it will be removed
(replaced by empty string)
-> 10001 + 20001
-> 30003
```
Because the main parser `parseNumber` is recursive in nature, we
need to make sure that the logic that removes the thousands separator
and replaces the decimal point to "." is not called in the branch
that evaluates an input expression.
With this change, the new evaluation steps are:
```
-> parseNumber("=1.000,1+2.000,2")
-> parseNumber("1.000,1") + parseNumber("2.000,1")
-> 1000.1 + 2000.1
-> 3000.3
```
X-original-commit: 91eb5c40ce898428fb15d945d70510b92e9ebb03
Part-of: odoo/odoo#107862
closesodoo/odoo#107856
X-original-commit: 409fc809bafec2507342534bcdf4810ebffe9228
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
In the QUnit type definitions, there is a QUnit namespace and a QUnit
interface. When using a jetbrains IDE, it is confused between the two
and thinks the global QUnit is the namespace.
This means that it can't resolve QUnit.test, QUnit.module, etc
This fixes this issue by disambiguating between the two.
X-original-commit: 26dc799f841e51a6d57d427e095b662a45bc7e5a
Part-of: odoo/odoo#107856
Improving:
- Chart of account
- Tax report
- Fiscal position
- Translation
Task-id: 2753362
Signed-off-by: Maximilien La Barre <malb@odoo.com>
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#99450
Related: odoo/enterprise#31003
Signed-off-by: William André (wan) <wan@odoo.com>
Currently, when the vehicle is assigned, it is checked from the first contract date, now it
will be checked from the order date
In this Commit, We added order date field in fleet vehicle
task-3054981
closesodoo/odoo#107073
Signed-off-by: Kevin Baptiste <kba@odoo.com>
In this version of the tooling, the prettier files do not exist anymore.
We don't want to check if the files have changed, it will always be true
and trigger a reload of the tooling.
closesodoo/odoo#107825
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Before this commit, it was possible to define a <widget/> in the arch of
an x2many in list mode. But this was not supported in normal list views.
So in order to unify the api, we decided to support in the list
view as well.
In a future commit, we plan to improve the widget api to receive only
the necessary props.
closesodoo/odoo#107811
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Journal Items menu was not visible out of debug mode, now it is visible
Closes PR #105704closesodoo/odoo#107668
X-original-commit: fbedc97a5479bace8b23122fc423abdeb2c1757a
Related: odoo/enterprise#34876
Signed-off-by: Laurent Smet <las@odoo.com>
Before:
In the kanban card of Bank/Cash journals
- Clicking the title of the journal opened recon widget (kanban) now it opens BSL list
- Clicking on operations opened recon widget (kanban) now it opens BSL list
- Journal Items view was opening recon widget (kanban) now it opens Journal Items
In bank transactions tree view:
- `Match` button was always visible, now it is visible if line is not matched, otherwise it renames to `View`
Closes PR #105704
X-original-commit: 178991eafdadfd955a7aa68bdecf94a39ec8e2fe
Part-of: odoo/odoo#107668
update the module name of l10n_ma. Morocco is the real country name and currently upon searching with country name, app is not listed.
closesodoo/odoo#107650
X-original-commit: f6438dbca6782401f1b23497271398210b113df4
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Purpose:
When a list view with searchpanel is empty, the searchpanel is completely
empty and white, and it's unclear what it's for. Make it obvious by
displaying an empty state. This will typically happen in some views when
you have no data or don't have the groups needed to show filters.
Spec:
Display the following paragraphs with the bs classes "small" and "text-muted":
"No quick filter available."
"Update the filters in the search bar to display more records."
"Quick filters will become available if the records shown can be filtered."
closesodoo/odoo#107379
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Add edi_format "A-NZ BIS Billing 3.0" used in Australia and New-Zealand.
This format is derived from Peppol BIS Billing 3.0.
task-2994014
closesodoo/odoo#103056
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
From the commit 2ab231bd7af609a751ed8168cc094dfeb1012eda
We introduce a error in the path to read Linux file
In this commit we correct the access to the file
which is in the "home" of the raspberry
closesodoo/odoo#107779
X-original-commit: e427d0a2147896aa4311488ebc13f45b84cb330c
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
There are three rationales behind this change to set USD as default
currency and to enable it in the demo data, from the beginning.
With a demo database, before this revision:
1. On runbot, with all modules installed, it's already USD the default
company currency. It's only when you install a module not depending
on account that it's EUR the company currency by default (e.g. CRM)
2. in the base demo data,
the company is set in the United States but with the currency EUR,
3. before installing account, the company currency is EUR,
after installing account, the company currency is USD,
this is due to the fact as the company is in the United States,
the US Chart Of Account is installed, switching the company currency
to USD.
4. when you install a demo database with a module not depending on
account, you are left with a database without any active currency,
and the monetary fields therefore do not show any currency.
For instance, install only CRM with demo,
you have no currency symbol before or after the expected revenue,
which is not the best user friendly experience.
On runbot you do not feel it because all modules are installed,
therefore with account installed, which activated the USD currency.
Additional weird thing with point 2.:
- Unit tests in modules not dependent on account with the
post-install tag had to handle this sudden change of currency change
before and after installing account.
For instance, when running their unit tests with only their module,
but not account, the company currency is EUR,
but when executing the same unit test with all modules installed,
the company currency is USD.
The unit tests had to handle this sudden change within the unit test,
for instance by setting a 1.0 rate for their own company currency,
which shouldn't be the case: the rate of your own currency should
always be 1.0.
closesodoo/odoo#107113
Related: odoo/enterprise#34613
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Steps to reproduce:
-install l10n_sa_invoice module
-switch to a company in Saudi Arabia (SA company)
-create and print an invoice with a product that has arabic translation
Bug:
When adding a product and the Arabic translation.
If we add an internal reference it is added to the template,
Odoo directly concatenates this with the product name.
The result is the product name being duplicated.
Fix:
display line name and add the translation if it's different
opw-2829934
closesodoo/odoo#107798
X-original-commit: ad585bc41f49d047c150ceb9dc88bd9859fa046b
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
`website_sale` module has custom handler for form submit event. That handler
ignores `noFuzzy` attribute. As result, adding `data-no-fuzzy="1"` to
`input[name=search]` works everywhere, but not on shop product list pages.
STEPS:
1. Settings > Technical > Views > website_search_box_input & website_search_box > Code in data-no-fuzzy="1" into the <input> tag
2. Go to Website >.Shop > Customize > Enable ecommerce categories
3. Search for a product on the main shopping page and enter > Observe the URL > There is no noFuzzy param
4. Go to any product's page on the website > search for a product through the search bar and enter > Observe the URL > there is a noFuzzy param passed
opw-3051319
closesodoo/odoo#107771
X-original-commit: 1df3b14f86bada2e2cf278d2b4e591996e9e8db8
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Steps to reproduce:
- Go to Request for quotation.
- Make any search that retrieves no values. (So we get the "no request
for quotation found." message)
- Open Filters dropdown menu. (or Any menu which lenghts will be over
this message)
Issue:
The dropdown menu will be under the message, the message is overlaping
the dropdown menu when it shouldn't be.
Solution:
We need to set the message to `position: relative` instead of
`position: static` so we take into account the right z-index for the
message.
opw-3080171
closesodoo/odoo#107409
X-original-commit: 47a6a555c5bcedffdfda7586ecbe4311d2a45e5f
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Maruan Aguerdouh Mohtar (magm) <magm@odoo.com>
Before this commit, the color badge for draft and sent quotations had
the same color. Same as the line color in list view.
After this commit, color badges and lines are different between draft
and sent quotations.
task-3010707
closesodoo/odoo#106843
Related: odoo/enterprise#34188
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
When the url redirects to an anchor on a website page, the page must
scroll correctly to the section. This commit allows to do that by taking
into account the size of the navbar. The bug is visible by following
those steps:
- Drop a text - image block on a page
- Drop a picture block under text - image block
- Create a link to target the picture block
- Put link to block picture in the "Learn more" button
- Save
- Right click on the "Learn more" button and open link in a new tab
=> The page is not scrolled correctly to the picture block.
Note that the bug is not present if the header has scroll, disappear or
fade out as scroll effect.
task-2818629
closesodoo/odoo#92777
Signed-off-by: Vray Benjamin (bvr) <bvr@odoo.com>
Follow-up reports were previously not handled by the commit fixing
invoices. This commit aims to fix that.
closesodoo/odoo#107787
X-original-commit: 768cfbe095cd6757771dcc683637fd510b0fbddb
Signed-off-by: Florian Daloze (fda) <fda@odoo.com>
Signed-off-by: Solan Delvenne (sode) <sode@odoo.com>
The kanban cards did not take the class
oe_kanban_color.
This is because it was set on the child div
instead of the parent one.
opw-3069024
closesodoo/odoo#107778
X-original-commit: 9078761d10289446cfd3881e9df9061075441440
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
STEPS: Create a Pricelist with price rule discount-based on parent product
category. Result: the price rule discount is not applied if the product is not
directly attached to a parent category.
Fix it by correcting domain in `_get_applicable_rules_domain`.
Also, update tests: use parent category in the pricelist.
https://github.com/odoo/odoo/commit/dc8db07ba718a2de845455efc6e265213537eedf
opw-3080836
closesodoo/odoo#107769
X-original-commit: ce44c045f6b75fa64962625baad322632a9c2979
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The demo data were assigning random res.partner as home_address_id for
some employees, this is no longer required since #98027.
closesodoo/odoo#107767
Signed-off-by: Kevin Baptiste <kba@odoo.com>
When a record is `forcecreate=0` and a reference of one of its fields is missing, the update of the corresponding module fails. In this case, we can skip the creation of this record.
An example of this issue is this [record](https://github.com/odoo/enterprise/blob/6411ae071ace980834befeb8040c94b1a05c8034/documents_account/data/data.xml#L17) in `documents_account` module (enterprise) when the reference of this [field](https://github.com/odoo/enterprise/blob/6411ae071ace980834befeb8040c94b1a05c8034/documents_account/data/data.xml#L20) is missing.
This can be reproduced as follows:
1. Create a DB with `documents_account` module
2. Uninstall `documents_account` module
3. Remove `documents.documents_finance_status`
4. Reinstall `documents_account`
```
Traceback (most recent call last):
File "/home/ayman/src/odoo/15.0/odoo/tools/convert.py", line 680, in _tag_root
f(rec)
File "/home/ayman/src/odoo/15.0/odoo/tools/convert.py", line 567, in _tag_record
f_val = self.id_get(f_ref)
File "/home/ayman/src/odoo/15.0/odoo/tools/convert.py", line 663, in id_get
res = self.model_id_get(id_str, raise_if_not_found)
File "/home/ayman/src/odoo/15.0/odoo/tools/convert.py", line 669, in model_id_get
return self.env['ir.model.data']._xmlid_to_res_model_res_id(id_str, raise_if_not_found=raise_if_not_found)
File "/home/ayman/src/odoo/15.0/odoo/addons/base/models/ir_model.py", line 1943, in _xmlid_to_res_model_res_id
return self._xmlid_lookup(xmlid)[1:3]
File "<decorator-gen-35>", line 2, in _xmlid_lookup
File "/home/ayman/src/odoo/15.0/odoo/tools/cache.py", line 90, in lookup
value = d[key] = self.method(*args, **kwargs)
File "/home/ayman/src/odoo/15.0/odoo/addons/base/models/ir_model.py", line 1936, in _xmlid_lookup
raise ValueError('External ID not found in the system: %s' % xmlid)
ValueError: External ID not found in the system: documents.documents_finance_status
```
closesodoo/odoo#107766
X-original-commit: 2e4f0667397d2d6670df50b9088fa9c23f1f9f5a
Signed-off-by: Christophe Simonis <chs@odoo.com>
Have a kanban view by default grouped by a date field, with a granularity
eg: "date:month".
Have no data so that the read group returns with only the groups for the range (fill temporal).
Those groups should have a count of zero, triggering the sample server to make up data.
Before this commit, there were multiple crashes basically because the groupby written
as field:granularity was not handled at least in the case were groups are returned by the server.
That is, from the sample server perspective, groups are reused and records are just made up
matching those groups.
There were two issues in fact:
- the groupBy with granularity (eg: date:month) was not properly handled, sometimes not splitting
the field name and the granularity, sometimes splitting those up where it should not.
- since the RelationalModel's groups are re-used verbatim by the sample server
(which still needs to return what the real web_read_group would), the "__range" data was missing,
since it had been transformed by the RelationalModel after the real call to web_read_group to the server.
After this commit, this use case is supported.
opw-3063067
closesodoo/odoo#107529
X-original-commit: 060b237f3caac5241130915b41a34aab7d28f4cb
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
When printing labels in a `ready` picking, if no quantities are set it
will only print the reserved quantities as labels.
Then, if a product has no reserved quantity, it will not have any
move_lines. Which means its initial demand won't be able to be fetched,
and the default behavior will be used, which is to print a single label.
By giving the moves instead of the move_lines to the wizard, we allow to
fetch for moves that have no reservation and print labels correctly
using their initial demand if no reservation is found.
The standard behavior once quantities are set remains untouched.
closesodoo/odoo#106414
Related: odoo/upgrade#4091
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Commit [1] introduced the creation of a website in the tests, but
wrongly set `user_id` to the current environment user.
It doesn't make any sense as this field is supposed to hold the website
public user, which is not a real user and is supposed to be a public
user, as the field name hints..
On top of that, the current environment user (the demo user for tests,
which is wrongly set as the website public user) is then used to login
into the website, which is then making things even more weird/wrong: you
are not supposed to login with the public user (which is not really a
public user here but still marked as the public user from the website).
It was preventing the fix from this same PR (see previous commit) to be
working, as it was making this tour crash.
Not setting the `user_id` property will simply let the system create one
for you (a real public user..).
[1]: https://github.com/odoo/odoo/commit/3611aaf0983b3d25822022ebeddd781f6d082bf7closesodoo/odoo#107759
X-original-commit: 68fc99cf944090a37ee2d392990f39adb4899076
Signed-off-by: Julien Castiaux <juc@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
One can very well select a "auth=user route" as homepage for his
website, like /my.
There would then be an issue with such an URL being set as homepage:
- As the user landed in the homepage controller which is auth=public,
the system will add the public user as env user (see
`_auth_method_public()`).
```
@http.route('/', type='http', auth="public", website=True, sitemap=True)
def index(self, **kw):
```
- Then, that controller will reroute to the homepage url (/my). The
request.httprequest.path will now be /my
- Then, that controller will recall the dispatcher stack:
`request._serve_ir_http()`
- From there, this call won't fail as it should because the user is
considered as logged in as it went already through the
`_auth_method_public()`, adding the public user as env.user.
`_auth_method_user()` won't raise its error.
- The /my page will be rendered despite not being logged in.
Once the user land on that page, the system will actually detect him as
logged out on a page supposed to be accessed when logged in.
It will then:
1. Show a toaster to inform the user
2. Auto reload the page
As the current URL is still `/` (due to the reroute and not a redirect),
the same flow will happen again, and again, looping forever.
--------
Note that accessing /my directly won't be an issue, as it won't go
through the homepage controller (which is auth=public), so there won't
be a user_id set on the env (the public user), meaning that the dispatch
layer will reject the access and raise an access error (through
`_auth_method_user()`.
Also note that the same behavior will occur when going through the first
menu fallback mechanism:
- if the user didn't setup any homepage_url
- and deleted his / website.page
- and his first website menu is /my
In that case, it will go through the first menu redirect fallback, which
will be working fine (as it's a redirect and not a reroute).
With both those 2 flows (going through redirect), the user will
correctly land on the login page (which will redirect to /my once logged
in).
------
Finally, the other solution would be to prevent such a configuration
(/my as homepage_url) but it was not easily doable (if doable at all),
see https://github.com/odoo/odoo/pull/99100#discussion_r963055251
------
A test is also added and over the more complexe case (which should cover
everything):
- With /my as homepage_url
- With the / website.page deleted
- With /my as first menu URL
-> Accessing / as public user should:
1. Reroute to /my (because of the homepage_url set to it) which
should fail now thanks to this commit
2. Since the reroute / re-serve failed, it should reach the
"first menu fallback" mechanism, which is also /my
3. That fallback should be a redirect, not a reroute, so the user
should actually land on the login page
4. Once logged in on that page, it should properly redirect to /my
opw-3077339
X-original-commit: 4f5899f769266edc27a0b2d812df092b95f43c71
Part-of: odoo/odoo#107759
Commit [1] improved the "sanitation" of this field for special
character. For instance, when copy pasting the following terms:
| Input | Before | After |
|-----------------|------------------|-----------------|
| fée d'été à 40€ | f-e-d-t-40- | fee-dete-a-40 |
| Nội dung có Dấu | n-i-dung-c-d-u | noi-dung-co-dau |
But it actually came with a bad behavior which was not noticed: it
prevents to type `-` at the end of the input, which sounds good but is
not.
Indeed, when typing `a-word`, you will type `a` then try to type `-`
which won't work as considering a (forbidden) trailing slash, even if
you actually want to type something after.
This commit allows trailing slashes again, it's not a big deal and one
can remove it if he wants to.
[1]: https://github.com/odoo/odoo/commit/bb43d4dbb5745be84f0f9462e768989e50607bea
opw-3075419
closesodoo/odoo#107746
X-original-commit: bb43e343c0ec823dad8b102a81945b4a05a7af85
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
install purchase_requisition module, and create an RFQ in db, check the alternatives tab in the notebook, currently the button Create Alternatives will not be visible unless user click the save button manually. button no longer needs to be hidden when creating a new PO since v16 added in the auto-save feature
closesodoo/odoo#107733
X-original-commit: a6a830e89c724f993b930442573d8d0c4e692b07
Signed-off-by: Tiffany Chang <tic@odoo.com>
This commit adds a new Unselect all button displayed when at least two
records are selected in a list view. This button appears near other list
buttons. Once clicked, the selected items are deselected and the button
disappears.
Some list view tests have been modified since that change now adds a
button in cases where it was not expected before. Those tests now verify
the behavior when the button is clicked.
task-3081101
closesodoo/odoo#107294
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The icons of the enterprise applications in the community apps list are
not updated with the new icons.
This commit update the old icons with the new ones from the enterprise
version.
Note: some of the app in the apps list should be deleted as they're
not in the enterprise version anymore:
- Android & Iphone (using same icon as CRM)
- MRP II
- Website Version
- Website Form
task-3062514
[FIX] web: updating community icons
closesodoo/odoo#106587
Signed-off-by: Julien Castiaux <juc@odoo.com>
Reproduction:
1. Install Sales, Stock
2. Place an order with any product, in the Other Info tab, type in
anything for Customer Reference
3. Confirm the Order, Go to Delivery, Validate the delivery
4. Print the Delivery Slip, and the customer reference part is
overlapping with other text
Reason: the unnecessary CSS attribute <row> is causing an overlapping
when rendering the delivery template
Fix: remove <row> and reformatting the code
A correct example of adding extra info (done without row): https://github.com/odoo-dev/odoo/blob/16.0/addons/delivery/views/report_deliveryslip.xml#L4-L17closesodoo/odoo#107726
X-original-commit: 863a9cf159da9691744f08a915e12f477342dbc3
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Liu Jinjiu (jili) <jili@odoo.com>
currently on clicking the given link return 404 response.
closesodoo/odoo#107722
X-original-commit: 9fe68d2510f4ee4fd05facc64783a32a16d09e9e
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The keys from the action context were not available in the context of
a name_search done when a user expand a one2many field in the search
bar. We add them.
closesodoo/odoo#107660
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Partial revert of 0beebad
Since the aforementioned commit, if a client updated its order on the portal:
* adding optional products
* removing optional products
* updating optional line quantities
and paid directly after, without reloading the page, the amount he paid
was the amount of the SO when the page was loaded.
Avoiding the reload and only modifying some DOM parts was a bad idea to begin
with.
We'll consider developing a correct and clean way to (re)render the payment part
of the DOM, or use separate pages for orders modifications and effective payment
checkout.
closesodoo/odoo#107569
X-original-commit: 81a9080eb375c31a7766189bb61e1bd8d99d855a
Related: odoo/enterprise#34837
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Thibault Delavallée