[FIX] *: selectors in tours
[FIX][TMP] account: CogMenu selector in tours
[FIX][TMP] web*: Breadcrumb targetting in tours
Adds a `o_breadcrumb` class to target the whole breadcrumb, no matter
how much elements it contains (collapsed parts, visible path, single
name...).
add classname on last breadcrumb item
[FIX][TMP] project: View buttons selector in tours (moved away from CP)
[FIX][TMP] project: Kanban selectors in tours (quick create)
[FIX][TMP] *: SearchBar selectors in tours (toggle menu)
[FIX][TMP] *: ButtonBox selector in tours
[WIP][IMP] web: add toggleSearchBarMenu in search helpers
adapt and unskip 3 list tests
adapt and unskip calendar tests
unskip web_tour test that actually pass
post rebase fix
allow to lose cell focus after multi edition (given to searchbar) - bug reported, to check later
post rebase fixes
fix
Part-of: odoo/odoo#116641
This commit adapts the directional icons to improve the usability and
maintain consistency with the ui icons library.
task-2818586
Part-of: odoo/odoo#116641
*: hr_holidays, stock, sale, product, web, sale, purchase, stock,
website, survey
Adapt some custom control panels (mainly for custom reports) to the
milk controlpanel.
hr_holidays:
Move the buttons to create a new time off or a new allocation to the
"create button" slot and transform it into a dropdown (creating
allocation requests is clearly a secondary action, not a primary one)
stock:
3 lines does not fit, must be on 2 lines
Part-of: odoo/odoo#116641
This commit brings the ControlPanel into a single line with 3 main
sections:
- buttons & breadcrumb
- layout related actions (ie. the SearchBar in multirecord view or
ButtonBox in formView)
- navigation (pager, switch view...)
Add new search bar menu, this is a merge of the following components
into one big component display in column:
* comparison_menu
* favorite_menu
* filter_menu
* group_by_menu
Also adapt navigation hook.
Part-of: odoo/odoo#116641
Change the rules for the activation of the unwanted replenish warning.
Before :
Verification for unwanted replenish were only done if the
stock_orderpoint have a max qty >= 1
After :
Verification for unwanted replenish are done if the
stock_orderpoint have a max qty >= 0
task : 2918947
closesodoo/odoo#121144
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
test_reordering_rule_1 try to ressuply 10 from RR.
However since 15.0 the picking `action_confirm` will
launch himself the required orderpoints to order the
missing quantity. So the run scheduler is useless but
should not order the quantity again since it's already
process.
But in the test the cache for the orderpoint is not
always consistent with the data. It happens that the
quantity forecast remains -10 even after the RFQ creation.
It happens due to the savepoint. It will flush the data
and take a random env. However in the enviroment, the
active_test key could be there. And it will recompute
all the fields. So it goes through `_compute_rules` that
call `search_rule`. There is an archived route from supplier
to stock. So it will pick this rule instead of the buy route.
`_compute_lead_days` will not have the supplier delay as
a result and a wrong forecasted date. `_compute_quantities`
on product will check the virtual available for this date and
will only have the out move and not the in since the domain
is incorrect with the wrong lead days date...
I can't do much since it's due to the orm.
- Remove the savepoint but it will require a global refactoring
- Fix the ORM, it's planned but difficult.
So for now I just remove the context key form the context in the
compute.
Note: this could happens outside the test when there is more than
1000 RR.
closesodoo/odoo#121106
Signed-off-by: Tiffany Chang <tic@odoo.com>
Steps to reproduce:
- Install purchase, inventory and manufacturing.
- Now create a subcontractor, with it's corresponding location, it's set
by default.
- Go to this new location and set it as replenishment location.
- Now create a Request for Quotation using this subcontractor.
- We will receive a traceback whent trying to access replenishment.
Issue:
We got a traceback caused by the fact that we are trying to set
as replenishment location, a location that doesn't have a warehouse.
Solution:
We need to add the handling of this case, so we won't always need
a warehouse for the orderpoint.
opw-3164276
closesodoo/odoo#121065
X-original-commit: 874e42463c2077980b9b4ce3903030c980285d51
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce the bug:
- Connect with the company A
- Create a consumable product “P1”
- Create a receipt transfer with this product
- confirm the transfer
- Come back to the product form
- limiter le produit que a la “Company B”
Problem:
no user error triggered
Go to inventory > operation > transfer: a Traceback is triggered
Before this commit, there is no verification while changing a product's
company for consumable. That can lead to an issue where some operations
cannot be done because of access errors. To avoid that, this commit
prevents to change the product's company if some move lines for this
product exist in another company.
opw-3300559
closesodoo/odoo#120983
X-original-commit: a6666de7f492f9f94abc23a080134dd473d0dddc
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
In the case of draft pickings/MOs, the reception_report_main
component's "Assign All" button was NOT disabled, which could result
in an IndexError if the button was pushed. Note that this issue does not
occur for the "Assign All" button within a table because the button is
correctly not shown at all when there are no assignable lines within it.
Noticed during task: 3046178
X-original-commit: 403d1ba5839d6073ee6321e77863f928336158ba
Part-of: odoo/odoo#120935
Steps to reproduce:
- activate Reception Report in settings
- create outgoing picking for a product (qty > qty in stock)
- create an incoming picking for the same product with a non-int qty
- confirm the incoming picking + click on "Allocation" smartbutton
- assign product to outgoing picking + click "Print Labels" (either at
top of report or within the table of outgoing moves)
Expected result:
Labels and created + printed
Actual result:
ValueError because int() is called on a non-int value within the label
template
Note that the the `onClickPrint` within the reception_report_line.js
already correctly did the Math.ceil rounding on the qty
Noticed during task: 3046178
X-original-commit: 69c557a5c0b407333be45cd7434448fc36de899e
Part-of: odoo/odoo#120935
Before, when the user pastes a list of tracking numbers into the move
line's `lot_name` field (through the move's detailed view), a lot is
created for each line, creating a move line for each new lot, or
assigning each lot to an existing line with no lot.
With this commit, it will also take `qty_done` and `expiration_date` (if
`product_expiry` is installed) from the pasted list if it's relevant.
Each data should be separate either by a semicolon, either by a tab, and
the first data should always be the lot name.
Valid examples for lots and quantities:
lot-01;22
lot-02 12
Valid examples for lots, expiration date and quantities:
lot-03;8;01-02-2005
lot-04 2005/02/01 12-20
The only valid separation characters for the date are the space (" "),
the dash ("-") and the slash ("/"). Examples of valid dates:
20-02-24 20-Feb-2024
20 02 24 20 Feb 2024
20/02/24 20/Feb/2024
If any of the extra values can't be converted into either a quantity or
a date, the whole line will be used as the tracking number.
Also, if dates are pasted but the product doesn't use any expiration
date, the date's part will be ignored.
task-3171866
closesodoo/odoo#115401
Signed-off-by: Tiffany Chang <tic@odoo.com>
Remove links to UoM form since they are useless and lead to unused
forms.
Part of task-3218314
closesodoo/odoo#119381
Related: odoo/enterprise#40153
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Use filters instead of domains for the `stock.picking` lists accessible
from the menu 'Operations', so all pickings can be easily consulted in a
single view when removing said filter.
Part of task-3218314
Part-of: odoo/odoo#119381
When using the Reserve / Unreserve buttons on the forecast report, this
will [un]reserve every move of the picking / production. We want to be
able to do it on a product base, so that when using the [un]reserve from
the forecast of a product, it will only affect the said product.
Part of task-3218314
Part-of: odoo/odoo#119381
Currently `report.stock.quantity` has a field defined in it called `move_ids`:
`move_ids = fields.One2many('stock.move',readonly=True)`
This virtual field has no corresponding inverse field so when performing a search_read on the model, it fails
in fields.py when trying to do: `inverse_field = comodel._fields[inverse]`
In addition, this field is apparently not used anywhere in the source code and not queried in the SQL View.
This means the model can never be search_read by default.
Since this field is never used, it isn't stored, and the model is `_auto = False`, removing it won't break any database.
closesodoo/odoo#120715
X-original-commit: e3b1a887a772333ebdb1682ffbbb695fe86030c1
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Andrew Gavgavian (andg) <andg@odoo.com>
Steps to reproduce:
- activate `group_stock_reception_report` in settings
- activate `auto_show_reception_report` for the "Receipts" operation type
- create a receipt w/ any product + confirm
- create a return w/any product + confirm
- select both the receipt + return in the (Operations > Transfers) list
view > action > Validate
Expected result: both pickings are validated
Actual result: stacktrace due to expected singleton ValueError
enterprise PR : https://github.com/odoo/enterprise/pull/37518
task-3204596
closesodoo/odoo#120190
X-original-commit: b2ac4b2f30e15c4b8a50628798b2fc39d7d43331
Related: odoo/enterprise#40570
Signed-off-by: Tiffany Chang <tic@odoo.com>
*: web + adaptations in base, fleet, hr, hr_expense, hr_recruitment,
loyalty, lunch, mail, mass_mailing, note, project, stock, survey,
web_tour
**Foreword**
Since d19037e141 the rootnode class attribute for form/list views was
copied two times:
- on the o_view_controller div
- and on the root node of the view renderer.
Examples:
<form class="foo">...</form>
gives
<div class="o_view_controller o_form_view foo">
<div class="o_control_panel">...</div>
<div class="o_content">
<div class="foo o_form_editable ...">...</div>
</div>
</div>
and
<list class="foo">...</list>
gives
<div class="o_view_controller o_list_view foo">
<div class="o_control_panel">...</div>
<div class="o_content">
<div class="o_list_renderer foo ...">...</div>
</div>
</div>
**Issue**
This could lead to confusion and also unexpected styling issues.
See this PR #119815 to read a message JS Framework team has received.
See also another a fix that had to be made for x2m fields: 980244fa8
**Introduced Changes**
- in the form compiler, the root node attributes are no more copied to
the root div node of the compiled template the form renderer receives
- the root div node generated by the form compiler now has the
"o_form_renderer" class, which was removed during the recent form view
refactoring.
- the list renderer no more adds the root node class attribute to its
"o_list_renderer" div
- the X2ManyFieldDialog has been adapted too
- since View, X2ManyField & X2ManyFieldDialog both need to compute view
classnames derivated from the arch root node, an util has been
introduced to avoid duplicating code
- the whole codebase has been checked and adapted.
Related: odoo/enterprise#40418
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Whenever an user updates a company or a currency, the webclient has to
reload, to properly apply these changes. It is done automatically,
immediately after the rpc has completed.
However, before this commit, it would do that always, even if the rpc
has failed (for example, if the user tried updating an invalid field),
so the user would briefly see an error window, then the browser is
immediately reloaded.
With this commit, we only reload the webclient when the rpc succeeded.
closesodoo/odoo#119730
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
**Steps to reproduce :**
- Create a Product A, with no stock and a 0 min 1 max manual reordering rule (no sales lead time, no purchase lead time)
- Sell 10 of A with a delivery scheduled today
- In Replenishment, create a PO for A, confirm it with reception scheduled today
- Reschedule reception of PO in 7 days
**Expected Behavior :**
The forecast icon is replaced by an orange warning icon.
When hovering the icon, the user is warned that replenishing can lead to an overstock.
**Current behavior :**
In Replenishment, Product A has a forecast of -10 and Qty to Order is set to 11.
When the user replenish A again, the PO is created and may lead to an overstock.
task : 2918947
closesodoo/odoo#97802
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
The current view replaces the existing groups attribute of the inventory
page in the product template form view with two specified groups (with
only one of these groups being newly introduced in stock).
This commit changes the product view to utilise an xpath that adds the
single new group (stock.group_stock_user), instead of replacing the
content of the attributes.
closesodoo/odoo#119284
X-original-commit: 43c888bb4df26b608ee6b0bedfe41032b40cc883
Related: odoo/enterprise#40101
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
Steps to reproduce:
- Enable multi-warehouses (i.e. have a company with 2 warehouses:
warehouse_1 and warehouse_2)
- Set warehouse_2's view_location to a location within warehouse_1
- Check the warehouse_id of a location within warehouse_2
Expected result:
warehouse_id = warehouse_2
Actual result:
warehouse_id = warehouse_1
The issue with this is each warehouse may be configured with their
own routes/rules, therefore a product within warehouse_2 may not
follow the warehouse_2 routes/rules. Note that a nested warehouse
situation like this may occur with warehouses located in different
countries, but products from both warehouses are sold in the same
ecommerce store and `website_warehouse_id` only allows 1
warehouse to be assigned to it
closesodoo/odoo#119181
X-original-commit: 83613b56cadf1a12331db9d4d41ab688d68768e9
Signed-off-by: Tiffany Chang <tic@odoo.com>
If applied, this commit will solve the issue of the singleton when there are 2
quants with the same location and same products but one quant with a lot and
another quant without a lot number.
Steps to produce:
- Create one quant with location-1 and without lot number.
- Create another quant with location-1 but with the lot number.
- Create 3rd quant with location-1 with same lot number as step2.
The error will raise in 3rd step as it is not accepting the 2 quants where one
is with lot number and another is without lot number.
see - https://tinyurl.com/2hqrgmwm
sentry - 4024572562
closesodoo/odoo#119152
X-original-commit: 05a7f5c04804423cfc3a833a1b3f0b5eec3fc147
Signed-off-by: Tiffany Chang <tic@odoo.com>
When an orderpoint triggers a procurement for a product and the system does not find the procurement route, it schedules an activity remembering what was the error.
If a normal user without admin access rights, makes an action that triggers the orderpoints, like confirming a MO, the activity schedule is not creating due to an access error on 'write' operation to a Product Template.
So, all activity schedules triggered from an orderpoint should be created without checking access rights.
closesodoo/odoo#119066
X-original-commit: e7de0b7f88ad55f662319aabcc5d989367b8c659
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
The new backend version of read_group can simplify the
current overrides of read_group. Do it for each of them and
avoid making extra search (done with __domain) when it is possible.
Part-of: odoo/odoo#110737
To reproduce the issue:
1. In Settings, enable:
- Multi-Step Routes
- Storage Categories
- Packages
2. Create a Storage Category SC:
- Allow New Product: same
- Max Weight: 100 kg
- Capacity by Package:
- 2 x Pallet
3. Create two locations L1, L2:
- Parent: WH/Stock
- Type: Internal
- Storage Category: SC
4. Create a putaway rule:
- When in: WH/Stock
- Package type: Pallet
- Store to: WH/Stock
- Having Category: SC
5. Edit the warehouse:
- Incoming Shipments: 2 steps
6. Create a product P:
- Type: Storable
- Weight: 1 kg
7. Update L1:
- There is 1 x P in a pallet
8. Create a planned receipt R:
- To: WH/Input
- Operations:
- 2 x P
9. Mark R as Todo
10. Create two packages:
- 1 x P in PK01 (! PK01 must be a Pallet)
- 1 x P in PK02 (! PK02 must be a Pallet)
11. Validate R
12. Open the related internal transfer T
Error: Both packages are redirected to L2 but one of them should be
redirected to L1
When checking L1, we ensure that the policy 'all same products' is
respected. To do so, we compare the products of the quants of L1
with the given product. Here is the issue: when moving a package, we
don't provide any `product` value to the methods used in the putaway
rules process.
Note: There was also another issue with the 'all same products'
policy. Suppose L1 is empty, and we move a pallet with two different
products, the move line is redirected to L1, which breaks the 'all
same products' condition.
OPW-3204924
closesodoo/odoo#118708
X-original-commit: 3a6d82de77e0ab477b3f22985f6d41995e25f652
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Currently, when a product with an expiration date is reserved, the
expiration date isn't checked when seeking which lot/serial to use. This
can lead to the shipping and delivery of already expired products, since
their expiration date came before their scheduled delivery.
Task-3203121
closesodoo/odoo#117138
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
To reproduce:
1. Manually create lot "0000001" for a lot product
2. Create a MO for this product and click generate-serial button.
Validation error raised since we are trying to generate lot/sn "0000001"
again.
When useing action_generate_serial, ir.sequence always try create a
lot/sn in form "00000dd". If user already created the same one, the
generation will fail.
We already tried to avoid this issue for sn in _get_next_serial() by
finding the latest sn and create new one base on it.
To fix, we also allow _get_next_serial to be applied to lot.
Part of Tast-3187003
closesodoo/odoo#118481
X-original-commit: dc69748ea2698077782d839cf7da48e987f17ffc
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Yuchen Huang (yhu) <yhu@odoo.com>
**Before this commit**
Almost all of the use cases of the `usePopover` hook are dealing
with an abnormal amount of complexity:
- they have to store the closing function of the popover, and sometimes
keep track to its opening state,
- you can find a duplication of a useUniquePopover hook, which is
anyway the behavior that is always wanted for popover users.
This is due to the fact that usePopover is just some kind of wrapper
to the lower level popover service.
**After the commit**
- The usePopover now has a new API, which simplifies its usage.
- The useUniquePopover hook implementations have been removed and
this "unique" behavior is now merged into usePopover
and has become the standard one (not configurable).
- All of the use cases have been adapted, even the cases where
components used directly the popover service (through `useService()`).
See the adapted jsDoc around the hook in popover_hook.js
closesodoo/odoo#118066
Related: odoo/enterprise#39654
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
When using message_post, the body format must be explicitly specified.
If html is expected, a Markup object should be used.
If text is given, the content will be escaped.
Before this PR:
message_post was unaware if the content of a message was HTML or
text. This lead to multiple situation where the content was
incorrectly considered as HTML and led to display errors.
In
self.message_post(body="Hello %s!" % self.name)
if the name contained HTML, it would be evaluated.
In
self.message_post(body="Contact Raoul <raoul@caramail.be>")
the email would not be displayed as considered as unknown HTML and
discarded by the sanitizer
Now each call must explict the type of content.
Use the escape() helper to properly combine Markup and translations.
It would also be acceptable to use Markup() to wrap a static
translation but escape is better as one can not guarantee the content
of a translation.
closesodoo/odoo#111850
Related: odoo/documentation#3612
Related: odoo/enterprise#36728
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
1-create a weight unit 'jm' bigger than reference
ratio 2.47541 rounding 0.001
2-create a stored product uom:'jm' / purchase_uom: 'kg'
3-set valuation method to automated (fifo)
4-create a replenishement for 200 (jm)
5-confirm and recieve the products
6-valuation for that stock move is null
Bug:
computations in the stock module are done with rounding method (half-up)
when computing the unit price the recieved quantity is computed with up
rounding which leads to a mismatch
Fix:
applied the same rounding method on all the Steps
opw-3213997
closesodoo/odoo#118251
X-original-commit: c305942958c73414def47ebd299227999841c6ed
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
before this commit, on clicking the picking calendar view, it allows the quick adding from the calendar view and entered value is going to the name field of stock.picking model.
after this commit, quick adding will be disabled and on clicking form will be opened with selected date.
closesodoo/odoo#118222
X-original-commit: c06f88c2535f959bc60416b6f32cb51ea1481c2a
Signed-off-by: Tiffany Chang <tic@odoo.com>
Since https://github.com/odoo/odoo/pull/104062, the location and
scrap location id fields on a scrap order are no longer editable
(even while still in draft).
To reproduce:
- Enable storage locations in settings
- Create a new scrap order
Bug: The source and draft location are readonly.
This fix restores the intended behaviour to make these fields editable
while in draft state and adds a test to confirm this behaviour.
Task: 3266655
Community PR: https://github.com/odoo/odoo/pull/117931closesodoo/odoo#118177
X-original-commit: 1dcc9ade1793a562e5df20336241d2a025c5e14c
Signed-off-by: Tiffany Chang <tic@odoo.com>
Before this commit, in large database, openning a sale.order can take 3s.
Because in module sale_purchase_stock, _get_purchase_order use a On2many field : stock_move_ids, with inverse field group_id.
Now it takes 200 ms.
closesodoo/odoo#117738
X-original-commit: 5fc448e7f6dcce94fb89b23be29c4d38a525dd97
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
An error appears when we try to change the product in transfer line via
product/search
steps to reproduce the error :
1- create 2 products : Test 1 (UoM is Cm) and Test 2 (Uom is g)
2- create a delivery order and add Test 1
3- UoM error due to the UoM not being updated at the time of change
The error was happening because when updating the product directly in
the line section , the stock_move item already has a UoM and the if
statement makes it impossible to change it , so the error appears.
opw-3231298
closesodoo/odoo#117504
X-original-commit: ece3dea8c1ab43a854a57513cc317e8618010542
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
Steps to reproduce the bug:
- Create a Storable product “C1” tracked by Lot:
- Update the Qty to 10
- Create a Storable product “P1”:
- Add a BoM:
- add 1 unit of “C1” as component
- Enable 3 steps for the manufacturing operation in warehouse settings
- Create a Mo to produce 1 unit of “P1”:
- Confirm the MO
- Click on related transfer:
- Select the “Pick component”
- check that the qty is reserved correctly
- Try to validate it without setting Qty done
- The immediate transfer is triggered, validate it
Problem:
The backorder's wizard triggers when it shouldn't
To know if we should create a backorder, we check if the qty reserved
is equal to the qty done, and as the qty done was not set correctly
during the validation of the immediate transfer, the two quantities
are not identical, therefore the widget is trigger:
https://github.com/odoo/odoo/blob/15.0/addons/stock/models/stock_picking.py#L1128-L1132
opw-3240264
closesodoo/odoo#117706
X-original-commit: dd44e1f69dfd217fafa9c2ec5da8b211b2ff3513
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
This commit converts almost all odoo module by native module.
The goal is to deprecate odoo.define in favor of native module and then
simplify boot.js by removing the regexp that finds module dependencies.
task id: 3162300
closesodoo/odoo#117305
Related: odoo/enterprise#39118
Signed-off-by: Géry Debongnie <ged@odoo.com>
Before this commit, if there is a demand for quantities and they are
available but reserved in transit (not yet in a stock location) they are
shown as not available.
To reproduce:
1) Have 2/3 step incoming shipments in warehouse
2) Purchase a quantity to create the incoming transfer
3) Validate the first step so that quantity is now in Input location
4) Create a MO with the component with quantity only in Input location
5) Go to forecast report of component, the quantity is shown not available.
closesodoo/odoo#117372
X-original-commit: 39ff1feae9f44b64ee3fff6ccee837ac4922ad1e
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Ahmed Khalaf <ahkh@odoo.com>
With this PR, the `digest_data` template has been changed, so the `digest_tips`
is not compatible with the new changes.
This commit changes the `digest_tips` data to be compatible with the new changes.
Below are the modules affected:
- account
- crm
- digest
- hr_expense
- hr_timesheet
- im_livechat
- mrp
- project
- purchase
- sale_management
- stock
- website
task-2717426
Part-of: odoo/odoo#89549
On the form of a storage category, the UoM of the weight is
hardcoded. This is incorrect as it could be `lb` thanks to the
option in the Settings
OPW-3204924
closesodoo/odoo#117236
X-original-commit: 57d3829d26d16d5360380aec4b7807fc381dd34a
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Steps to reproduce
==================
- Access a company with no records in transfer model (IT Company, SE Company, etc.)
- Go to transfers menu
- Click Studio
- Click form view button
- Click view tab on the left
- Click Show invisible elements
- Error "The requested change caused an error in the view. It could be because a field was deleted, but still used somewhere else"
Cause of the issue
==================
Since we are not editing an existing record, the PopoverWidgetField
component is loaded without a field value (it is an empty string).
This means that JSON.parse will fail
opw-3249161
closesodoo/odoo#117148
X-original-commit: ddb36467b401ec401b813182d172f5aab329baa7
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
before this commit, there is typo in unit of measure
after this commit, the typo will be corrected and
unity of measure will be updated to unit of measure
closesodoo/odoo#116764
X-original-commit: 11b89fcffe748e6119648dbc32594f0c0bdcf064
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
before this commit, for the company_id field
the user groups given was base.main_company,
such a group is not existing in the system
after this commit, the group will be changed
to base.group_multi_company from base.main_company
closesodoo/odoo#116939
X-original-commit: e259a33b0bff33005bc119838c517aec804695ae
Related: odoo/enterprise#38942
Signed-off-by: Tiffany Chang <tic@odoo.com>
The web client has a mechanism to invalidate the action and the view
cache: in the basic model (and the relationalmodel), some code is
looking for updates to some specific models (such as ir.actions) and
trigger a `CLEAR-CACHE` event. This event is then listened by the action
and view services to properly clear the caches. This mechanism was also
used to reload the page after editing a company, or reloading the
currencies after editing some currency.
With this commit, we modify the orm service to trigger an event after
each rpc. This event can then be used by the action/view service, and
also by the currency/company services to perform their specific cleanup.
This work is one step in the future refactoring of the relational model.
closesodoo/odoo#115655
Related: odoo/enterprise#38814
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Pierre Paridans