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>
preliminary work for
- task 1938108 (which is adding a pre action done wizard)
- task 1938656 (which is adding another pre action done wizard)
- task 2069646 (which will rework all pre action done wizard to select to pickings to apply)
closesodoo/odoo#39318
Signed-off-by: Simon Lejeune (sle) <sle@openerp.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>
Before, en_US was almost always the default in case of 'no language'.
Now, that should be superseded by lang=None;
yet still, en_US plays the role of source language.
In a multilanguage database where en_US was not installed,
writing a translation with lang=None would crash.
This could prevent module installation.
A test is added to cover that case.
In the case where we write a record with lang=None, the source is the
same as the record; in that case the cache contains the value for the
field.name under the context keys en_US and None, so we need to
invalidate the cache to avoid getting back the old value.
co-authored with mart-e
opw 2088487
opw 2083710
closesodoo/odoo#39130
X-original-commit: 1a5a999c2dd69c9a6a2dacb59e8bf45b09c6bc13
Signed-off-by: Nans Lefebvre (len) <len@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.
Since https://github.com/odoo/odoo/commit/a5b6f31cf28e5381e1c85f66730bcdb55998e643,
the current companies of the user are saved in the context as "allowed_company_ids"
context key.
In case of invalid context content, the api was computing the intersection
between the context content and the user company(ies) and falling back on user
company_id(s) when catching an error.
A sanity check was done, but no feedback was given to the user,
saying that the context change was falsy.
This commits changes this behavior to :
* raise an AccessError when trying to access self.env.company(ies) when
invalid or unauthorized companies are defined in the context.
* take sudo mode into consideration, allowing inter-company impacts,
even when current user doesn't have access to a given company,
if the code is done in a sudoed environment.
Co-Authored-By: Raphael Collet <rco@odoo.com>
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>
This is a preliminary work for task 2088171 that will
improve server action creation usability in marketing automation.
When creating a marketing automation activity, one can choose to trigger a server action.
This task aims at improving a the usability of this option for non-technical users
as well as cleaning the view a bit (because so far we display the standard server action form view).
closesodoo/odoo#38922
Signed-off-by: Thibault Delavallee (tde) <tde@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
So far the weight of a delivery package had to be entered manually.
It is now possible to link a number of IoT scales to an operation type,
then select any of those scale in the delivery package wizard
to set weight automatically instead.
closesodoo/odoo#34782
Task: 1883775
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
- Create a product A with a barcode, UOM as 'Unit(s)' with a BOM
- Create a MO for A with more than one unit, validate
- Print the 'Finished Product Label (PDF)'
A single label is printed for all units, although it is not logical: a
label should be printed for each unit, as already done for the Zebra
labels.
In case the product UOM is 'Unit(s)', we print a label per unit. To do
so, we use a template similar to `label_transfer_template_view_pdf`.
opw-2091663
closesodoo/odoo#39311
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create a customer invoice or a vendor bill
- Add a product with any pre-defined tax
The tax line is not added.
This is because the account 2221 is set as 'Payable' instead of 'Current
Liabilities', as it is the case in other localizations.
For reference, the tax line is created then removed because:
https://github.com/odoo/odoo/blob/db2e6bc600364c00e8a1d528d4b17ae052ecd41e/addons/account/models/account_move.py#L816
The line is part of `existing_terms_lines` instead of `others_lines`.
opw-2089955
closesodoo/odoo#39309
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Do not use `tickets` which is a recordset with more than one record.
opw-2092231
closesodoo/odoo#39312
X-original-commit: 3e2d968c55542426746b287c556b5fb05d59fdcb
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Commit c95acd624e added support of sending tickets to client directly
by email. However parameters management in the business method allows to send
void emails or to spam people quite easily. Moreover missing translations
marks prevent from translating mail content.
This commit fixes that by ensuring current user is member of pos user group.
Code is also a bit cleaned to ensure mail values are correct. Finally
translations marks are added to allow content translation.
closesodoo/odoo#39275
X-original-commit: 884c98984d45d0875fe5b0d230a70408d8f75f6d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before update
When we creating opportunity from lead and select option 'linked with existing
customer', partner information is not filled up in followup section.
After commit
When we creating opportunity from lead and select option 'linked with existing
customer', partner information is correctly filled up in followup section.
This commits fixes that behavior by calling onchange_partner_id when converting
a lead to an opportunity.
Task ID 1974504
closesodoo/odoo#33073
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before commit
When we create an opportunity manually from the Kanban view and associate
a customer to the opportunity, the "Initial Contact Information" doesn't
appear in the "Followup" tab on the lead so we have to reassign a partner
second time on the opportunity.
After commit
When we create an opportunity manually from the Kanban view and associate
a customer to the opportunity, the "Initial Contact Information" will appear
in the "Followup" tab on lead.
This commit adds missing fields as invisible in the quick create view so
that the onchange updates them. As original author say, "to make onchange
works fabulously".
Task ID 1974504
- Teacher can now see the progress of his students on the attendees' list.
- The completion of a course was recomputed even if the course is completed
now it's fixed to 100 when completed.
- Added a progressbar in course page in front-end to allow the user to see
it's progression. When completed, the tag completed is displayed instead of
the progressbar.
- On slide page in front-end(normal view or fullscreen) when a course is
completed, display the tag completed instead of the progressbar.
- Removed completed state on course "Taking care of Trees" for portal user
because it was not the case.
task-2049689
closesodoo/odoo#36608
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit adds a new field "completed_slides_count" in slide.channel.partner
completed_slides_count has the same role as field completion before this commit
Now the field completion is a % of the completed slides
task-2049689
Before this commit, lists having a section or a note would have a horizontal
scrollbar in readonly mode.
Now it has been removed and the list stretches properly according to its parent
size.
Task 2086594
closesodoo/odoo#39301
X-original-commit: cbe26b3a3ac5ef3d79695cf44874e01087a35ef9
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, all the computation of the default widths for column
headers was done before the list was attached to the DOM, meaning that no
column was actually visible. This was a problem since columns that are
meant to stay unseen were taken into account in the calculation of relative
column widths.
Now, the same algorithm runs once the columns are visible so that invisible
columns can be properly excluded.
fixes#38744
Task 2076721
X-original-commit: 4bf98b47898b075049975dfe597f0fb92c7c14d1
Before this commit, the `width` attribute was interpreted by a jQuery node generator
function as a `style="width"` property and gave an incorrect width value to the affected node.
Now, the `width` attribute is automatically plucked in the list renderer in the
specific function used to render buttons.
Task 2076721
X-original-commit: c67b36c00ca263f51e0dd49d6e38702c4d614289
Some external ids of account.fiscal.position.tax.template were
duplicated
closesodoo/odoo#39287
X-original-commit: 707084af713d90ab71f7eab389bed493ae86c68a
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The queries made by the method `_is_an_ordinary_table` represent about
8% of the time to do a full Odoo installation. Use a cached query for
all tables on the registry to reduce that time to some negligible
amount.
closesodoo/odoo#39262
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
`_` is not available when loading this part of the template, leading to
an error on `_.str.trim()`.
We can simply use `trim()` to do so. By the way, `google_analytics_key`
is now trimmed automatically when adding it in the settings, so this is
only useful for migrated databases.
Fixes#38891
opw-2089296
closesodoo/odoo#39269
X-original-commit: a492047e9a064beecbe0611c3f7aef5172406eb1
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Purpose of this commit is to remove code coming from old features,
implementations and that was not completely cleaned.
Including
* remove support of old "reply" composition mode which is simply a comment
with a parent message, and is deprecated;
* remove support of old "mail.compose.message.mode" context key that was
used in Odoo 6.1;
* remove support of message_id default value in context instead of
default_parent_id;
* remove old redirection of user / partner post. This code come from
old age when people were able to post on their "profile" by posting
on their user;
* remove unnecessary method for selection field;
* remove unused imports to clean a bit code;
We also make some optional parameters in rendering methods mandatory to
ease code understanding and future modifications.
Task ID 1853147
PR #39272
Purpose is to prepare future cleanups and speed improvements. In this commit
we use create multi on mail.mail, allowing to batch their creation when
necessary.
Task ID 1853147
PR #39272
When a BoM is using a component with a quantity required set to 0,
tracebacks were occuring when computing the available quantities
for the kit.
Fixes#38807closesodoo/odoo#39267
X-original-commit: 7676269ba56c8e293ef4cd3dffbe7eccbad4a9d0
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Before this commit, when clicking inside a snippet which is already
enabled, it was disabled then re-enabled... which had the side effect
of calling onBlur/onFocus methods. This can be a problem with some
onFocus/onBlur implementation relying on the old behavior.
Note: this commit restores the exact same behavior as before. If an
internal snippet of the active one is clicked, then we still call the
onBlur then onFocus for the old active one (the parent) as the actual
enabled snippet changed (even if it is simply a child snippet).
closesodoo/odoo#39261
X-original-commit: 076992bdf099f3a645c9a1ef6df2cdcccbf1c2b2
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
