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>
Steps to reproduce the bug:
- Let's consider a confirmed PO with one line L
- Create an invoice I and choose PO in the Auto-complete field
- The line L has been added and the Source Document has been filled with PO
thanks to the onchange function '_onchange_purchase_auto_complet'
- Save
Bug:
The field Source Domcument was not saved because the field is readonly
opw:2209893
closesodoo/odoo#47158
X-original-commit: 9fc3a4a6a16a205974d109c22e91b9c2cd250077
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Previous implementation crashes randomly in chrome headless due to timeout.
Avoid to do web action, while we just want to check reset_password feature.
+ add one test that reset password on partner from website 2 to check that
link match the domauin from website 2.
closesodoo/odoo#47136
X-original-commit: d8019f25a5cd6ed611295e9b93111402f4cad04a
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
- Install Inventory, Purchase
- General Settings/tick Multi-step routes
- In Warehouses/YourCompany
Incoming Shipments: Receive goods in input, then quality and then
stock (3 steps)
- Create a PO and add the same products on 2 lines. One has a scheduled
date in the future
- Go to transfers, where "Picking List" or "Procurement Group"
correspond to your PO
=> the 3 scheduled_date correspond to Datetime.now()
- Validate the first picking (WH/IN)
The scheduled_date (resp date_expected) in the remaining pickings WH/INT
(resp. stock moves) are changed to the past.
This is due to the fact that both moves are merged in subsequent
pickings. The cleanest solution would be to avoid the merge in case the
expected dates are different. Although this makes sense, that also
implies a change of behavior.
Therefore, we avoid such situation by preventing the propagation of an
expected date in the past, which does not make much sense when
propagating.
opw-2171509
closesodoo/odoo#47155
X-original-commit: c7b2341b35aabe394a34e14c48a913a8595737fc
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: Arnold Moyaux <arm@odoo.com>
The generic IAP flows forces us to commit the creation of a new record
to prevent the loss of his token once the system contacts iap.odoo.com.
Unfortunately, this operation can drastically alter any business flow if
it's not executed at the very begining or end of the flow.
Furthermore, it can be difficult to exactly pinpoint if this will affect
a flow (for instance, the point of sale is affected by iap because of
the module 'stock_sms' while the former doesn't depend on the later).
To avoid those issues, we isolate the account creation on a dedicated
cursor and load the values of the created record on the current cache.
closesodoo/odoo#47026
X-original-commit: 5307f47d975c3b3ebd87c7f7e2248802a1aa5be7
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
When we create a landed cost, we can now apply it on a
manufacturing order instead of a picking. Also, change
some Float fields in Monetary ones and add the currency_id
field in views.
task-2123752
closesodoo/odoo#44109
Related: odoo/upgrade#822
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
On the product form, when "Is a Landed Cost" is checked,
show a "Split Method" selection field. When creating a
Landed cost with this product, automatically
set the right split method on the line.
This behavior was removed by 24bca8fd4a
task-2123752
Add a way to create a munual stock valuation layer, create
a stock valuation layers implies :
- Change the stardard price with the new valuation by product unit in case of AVCO.
- Create a manual stock valuation layer with the added value.
- Update the remaining value of current valuation layer.
- If the Inventory Valuation of the product category is automated, create
related account move.
task-2123752
The private method _change_standard_price was incorrect in batch
and didn't contain a ensure_one check.
Fix to be batched and used this new version in the write method
of product.product model.
task-2123752
The views of stock.valuation.layer model
were in the wrong file,
move it, and merge duplicate search views. Also
remove the unused action 'action_stock_inventory_valuation'.
task-2123752
Sébastien Theys