Issue
- Install Sale
- Create SO
- Add a note line with a very looong word
- Print PDF
No line break, table is expending out of
the visible report.
Cause
There is no line break CSS rule
Solution
Use word-break: break-word; in order to
break line without cutting words.
OPW-2195984
closesodoo/odoo#47272
X-original-commit: af8fb786a9569562cefb7d8ea63454cddc04cd44
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
Since 13.2, the cards cannot contain an overflowing element anymore as
we needed to enforce 'overflow: hidden' for the border-radius option.
Note: this commit adds data-vxml="001" on the snippet. This will allow
users which have already added the card version of the snippet in their
website to receive a notification that the snippet is deprecated once we
will have implemented that system (in progress).
task-2208802
closesodoo/odoo#47228
X-original-commit: 220ec38e7538389279eb2dce9c897052d680ea1a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
No default url on countdown's urlpicker anymore. Only a placeholder.
Also redirect to homepage if no url.
Part of: https://github.com/odoo/odoo/pull/46640
task-2210358
closesodoo/odoo#47235
X-original-commit: a0d983e94e3681a3f3e55cc445defc1ec862c606
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The urlpicker was not closing properly when a value was selected.
Part of: https://github.com/odoo/odoo/pull/46640
task-2210358
X-original-commit: 6f722d919cd650d5c0b1b9c4a878fd519267c348
- Create 2 companies A & B
- Set the website in A
- Set the user in both companies, main company being A
- Create a SO template in company B
- Click on "Design Template"
An AccessError is raised because:
- `slug` accesses the `display_name` of the template which is in company
B
- the `allowed_company_ids` is set to company A in [1]
A solution could be to always set:
```
context['allowed_company_ids'] = request.env.user.company_ids.ids
```
But the side-effects could cause other issues.
Therefore, we handle the `slug` manually.
[1] https://github.com/odoo/odoo/blob/af411b866aa2052c01168342f8f05ae3dabad83e/addons/website/models/ir_http.py#L203
opw-2194103
closesodoo/odoo#47249
X-original-commit: 0bcfffd291aceb74a5260a49d2fa3032f511dba1
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Purpose
=======
We don't have the description of the payment terms in the online SO
even if we get it on the report.
Specification
=============
Fix the bad usages of t-field on the website quote.
task-2186685
Closes- #46815closesodoo/odoo#47116
X-original-commit: 0f622ae61dcbb454b5d7a4124dfcc5187085a64d
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
purpose of this commit is to change the field type
of min_quantity from int to float on product pricelist
object
task:2165208
closesodoo/odoo#45792
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
When passing a default field chain to ModelFieldSelector, the page data is
not set correctly for the relational field. To understand the issue :
- login to v11 enterprise all db branch in runbot (debug mode recommended)
- create a mass mailing, add subject, select 'Contact' in `Recipients` field
- click on domain selector and select 'Company' from ModelFieldSelector popover
- click somewhere else to close the popover
- again open domain selector and observe the popover
Current behavior : fields of `Contact` are visible in the page even thogh
`Company` is selected in the ModelFieldSelector
Expected behavior : fields of `Company` should be visible
This commit fixes the issue by correctly pushing the page data
in ModelFieldSelector.
task - 2058702
closesodoo/odoo#47231
X-original-commit: 5746c2705c324b124445f38ead4f75624b3f99e3
Related: odoo/enterprise#9124
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Steps to reproducethe bug:
- On an existing product P, add alternative products under the eCommerce tab
- Go to the website
- Check that the compare button is enabled on the main shop page
- Turn off comparison button in the list under customize menu
Bug:
The compare button is still available on the alternative products of P.
opw:2201874
closesodoo/odoo#47230
X-original-commit: 9bf0d15ff4e1fcb9d7003d06f7e904cc9421b13b
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Before 13.0, the "Payment reference" column was linked to the 'ref' field.
In 13.0 it is linked to "invoice_payment_ref".
So the field reference was not visible in the list view
opw:2201763
closesodoo/odoo#47195
X-original-commit: 6acba443bd4e81c07eb5f4f48e1b4e554b4c5d13
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Let FEC report be generated by users having access to
full accounting feature or who are Accountants.
Task: 2210808
X-original-commit: 89fd50e47dcd4c6fda9342fce872283c18dc39b1
Let's assume a form view with a boolean field and a one2many field,
displayed for instance with widget many2many_tags. There is an
onchange on the boolean field, which populates the one2many, e.g.
[[5], [0, 0, {display_name: 'name', other_field: 'value'}]]
Before this commit, only the display_name was sent to the server on
save, because 'other_field' is unknown by the webclient.
Similar situations occurred with one2manys displayed as lists, and
onchanges returning values for fields that aren't in the list.
These situations probably didn't exist in Odoo yet, but a pending
task on website event adds one.
This commit ensures that all values returned by the onchange for
the x2many subrecords are sent back to the server when the user
saves.
closesodoo/odoo#46807
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
This commit fixes two issues that occurred in the following
situation: in a form view, have a one2many field F1 displayed as a
list, that contains another one2many field F2, displayed with
widget many2many_tags (in the list), and with a list in the form
(in the dialog). In the dialog, the list of F2 displays a
field, say 'name', which has an onchange that sets 'display_name'.
Moreover, there is an onchange in the (main) form view, that
populates F1 and F2, for instance, it returns something like: {
F1: [[5], [0, 0, {
F2: [[5], [0, 0, {
display_name: 'xxx',
name: 'xxx',
}]]
}]]
}
1) If the user opens a related record in F1, and adds (in the
dialog) a related record in F2, then validates the dialog, the
newly created record in F2 isn't correctly displayed in the
many2many_tags (the display_name is `false`), i.e. the onchange
hasn't been applied.
2) If field 'name' in F2 in the list is required, the new record
can't be saved, even if the user enters a correct value.
In both cases, the reason is that we use the incorrect viewType in
datapoints: as we don't specify that we specifically want 'list',
the 'default' one is taken, and we thus use the fieldsInfo of the
many2many_tags, which only knows field 'display_name'. As a
consequence, onchanges aren't correctly applied (issue 1), and
fields aren't correctly reset (issue 2).
Issue reported on task 2189529
When x2many fields are displayed with widgets like many2many_tags,
there is no limit on the number of related records to fetch and
display. In this case, the 'limit' attribute on the datapoints is
undefined. This could lead to weird issues when the limit is used
in computation, e.g.
var index = list.offset + list.limit; // = NaN
There are several occurrences of the above examples in the code,
which can be observed in specific scenarios, e.g. the one encoded
in the test. In this scenario, when the bug occurs, new records
added to editable list views are inserted on top (even if the list
is editable="bottom"), but the edited row is the last one.
Issue reported on task 2189529
Let's assume the following scenario in a form view:
- have a one2many field, say fieldA, displayed as a list,
containing another one2many, fieldB, (no widget, thus
displaying 'n record(s)')
- the one2many list is not editable, so there is a sub form view,
displaying fieldB as a list, and in this list some random field,
say fieldC, is displayed
- have a random field on the main form view, with an onchange to
populate the one2many
- set that random field s.t. the onchange returns something like
fieldA: [[5], [0, 0, {fieldB: [[0, 0, {fieldC: 'value'}]]}]]
- there is now a record in fieldA's list, displaying '1 record'
as value for fieldB
- click on that record to open it in a form view (dialog)
- in the dialog, in fieldB's list, we expect to have a single row
displaying 'value' as value for fieldC
Before this rev., it crashed when opening the record in the dialog,
whether the form view was inline or not.
The crash occured because fieldB was already in the list view, so
datapoints already existed for it (a list datapoint, and record
datapoints for records in the relation, in our example one record
datapoint). However, those datapoints didn't have the fieldsInfo of
the form view. When opening the form view, we added the fieldsInfo
of the form to the datapoint of the record we opened, but we didn't
recursively apply the fieldsInfo to its children. As a consequence,
when rendering the list view for fieldB in the dialog, we haven't
the information about fieldC, and it crashed.
Note that if fieldB wasn't present in fieldA's list view, it worked
fine because datapoints didn't exist before we opened the record in
the dialog.
Task 2120235
When installing website_sale_coupon, you are forced to install sale_management,
it shouldn't be the case.
Task Id : 2192587
closesodoo/odoo#46416
Related: odoo/upgrade#861
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This commit moves the product search input snippet options from a modal
to the option side panel.
Part of #45176
task-2189645
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Remove aggregation from `message_format `and `_message_read_dict_postprocess`.
There should be no functional change in this PR.
Purpose
=======
The existing code working with "tree" for aggregation and doing explicit "read"
or "search" for related fields does not seem necessary since the ORM of v13.
Considering that it adds complexity to the method, if its original purpose is
not necessary anymore, it would be better to change it.
The notable changes of the ORM that would justify this task are:
- single cache, shared between current user and sudo (which is called a lot in
those methods and might explain why the "tree" mechanism was put in place
originally)
- m2o and o2m being kept consistent with each other, which allows accessing o2m
through fields directly (instead of having to use "search" to ensure getting
consistent data)
Explanation
===========
Doing "read" or "search" could be counter-productive if the data are already in
cache because using those methods will lead to a query no matter what.
The ideal way is to simply access the fields through the records.
As for the "tree" and aggregation in general, the prefetch is automatically
taking care of that when iterating.
task-2180311
closesodoo/odoo#43841
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Currently, when clicking on the systray activity action icon and click on any
record from the activity, kanban or list view, not redirecting to its form view.
This commit adds the form view for that action and now click on record will
redirect to its form view.
task-2198480
Closes https://github.com/odoo/odoo/pull/46877closesodoo/odoo#47208
X-original-commit: 3fd30316c0af9a6ca2ea4962f2e2f832e68dee54
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Prevent unexpected loss of context.
closesodoo/odoo#47194
X-original-commit: d6299de8c83d56fc5e05ba0efd8558c4e5b21572
Related: odoo/enterprise#9111
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Active 'Round Globally'
- Create the tax:
Amount: 21 %
Tax Included
- Create the following invoice:
Line 1: qty 1.0, price 11.90
Line 2: qty 1.0, price 2.80
The Taxes amount should be 2.56 since we apply a 'Round per line' logic
in case of included taxes.
opw-2181486
closesodoo/odoo#47175
X-original-commit: a55bc67f0797f412c3bd82074c3f8f5d1497bce2
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This commit removes an unused and undefined variable that raised an error when
the user tries to answer a mandatory char_box question.
Oversight of commit: 0675d68afb
Task 2212021
closesodoo/odoo#47174
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
How to reproduce
================
You must have
- a form view with a one2many list
- in this one2many list add a column of a reference field
How to reproduce
1. open the record associated to the reference field
2. edit this record in the form modal view
3. click on save
-> Traceback
Bug
===
In `basic_model` the attribute `localData` become inconsistent
because of the method `_fetchReferenceData`.
We want to store the ID of the parent and not the all dict.
closesodoo/odoo#47171
X-original-commit: af411b866aa2052c01168342f8f05ae3dabad83e
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
from `message_format` and from `_message_read_dict_postprocess`.
The reading and initial formatting is done by `_message_read_dict_postprocess`,
which has been renamed more simply to `_message_format` due to its new goal.
This makes the methods easier to follow and does not increase the query count.
It actually reduces it when the data were already in the cache, by not always
reading them again.
Part of task-2180311
PR: #43841
This makes the method easier to follow and does not increase the query count.
It actually reduces it when the subtype data were already in the cache, by
not always reading them again.
Part of task-2180311
PR: #43841
in `message_format` and in `_message_read_dict_postprocess`.
This makes the method easier to follow and does not increase the query count.
It actually reduces it when the notifications and tracking data were already in
the cache, by not always reading them again.
Part of task-2180311
PR: #43841
in `_message_read_dict_postprocess`.
This makes the method easier to follow and does not increase the query count.
It actually reduces it when the attachment data were already in the cache, by
not always reading them again.
The `has_access_to_model` is removed and replaced by `sudo` because:
- from portal everything is sudo so it's pointless to check access on top of it
- from backend, it's almost impossible to trigger the case, and it's not like
returning is_main True would leak any sensitive information to an employee
Part of task-2180311
PR: #43841
It was partially tested already as part of some other performance tests, but
this new test will cover more specific cases of `message_format` and
`_message_read_dict_postprocess`.
The goal is to ensure the performances are not made worse by the following
commits, or even to be able to notice when they are made better.
Part of task-2180311
PR: #43841
Similar to what is done for the other tests, mute unnecessary log such as
`odoo.tests: skip sending email in test mode`.
Part of task-2180311
PR: #43841
In order to ease user comparison of expected vs actual delivery date in
sales orders, we make it so there are only 2 dates displayed in the
form related to expected/actual delivery dates. This is done by hiding
the 'expected_date' after the first delivery has occurred (i.e.
'effective_date' is non-empty) when a 'commitment_date' value is set.
If no 'commitment_date' value is set, then we display the 'expected_date'
so users still have a date to compare to.
This is addresses specification 10 of overall usability improvement task.
closesodoo/odoo#45724
Task: 2041853
Related: odoo/enterprise#8566
Related: odoo/upgrade#904
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Product purchases triggered by a stock rule currently searches existing
draft RFQs for matching 'partner_id' and 'company_id'. This commit makes
it so it also takes into account 'user_id' (i.e. "Purchase Representative")
and only selects ones without a user_id so as to not randomly add lines
to POs of different Purchase Representatives.
Supports Task: 2041853
Make it so documents auto-generated by other actions have Odoobot set as
the creator rather than the user triggering the action. This includes
the following documents:
1. Delivery (stock.picking) - generated by Sales orders (including MTO)
2. Purchase orders - generated by dropshipping, manual replenishment,
and run scheduler
3. Manufacturing orders - generated by made to order (MTO)
This is addresses specification 2 of overall usability improvement task.
Task: 2041853
This commit makes it so the order of the products in the Operations tab
of a transfer (stock.picking) form is the same order in the "Picking
Operations" report. Previously the products were being printed by
product id in the report and this is no longer desired as it makes it
more difficult for stock managers/workers to work. This addresses
specification 4 of overall usability improvement task.
Task: 2041853
This commit updates product, stock and manufacturing views for improved
usability. Handles view only changes of overall usability improvement
task. Specifically spec numbers:
1. Add "Run Scheduler" (from stock) to the manufacturing app under operations
5. Make "detailed operations" wizard modal have more intitutive footer
buttons (i.e. don't say "Confirm"/"Cancel" when changes aren't
possible.
8. Rearranging of vendor pricelist view
9. Updating of tooltip content for "property_stock_account_input_categ_id"
Task: 2041853
This PR adds some compatibility fixes needed for a rather large set
of improvements to make using sign easier on a mobile device (sign is
an enterprise module; cfr. enterprise PR counterpart for details).
- Adapt some CSS rules to fix the control panel
- Avoid displaying the keyboard on the name_and_signature widget (mobile device)
- Allow _ir_act_window_ to display on fullscreen on mobile
Task 2155601
Counterpart odoo/enterprise#8871closesodoo/odoo#47110
Forward-port-of: odoo/odoo#47025
Forward-port-of: odoo/odoo#46520
Related: odoo/enterprise#9085
Signed-off-by: res-odoo <res-odoo@users.noreply.github.com>
Otherwise, users will ending up with broken templates if
they update from v12
closesodoo/odoo#47120
X-original-commit: 3f84cae060c62839e8d493c0b90539363469f5f3
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
Step to reproduce:
1. Go to sign
2. Click on the button 'Share' inside a template.
3. Click on Sign now'
4. Click on a field signature
5. Draw a signature
6. Resize the browser
Before this commit the code of the widget drops the content when a browser is triggering a resize.
But with a mobile devices (like Android phone). A resize event is trigger when the keyboard is displayed.
=> The resize drop redraw all the widget content when the user fill the displayed input.
Task ID: 2155601
X-original-commit: a6af5a12efb0da9d8ee7526e6b4738c9595f9816
Now if you use the data attribute 'data-mobile' inside a type="action", we
can now send some specifics options on the dialogs.
Here a sample to open an action dialog in fullscreen on mobile:
Here the original action:
```
<button name="%(sign.action_sign_send_request)d" type="action" class="btn btn-primary btn-sm mt8 o_kanban_sign_send_request" context="{'sign_directly_without_mail': 0}">Send</button>
```
Now if you define the data-attribute data-mobile to allow fullscreen like:
```
<button name="%(sign.action_sign_send_request)d" type="action" class="btn btn-primary btn-sm mt8 o_kanban_sign_send_request" context="{'sign_directly_without_mail': 0}" data-mobile='{"fullscreen": true}'>Send</button>
```
Task ID: 2155601
X-original-commit: 66f99636d2d8bd850e33ed6c8f272eb662d835f7
The content of the "wysiwyg.fonts" module is duplicated in
"web_editor.base". This is a mistake that was introduced with the
revert of the saas-12.2 editor.
This duplication is the cause of github issue https://github.com/odoo/odoo/issues/44689.
This commit fixes the issue by requiring the correct module in rte.
closesodoo/odoo#46865
X-original-commit: 8bc3fd2c41c1d0fc1fa22e0849a7204b6712d7b2
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When leaving a channel, remove the earned karma in addition of the
slides.
This way, the user goes back in the same state as before completing
the course.
Add a message to clarify to the user the impact of leaving a course.
Add a test to answer questions
opw-2199066
closesodoo/odoo#47166
X-original-commit: a5e66d681ccd760c0af7bd0b179b5e42c76577ba
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
jvm-odoo