Wrong key in default_get. It should be `company_id` instead of `company`
closesodoo/odoo#39448
X-original-commit: 0859a5b073aeadf7cfa5e32b7c45cce7a1933f0d
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Currently, the "Opportunity restored" note appears while changing the tracking
field's value, which is incorrect.
The "Opportunity restored" title should only appear when the modification is
done by clicking on the "Restore" button.
Thus, make a condition proper to display this title "Opportunity restored".
task-2089784
closesodoo/odoo#39447
X-original-commit: 14453bf9dc6677056329b4599c798d6bf5273980
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The issue is the following: if both fields F1 and F2 are computed by the
same compute method, actions based on changes on F1 may not be triggered
when F2 forces their recomputation. This is caused by the API of the
method `_compute_field_value` that takes as parameter the field that
triggered the recomputation. The method must consider all the fields
computed by the method.
closesodoo/odoo#39440
X-original-commit: ceddb710a17e552061b9ad3cbc2647d7eae6567d
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Steps to reproduce the bug:
- Create an event E with max available seats = 1
- Register to E with public user and leave the cart
- In backend, register an attendee for E and confirm it
- Go to the cart, try to update the line with the registration
Bug:
The line was not updated to 0 and so the customer had to buy an unavailable
ticket.
opw:2091720
closesodoo/odoo#39439
X-original-commit: af3938eb3f97a8c8804130788c18b515da1d84e7
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
From now, you need to explicitely add sitemap=True if you want your controller
into the sitemap.
It's the default value, but if you forgot it, it will raise a Warning on runbot.
It will avoid wrong controller in sitemap and duplicate (empty) content.
From now, if your model contains a field website_id, the modelConverter for
sitemap will automatically add the domain:
"[('website_id', 'in', (False, current_website_id))]"
It avoid redundant declaration and ugly url in redirect/rewrite view.
Migration: need to remove it from url_from in website.rewrite
task-2065018
closesodoo/odoo#39427
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
To reproduce the issue, go in the settings of the employee app,
simulate a slow 3G connection, modify the working hours:
* Select the first one, modify it but don't save it,
* Click on some others working hours consecutively
They will be all editable
* Edit them quickly
Before this commit:
- You get an error
After this commit:
- You get no error and the behavior is the same than in V12:
the working hours are updated consecutively
Note: when you stress the relational field quickly, there is a moment
where this.$el is undefined. This is the reason why the error is raised.
OPW-2088558
closesodoo/odoo#39435
X-original-commit: 2acb76ffbb2f1ca2a6af0e316da15ce605f2273a
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
On a delivery type picking, adds a button to able the partner to sign
the delivery on receipt.
task-1878607
closesodoo/odoo#39183
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Co-authored-by: sle-odoo <sle@odoo.com>
Remove SignatureDialog from `signature.js` to put it in its own file,
`signature_dialog.js`. The purpose of this change is to be able to
require SignatureDialog in any other file and to separate dialog and
field business.
task-1878607
Before commit: - If there are multi level production order,
and user cancelled any one then,
there is no activity logged on related production order.
After this commit: - In multi level production order
(i.e. one production order creates another production order
to consume the raw material)
if user cancelled raw material production order then,
exception will be generated on main production order,
so that user can easily get the idea that
raw material for this production order is not available.
[ADD] sale_mrp: add testcase for cancellation of the multilevel production orders
task-1819526.
closesodoo/odoo#28708
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
When installing point_of_sale, the admin user only belongs to
group_account_invoice and not on group_account_user. Because of this,
the record rule define in point_of_sale that allows access to
account.bank.statement and account.bank.statement.line models does not
work as intended. This commit now allows read access to the said account
models.
Task-id: 2083597
X-original-commit: b521605c166ba03079bc15899a7dc3129326c98c
Before this commit, the "Expiration Alerts" search filter for quant
return a traceback because it tries to render hours/minutes/seconds but
there aren't supported. This fix just removes them.
closesodoo/odoo#39416
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
The last step of the 'course_member' test tour adds a new rating on the course.
This commit improves the test by actually checking the rating is added.
At the same time, we fix a potential build error caused by the fact that the test was closed
potentially before finishing the rating request.
Task#2091810
closesodoo/odoo#39393
X-original-commit: e26e99fae06d49f83ed2bfc9927dc60ec1af3b83
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
* web_editor
Commit https://github.com/odoo/odoo/commit/7e2b0ebe7996c9fa35f75949b7fc8cd5a58d7c36
broke the website JS loading as it added a dependency to a lazy loaded
JS module which was not even always lazy loaded.
A test so that this does not happens anymore will be made in another
commit.
Related to task-2092386
closesodoo/odoo#39391
X-original-commit: 5ac269d722f9ff8c206215dd1c07b8544cfd5382
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
With product_expiry, when a workorder is done, we check if there is
expired lot in components. If it is, we ask confirmation to the user.
Task #1938656closesodoo/odoo#36680
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
When user produces for a Manufacturing Order, if he/she uses an expired
component, a confirmation wizard will ask if he/she really wants to use
this component.
Task #1938656
The production lot expiry alert was based on the field `alert_date`.
Now, it will be based on the field `life_date` since if user set only
one field, there is more chance this field will be filled but the field
`alert_date` will not.
Task #1938656
When user tries to validate a picking with expired production lot,
displays a wizard for the confirmation popup. This wizard shows which
lots are expired.
Task #1938656
Adds new product field, `use_expiration_date`, to know if user wants to
use expiration date on product. Only accessible when product is tracked.
Also, changes fields' name:
- product.template: life_time becomes expiration_time
- stock.production.lot: life_date becomes expiration_date
Task #1938656
Task 2076182
It makes no sense to allow creating draft entries for closed periods as it will never be allowed to post them! Directly warn the user seems smart.
At the same time, we should be able to duplicate entries from closed fiscal years without any errors. So, if we duplicate an entry from a closed period, we should replace the accounting date by the first "open" accounting date.
In order to keep the audit trails, we should keep the history in the chatter.
closesodoo/odoo#38699
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Task 2074811
Allow to specify on an account the journals that can be allowed
Example of use case :
* I create an IFRS journal and some specific IFRS accounts
* I want to make sure that the accounts I configured for the IFRS are
only use to make entries in the IFRS journal
In this commit we also prevent from changing the configuration of a
journal if there are account.move.line that should not have been allowed
to be created with the new configuration.
closesodoo/odoo#38255
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
In e-commerce module, when you have a free product and 2 delivery
methods:
- Free
- Any delivery method with a fixed price
When you confirm your cart, you have to choose a payment method.
If you select "free delivery" and "wire transfer":
Before this commit:
- You get an internal server error
After this commit:
- You are redirected to the wire transfer confirmation
OPW-2083778
closesodoo/odoo#39328
X-original-commit: c87398ac1e6c49555a1e34ebf4e0ec714baa9ff3
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When duplicating maintenance request, the stage should be reset to the
first one (which is +/- what the default does).
Fixesodoo/odoo#38558closesodoo/odoo#39327
X-original-commit: 14642826601070960fdd79ebd74ebd407e00617c
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
In the leaves app, you can create an allocation request where you can
select a leave type.
Before this commit:
- The leaves type order is not correct when you have a lot of them.
You should have your remaining leaves on the top of the list.
When you click on search more, the order is correct.
After this commit:
- The leaves type order is correct.
Odony's comment: Leave types are reordered after each search(), based on
some context-dependent, non-stored conditions. The problem is that the
initial search() applies the given *limit*, so the "post-sort" will only
sort a limited number of random result from the initial search,
rather than all types matching the domain.
If you have more than 7 leaves types matching the domain, you have a
chance that the m2o auto-completion on the leave request form will not
suggest the correct leave types, because the post-sort will not even
receive them. So you may not see a leave type for which you have
remaining leaves!
OPW-2089593
closesodoo/odoo#39372
X-original-commit: 04e85efb82f257c01ea056c759eb1b2cec078188
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: odony <odo@odoo.com>
Steps to reproduce the bug:
- Go to Settings > Technical > IAP account >
- Remove the access token
- Go to Contact
- Try to create a company called 'Proximus' and click on the autocomplete
Bug:
A traceback was raised because the IAP account token was not set.
opw:2087607
closesodoo/odoo#39099
X-original-commit: bc6357f0b95d354afa602eecce24a3c265819101
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Install MRP and Accounting
- Create a user with only 'Billing' as access right
- Create a customer invoice
- Add a line, type some text (e.g. 'desk'), then click on 'Search
more...'
An `AccessError` is raised.
It arises because of this:
https://github.com/odoo/odoo/blob/e2d7cf7898704c82f25556b0b0edb87c05ec5903/addons/mrp/models/product.py#L112
The user has no access to `mrp.bom`, leading to the error.
Since the user has access to stock moves and pickings (thanks to the
rules `access_stock_picking_invoicing_payments` and
`access_stock_move_invoicing_payments`, it makes sense to give him
access to `mrp.bom` and `mrp.bom.line`. Moreover, adding a `sudo` on the
mentioned line could cause issues since `_bom_find` performs a search
which is company dependent.
opw-2089556
closesodoo/odoo#39365
X-original-commit: 59ea1993bc5ddb66675bfc2bff70a626cd14b645
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
*: website
Inherited colorpicker were not used due to the context missing the
website_id and the method call being used instead of call_kw.
task-2092386
closesodoo/odoo#39357
X-original-commit: 7e2b0ebe7996c9fa35f75949b7fc8cd5a58d7c36
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
So we have to adapt
- the sanity checks
- the immediate/backorder wizards
- split the call to _action_done with and without backorder
This is a preliminary work to remove all the override in
stock_picking_batch and to allow choosing the pickings to immediate or
backorder directly in the wizards.
Before this commit, both wizards were calling _action_done and one
another. We make them go back through `button_validate` so that it is
more sane to handle and allow future extensions to add pre-action done
wizards.
Also the first part of button_validate is some sanity check. We adapt
them to be multi (inside of a loop over self) without any other
changes.
Now the wizard can work on the records (immediate: write the done
quantities) or work with the context (backorder: picking ids to not
backorder in the context).
Also we adapt the stock sms weird wizard (a confirmation wizard but the
feature is auto installed? wth). Now there it isn't manually called in
the middle of button_validate but it uses the pre_action_done_hook.
task-2069646
Shop page link and popover use the same route which make a write on db
to recompute coupon lines. Can lead to concurent updates if unlucky on
timing.
closesodoo/odoo#39356
X-original-commit: 14253c412be8078290e808fe255c746afa79cc9c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
shop page link and popover use the same route which make a write on db
to recompute coupon lines. Can lead to concurent updates if unlucky on
timing.
task-2070507
X-original-commit: f7c64081f6a41884ddea2a914d48d91750e48d41
Raising a python error cannot stop an uninstall, however since the
unlink stops early, the calls to super() are never reached, this
prevents the deletion of module-related data and leaves crap in the
database, not to mention that it potentially prevents the reinstallation
of a module because of duplicate data with unique IDs, which is the case
for mail.
With this patch, we let the registry delete everything related to the
mail module when uninstalling, which allows for its reinstallation.
Fixes#25138closesodoo/odoo#39347
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
This commit allow users to set up different colors for both
the live chat button for website visitors and the chat window
once the live chat button has been clicked. For both, the header
background color and the text color can be set up.
Task-Id 2030383
closesodoo/odoo#35843
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Use correct company to get fiscal positions and properties
Ensure company used to fetch fiscal positions is always the correct one
when coming from a company restricted model (company_id required, or
related.required).
purchase: get_fiscal_position doesn't consider company_id ctxt key
others: properties were accessed with potentially the wrong company.
The reloading of the registry causes cache misses when creating or
modifying automated actions via Odoo Studio. Right after the reloading
happened, some field is computed in an environment `env` that no longer
appears in `Environment.envs` (collecting existing environments),
because the latter has been explicitly reset. Performing `sudo()` or
`with_context()` in the compute method creates a new environment that
appears in `Environment.envs`, and uses a different cache from `env`.
The recomputed field is thus stored in the other cache, and retrieving
its value from `env` issues a cache miss...
The fix consists in re-patching the registry models without reloading
the registry from scratch.
opw:2082497
closesodoo/odoo#39342
X-original-commit: c99ad25d4c6affeed75b40e8bc8eeffe87873e48
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
- Create a user with rights 'Billing' only
- Create an invoice, post
An `AccessError` is raised.
This is because the user has no access to the pos order.
opw-2089587
closesodoo/odoo#39333
X-original-commit: d9d1f8099067e4de4891acbd6553c34eafff20a1
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create a user with 'Billing' as only right
- Create an invoice with this user
Errors pop up, `CacheMiss` blablabla.
This is because `invoice_sequence_number_next` and
`invoice_sequence_number_next_prefix` are not set.
X-original-commit: cf0f5a782954f4ad3c475507892851a0e0efe2e1
David Tran