Currently using a customer with a company set on a lead without company
crashes, as it keep a void company on the lead. This is not compatible
with the company set on the partner itself.
OPW-2805181
Task-2888330
X-original-commit: 51be6cab5c4437ef56de5d1b25c0ba8486d25291
Part-of: odoo/odoo#94493
This commit introduces a node option 'keydown_debounce_delay' on the
character field and on emoji mixin, so that use can define the custom
debounce delay (in milliseconds) instead of fixed 2000 ms for
triggering an onchange on the field. Note that this delay will be
applied only when 'onchange_on_keydown' node option is also provided.
Also, we've utilized the odoo's debounce instead of the one provided by
underscore js, for 2 reasons:
1 - odoo's debounce is already well tested (see the file
/web/static/tests/core/utils/timing_tests.js)
2 - to take a step forward for reducing external lib dependency
task-2821978
closesodoo/odoo#94486
X-original-commit: ab80cdc0809e1347d201f21ac9474e66e9270f94
Related: odoo/enterprise#28822
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
The flow where we copy / paste the authorization code will be
depreciated. Because of that, we know use the newest authentication
system which use redirect URI.
Technical
=========
Now, the user is redirected to an Odoo endpoint "google_gmail/confirm"
and the access token / refresh token are automatically fetched.
Documentation
https://developers.google.com/identity/protocols/oauth2/native-app
Task-2852560
closesodoo/odoo#94476
X-original-commit: 69bd9bc6b36fdd55e8e859667bcddddad6db7d06
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to Reproduce:
- Connect as Admin
- Install event_booth_sale module
- Give only sales right to Demo user
(get rid of everything else (especially event)
- Connect as Demo
- Create a new SO
- Add an event_booth as product to the SO
- Try to confirm the SO
Issue:
Access error.
Cause:
When confirming the SO, we also update the selected event_booth
while the sales right are not enough to update event_booth model.
Solution:
Use sudo to update event_booth, since SO already confirmed.
Also fix unlink of booth, for the same reason.
opw-2823555
Task-2842621
closesodoo/odoo#94475
Forward-port-of: odoo/odoo#93983
Forward-port-of: odoo/odoo#88914
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When unlinking booths a check is done on sale orders to prevent their deletion when
a SO is linked and raise a nice error message. However as there is a group on the
field (coming from Sales app) we should sudo the filtered.
Task-2842621
X-original-commit: 9cdc2eec25dd57a74be993b0db0fd81460d6aed6
Part-of: odoo/odoo#94475
Notably using post-install allows to run event_booth tests even when sale
dependencies are installed. Otherwise they cannot run at install due to
required column not being filled in DB.
X-original-commit: aa769df87c0ef0e7ac6924c3e8f5595e8c82eba7
Part-of: odoo/odoo#94475
Steps to Reproduce:
- Connect as Admin
- Install event_booth_sale module
- Give only sales right to Demo user and remove event rights
- Connect as Demo
- Create a new SO
- Add an event booth as product to the SO
- Try to confirm the SO
Issue:
Access error.
Cause:
When comfirming the SO, we also update the selected event_booth
while sales rights are not enough to update event_booth model.
Solution:
Use sudo to update event_booth.
opw-2823555
Task-2842621
X-original-commit: 3f78c6aab091388afaf1e75fc8e9e66db5b8ab4a
Part-of: odoo/odoo#94475
In the `_stock_account_prepare_anglo_saxon_in_lines_vals` method, we
loop the moves' invoice lines but we called `filtered` on it to remove
ineligible lines.
That said, we have a conditional `continue` at the beginning of the loop
precisely for the same reason, which is redundant.
As it's better to filter out inside a loop instead of call `filtered`
(one loop instead of two), this commit removes the call to `filtered`.
closesodoo/odoo#94456
X-original-commit: a0a90fb20410d663d4615e7a055fce18c868116b
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Steve Van Essche <svs@odoo.com>
*: website_livechat
This commit is a step towards refactoring the JS of public livechat,
so that it reuses the same architecture as the code of Discuss.
This implies code that uses JS models and OWL components.
Task-2894102
closesodoo/odoo#94508
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Steps to reproduce the bug:
- Let's consider a project P with a task T
- P has has two stages S1 and S2
- From T, create a new sub task ST1 with a new stage S3
- From T, create an other new sub task ST2 and try to select S3 as stage
Bug:
ST3 was not displayed in the available stages
Fix:
The stage ST3 is available for every task or sub task
opw:2873640
closesodoo/odoo#94487
X-original-commit: 5254407f5a593f37a1f21d43a725504c8dc0ab6d
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
revert of https://github.com/odoo/odoo/pull/91209
Steps:
- Go to CRM, kanban view
- click on "Planned" button
- click on "Mark as done" button
- click on "Write Feedback" textarea
The activity dropdown disappears immediatly
opw-2884875
closesodoo/odoo#94470
X-original-commit: f59dab2ed666d5a71eb84d53c50bcdd15e264d96
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
The string concatenation would fail on False help_message.
Closes#93036closesodoo/odoo#94505
X-original-commit: 97e066b4cfda8ac34208f84753a40c10524ae989
Signed-off-by: Kevin Baptiste <kba@odoo.com>
The s_countdown snippet had 2 templates defined inside one file
(000.xml):
- One for showing a redirect message which is rendered in the
public widget flow.
- Another for showing an end message which is rendered and
appended to the snippet in the option flow.
The templates were loaded by the public widget, which means that even
if no end message was shown, the template would be downloaded for a
visitor.
This commit fixes that by splitting the file in 2, one for the options
and one for the public widget, ensuring that the option will load what
it needs.
(This is necessary for the task mentioned below, which moves the edition
to the backend, preventing the option from relying on a public widget
template.)
task-2687506
closesodoo/odoo#94118
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
* verify settings access for "Settings" user (`base.group_system`)
* Improve loading performance through the use of conditional groups inheritance
* Do not imply application administration groups for "Settings" users
* Fix wrong view inheritance (views hooked on content defined in siblings, not in parent(s))
Enterprise PR: https://github.com/odoo/enterprise/pull/27595
Task - 2858427
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#91909
Related: odoo/enterprise#27595
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Now that the settings user implies having internal user rights
(base.group_user), the access rules for users are applied and the test
test_system_user_should_be_able_to_reset_any_tokens failed.
This commit adds a generic ir rule giving all rights on gg calendar
credentials to "Settings" users, aka base.group_system group.
Part-of: odoo/odoo#91909
The field pos_employee_ids (pos_hr) links hr employees records to
settings records
but this model isn't readable for Pos Administrators by default.
This commit gives read rights on hr.employee model to settings users,
reusing a confusing existing ACL whose name targeted system users,
whereas the group effectively targeted was the internal users.
Since this rule didn't give any rights, we might as well correctly
replace
it so that the name can match its purpose.
Part-of: odoo/odoo#91909
Settings user is not able to access Bill of Material (mrp.bom) records
unless they have additional groups (account, inventory, manufacturing, ...)
This commit makes sure the operation is done in sudo so that any setting user
is able to save the settings.
Part-of: odoo/odoo#91909
Now that settings views are only loaded for the ones able to see their content,
the field group_cash_rounding might not be present if a pos manager without
account manager rights opens the settings.
Part-of: odoo/odoo#91909
Since #87636, delivery carrier model is referenced in the settings when
website_sale_picking is installed.
Because of that, users with only settings access are not able to
open the settings anymore.
This commit adds read rights on delivery carriers so that base settings
users are able to update settings.
Part-of: odoo/odoo#91909
It seems most accounting tests relied on the fact that the "accountman"
test user has both the user AND manager groups (but previously, the
manager group was given by the implied group relation "Settings" ->
"account manager")
Part-of: odoo/odoo#91909
For bugfix purposes, app administration groups have been given to
(implied by) the "Settings" group because without those rights,
opening/saving the settings crashed.
1) Do not load hidden view content
This commit uses the conditional inheritance of views
(depending on user groups) to avoid loading unnecessary view
& record content client-side.
This improves performance for admins without the specific application
admin rights, but also fixes the main bugfix problem,
caused by the webclient querying name_get for the records in relational
fields content.
Example:
sale_management adds a res.config.settings field to specify
the default sale.order.template for the current company.
If a 'Settings' user without 'sale.group_sale_manager' opens the
settings, he won't see this setting, but if a default template is
specified for the current company, the webclient will still request
the name_get of this template to the server, because the field
was present in the view, only hidden with a groups attribute.
With this commit change in sale, the field won't be in the view unless
you have the Sale manager group, avoiding the error/traceback/bug.
2) Remove implied application administration groups
Do not force the specific application groups on all 'Settings' user,
they globally do not need those rights, and if they need it, they
can add it to their account themselves.
3) Add a test to make sure settings user are able to manage settings.
4) Enforce 'settings' -> 'access rights' -> 'internal user' groups
As the previous test highlighted some 'false positives' because
it considered a settings user unable to read `crm.team`
and `stock.warehouse` records, we also took the opportunity to enforce
the fact that 'Settings' & 'Access rights' users must be internal users.
It makes no sense for a portal/public user to have access to the
settings, and didn't work anyway.
Part-of: odoo/odoo#91909
the div with id auth_signup_documents is specified in the view
`sale.res_config_settings_view_form`, which is not a parent of
`website.res_config_settings_view_form`.
This led to an error during view rendering because of the changes in
the following commit, where the sale settings view is modified to be
only loaded for sale managers.
Part-of: odoo/odoo#91909
Minor usability changes:
* Reorganize menu to be more consistent with other HR apps;
* Tweak several views;
* Don't expire contract when date is set to Today - they will be
automatically expired the next day;
* Show contract name on form view.
closesodoo/odoo#92604
Related: odoo/enterprise#27919
Taskid: 2856135
Signed-off-by: Kevin Baptiste <kba@odoo.com>
add the compare_list_price to /shop, if there is a compare_list_price and a
price_list price for a product, the fixed_price will be displayed
task-2813257
closesodoo/odoo#90195
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Rework and code cleanup of automatic invoice and auto-confirm order
flows.
task-2541188
closesodoo/odoo#72368
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Method: _find_mail_template()
Before this change, the method returned only the id of the template.
Now, it will return the template, as the method name suggests. Also, it
will simplify the method by avoiding complicated research into XML.
Code imported from #68965 that contained a new feature that was at last
abandoned.
Task-id: 2541188
Part-of: odoo/odoo#72368
Co-authored-by: Demesmaeker <edm@odoo.com>
Updating the scheduled date of a delivery doesn't update the quantity to
order of an orderpoint
To reproduce the issue:
(Need purchase)
1. Create a storable product P with a seller
2. Create and confirm a planned delivery D with 1 x P
3. Open the replenishment page
- There should be a line for P (Forecast: -1, To Order: 1)
4. Edit D and postpone the scheduled date
5. Go back to replenishment page
Error: The line is still present, its forecast qty is correct (0) but
the quantity to order is still 1 (instead of 0)
`qty_to_order` is a stored field, so when loading the replenishment
page, its compute method is not called. Moreover, even though
`qty_to_order` depends on `qty_forecast` and the compute method of
`qty_forecast` is called, it still won't trigger the compute:
when setting the value of `qty_forecast` from its compute method, it
will lead to:
https://github.com/odoo/odoo/blob/b54f78de307543efcea934206806f361eaac811a/odoo/fields.py#L1106-L1109
So, as shown and explained, we bypass the `write` of `BaseModel` and
skip the business logic and the recomputations
The compute of `qty_to_order` should actually be triggered earlier: when
we edit the scheduled date (step 4). That's the reason why this commit
adds a dependency to the compute of `qty_forecast`: it makes more sense
and becomes an implicit dependency of `qty_to_order` -> update the
scheduled date will trigger the compute of `qty_to_order`
OPW-2868167
closesodoo/odoo#94400
X-original-commit: 791b68fc02cbc4dc5b376e5fc5d37e725f88d0dc
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Follow-up of https://github.com/odoo/odoo/commit/0c30945d364a8b986f0b48db28e42c7b355471e3
Commit above changed the message formatter in python,
so that `attachment_ids` now always return a list of field commands.
This work fine in backend code of discuss, but in public livechat,
it still uses legacy code. The legacy code do not support field
commands, so instead it thinks the command is data of an attachment,
thus showing an "unamed" attachment.
Actually attachments are not supported in livechat. Code had some
handling of attachments just because this was shared with the
backend in the past.
This commit fixes the issues by simply enforcing showing no
attachment in any message in public livechat.
closesodoo/odoo#94394
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
This commit has as purpose to split the method `_is_add_to_cart_possible`
and put only the first part in another method so it can be overridden.
Issue:
The first part of the method _is_add_to_cart_possible check that the
product is active and can be sold.
The second part check if a combination is possible.
In sale_renting module, only the first part must be overridden since
second part is a common check to all product regardless if it
can or can't be sold or rent
opw-2879711
closesodoo/odoo#94373
X-original-commit: 99dc5a963002e887d5c4a9ad403e171b627d2e8a
Related: odoo/enterprise#28777
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
1. Activate anglo saxon accounting
2. Create product with automated inventory valuation and standard pricing
3. Set decimal accuracy to 6
4. Set product cost price to 0,01719
5. Create PO for 30.000 items -> price = 0,01782 -> total = 534,6
6. Receive goods -> stock journal entry = 515,7 (based on the cost, ok)
7. Create vendor bill
Price difference is incorrect if you have a tax rate in the vendor bill
`price_unit_val_dif` will be rounded to 0.02
Multiplied by a great quantity the result will be wrong (84.30)
Without using the tax rate the price difference amount is the expected one
This commit partially revert 643d91ef5ebfb29fde142294ced82c470d42c136
to improve the original fix.
opw-2849074
closesodoo/odoo#94346
X-original-commit: 315a18f12f9d67284bbd8b027ca652db17aae9d2
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
This commit duplicates the components Emoji and EmojiList into
other components called "LegacyEmoji" "LegacyEmojiList".
We do this so that we can implement the new EmojiPicker in Discuss
code, without affecting the code of `knowledge` during development.
When the Emoji Picker is in a good state with just the scope of
feature of Discuss, then we can integrate this new Emoji Picker
in other modules, like `knowledge`.
Task-2890268
closesodoo/odoo#94254
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
In picking type, we introduce a new setting ask-always-never setting for
creating backorder. When a backorder is needed, the behaviour will be
different according to this setting:
- ask: popup a wizard to ask if a backorder is needed
- always: generate backorder automatically
- never: no backorder
The main reasoning behind this change is that there are some scenarios
in which operators always create backorders (e.g. by validating the
transfer after scanning a pallet and setting quantities). Hence, always
asking if the user (operator) wants to create a backorder can be confusing.
task-2648993
Part-of: odoo/odoo#83462
When unbuilding a product, the selected source location is not applied
on the SM.
To reproduce the issue:
1. In Settings, enable "Storage Locations"
2. Create two storable products P_compo, P_finished
3. Update the qty of P_compo: 1 in WH/Stock
4. Create a BoM:
- Product: P_finished
- Components: 1 x P_compo
5. Process a manufacturing order MO with 1 x P_finished
6. Transfer the P_finished from WH/Stock to WH/Stock/Shelf 1
7. Create an unbuild order UO:
- Manufacturing Order: MO
- Source Location: WH/Stock/Shelf 1
- Destination Location: WH/Stock/Shelf 2
8. Confirm UO
9. Open the associated product moves
Error: The SML of P_finished is incorrect, its source location is
WH/Stock instead of WH/Stock/Shelf 1 (as a result, the quants are
incorrect too).
The issue only happens with P_finished. The destination of the
components is correctly defined:
https://github.com/odoo/odoo/blob/90a87d6ecd420c61ea8db8a6c571db477ee7220e/addons/mrp/models/mrp_unbuild.py#L229
(i.e., we use the destination location of the unbuild order)
OPW-2869454
closesodoo/odoo#94367
X-original-commit: 45ec5871a1ee6e3a31e790323f08df20715f4171
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
When selling a kit with a dropshipped component, the delivered quantity
will be incorrect
To reproduce the issue:
1. Create 3 consumable products P01, P02, P_kit:
- P02:
- Add a seller S
- Enable the dropship route
2. Create a bill of materials:
- Product: P_kit
- Type: Kit
- Components:
- 1 x P01
- 1 x P02
3. Create and confirm a sale order SO with 1 x P_kit
4. Confirm the generated purchase order (with vendor S)
5. Process the two pickings of SO
6. Go back to SO
Error: The delivered quantity of P_kit is 0 instead of 1
When computing the delivered quantity, because the `dropship` flag is
not set, we don't reach the revelant code:
https://github.com/odoo/odoo/blob/3db136f19480b31ca3f60a77c0c7354161bedde0/addons/sale_mrp/models/sale_mrp.py#L37-L44
OPW-2870893
closesodoo/odoo#94364
X-original-commit: fff6edad8cfb45b9a622bceefa4b83f620d7fe86
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
When a MO is generated in order to supply another one, the smart buttons
"Source MO"/"Child MO" are still invisible.
To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. Enable MTO route
3. Edit the warehouse: 3-steps manufacturing
4. Create 3 stored products Super, Sub and Compo:
- Sub has two routes: MTO and Manufacture
5. Create two BoMs:
- For 1 x Super:
- 1 x Sub
- For 1 x Sub:
- 1 x Compo
6. Create and confirm a MO with 1 x Super
Error: On confirmation, a second MO is created to produce one Sub, which
is correct. However, neither the first MO nor the generated one has a
link with the other one (through the smart button "Source MO"/"Child
MO")
When confirming the MO, a SM is created to bring one Sub to the
pre-production location. Thanks to MTO route, this will generate another
SM that brings one Sub from post-production to stock location (this will
lead to the creation of the second MO). However, the other SM (1 x Sub
from Post to Stock) doesn't have the same procurement group. This is the
reason why it is not found by the `_compute` methods.
OPW-2730830
closesodoo/odoo#94334
X-original-commit: 81e5ce05f2f79eb19489f00fb867143189fb38df
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
- Change some section and column headers to make content clearer based on MO status
- Add in columns/field for in progress MOs for easier tracking of MO status
- Update words to match field names more closely (i.e. Actual Duration, To Consume, etc.)
Task ID - 2688146
closesodoo/odoo#93066
Signed-off-by: Tiffany Chang <tic@odoo.com>
Sorting the `stock.quant` by lot_id didn't work correctly
Steps to reproduce:
1. Install Inventory
2. Edit a product tracking to 'By Unique Serial Number' (e.g. Acoustic
Bloc Screens)
3. Go to Inventory > Overview > Receipts, create a receipt for 3
Acoustic Bloc Screens with serial number '05', '01' and '03' and
validate
4. Go to Inventory > Reporting > Inventory Report, remove the
'Group By' filters and sort the entries by Lot/Serial Number
5. The serial numbers are not properly ordered ('01' is between '03'
and '05')
Solution:
Order the `stock.production.lot` by name
Problem:
Sorting the `stock.quant` by lot_id used the id of
`stock.production.lot`
opw-2879464
closesodoo/odoo#94358
X-original-commit: 4c855bd3eeb7ffcebd76eb4eaa1e41edf2935021
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
We only want the edi.format options to appear on the sale journals
(out_invoice, out_refund).
In addition, the warnings are no longer displayed on top of the invoice.
closesodoo/odoo#94376
X-original-commit: dca5a2844ef2e90c257b78add3e147b291a9fa18
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
Laurent Desausoi