**Before this PR:**
- The quantities available when a kit was ordered was 0 even if enough components were available
- The quantities delivered when a kit was ordered were correct only if all move from the picking of its sale order were done. So the quantities delivered were correct only if all components were fully delivered.
**After this PR:**
- The number of kits available is computed based on the quantities available of the components needed to make the kit.
- The number of kits delivered is computed based on how many kits it's possible to make with the components already processed.
- Some test case are added the check the flows when kits are ordered.
Those test case make sure that:
* Delivered quantities are accurate if :
- kits in kit
- backorders are made
- returns are made
- returns of returns are made
- Multiple differents UoMs are setted on the components of a kit
* Available quantities are accurate if:
- Kits in kit
- Multiple differents UoMs are setted on the components of a kit
TaskID : 1915370
closesodoo/odoo#29270
Thoses tests checks the correctness of the kit's flows.
The following cases are tested :
Delivered quantities are accurate if :
- kits in kit
- backorders are made
- returns are made
- returns of returns are made
- Multiple differents UoMs are setted on the components of a kit
Available quantities are accurate if
- Kits in kit
- Multiple differents UoMs are setted on the components of a kit
TaskID: 1863856
With this commit, the warning message triggered when there are not enough quantity available of a kit is based on the minimal quantity of a kit it's possible to make, based on the quantities available of its components.
However, as this quantity is based on the 'virtual_available' quantity, the values could be negative, wich doesn't really make sense for a kit.
This is why in such a case, the quantity available reported by the warning will be set to 0.
TaskID: 1915370
Before this commit, the quantity_delivered of a kit was set to 0 unless all its components were delivered.
With this commit, the quantity_delivered is the minimal quantity it's possible to make with the components currently delivered.
TaskID: 1863856
The option `showSearchInput`, which is used on the model field selector to display a search
input that filters the displayed fields, is not set by default.
This includes the model field selector instantiated in the `domain` field widget.
closesodoo/odoo#29986
With this commit, the buttons 'Check availability', 'Unreserve' and the column 'Initial Demand' are hidden if
the picking is an immediate transfer.
TaskID: 1868544
closesodoo/odoo#29108
Purpose of Task is to relabeling of various settings and button to be consistent with other view.
-- change menu 'Lead Generation' to 'Visits to Leads' for crm.reveal.rule
-- change help tooltip 'Create a conversion rule.' & 'Create rules to generate B2B leads/opportunities from your website visitors.'
This commit is related to task ID : 1919736
closesodoo/odoo#29701
On small screens, when we click on the overview of a task
inside the "project" app, the displayed table doesn't fit the screen.
This commit only add missing parent "div.table-responsive" to add
responsive support.
opw-1907877
closesodoo/odoo#29970
Modal primary button should be the one in the corner (left if buttons aligned
left, right if buttons aligned right) as in the Bootstrap doc.
More than a simple guideline, the user will intuitively click on the button in
the corner as it is supposed to be the primary one.
Plus some DOM fixes (o_technical_modal was missing, H2 was too big especially
since BS4)
Closes#29890
task-1922120
In some cases, the web client may receive a search view with invisible
filters. This is due to the way field_view_get works. For
example, if there is a group on a filter, then this will be transformed
into an invisible attribute.
In that case, the search view should simply ignore the filter and not
display it. This was broken in the recent control panel refactoring
(note that the search view lacked the possibility of testing that kind
of situation).
closesodoo/odoo#29430
cherry-pick of 13aae100e2closesodoo/odoo#29965
Commit https://github.com/odoo/odoo/commit/52ec536cef2ec84af0b36746f19a8cdf9f23fe2a
made a mistake which made the backend use the website colors. This is
because the web_editor app adds its bootstrap_overridden.scss file in
both backend and frontend assets as the backend needs the editor colors
(alpha, beta, ...). However, the 'primary', 'secondary', etc that the
backend customizes should not be overridden by the web_editor. Therefore
the file contained a hack to determine if it is the backend or not...
hack which did not work anymore with the new system the mentioned
commit implements.
Also some comments were not adapted correctly by the mentioned commit.
closesodoo/odoo#29935
Track_visibility field parameter allows to track field changes in mail. Since
commit c99de45 only updated values are tracked. Previously to that commit it
was possible to have field values being tracked whenever any other change
occurred. This feature has been removed to simplify tracking and avoid having
unnecessary values in the tracking table. In this commit we rename the
track_visibility parameter to tracking. Old parameter value is still supported
in mail for backward compatibility.
Commit ec35eca added sequence on tracking so that display of tracking values
is coherent through various chatter messages. To ease tracking configuration
it is merged with the tracking (old track_visibility) parameter. It means
tracking parameter can either be True (default sequence of 100) or an integer
giving the sequence to apply on the tracking.
Purpose of those changes is to simplify tracking configuration with studio
in mind. That way changing one parameter allow to customize the tracking of
fields in chatter.
Sequence field on mail.tracking.value model is renamed to tracking_sequence to
have a coherent namespace for tracking information. Tracking information on
ir.model.fields is also updated accordingly. To simplify manipulation boolean
value for tracking is automatically transformed into a sequence of 100.
All addons are updated accordingly.
This merge is linked to task ID 1903814 and PR #28430.
Purpose is to clean the use of tracking parameters on fields. Parameters are
merged and is now tracking=<int> or tracking=True.
This commit is linked to task ID 1903814 and PR #28430.
Track_visibility field parameter allows to track field changes in mail. Since
commit https://github.com/odoo/odoo/commit/c99de4551583e801ecc6669ac456c4f7e2eef1da only updated values are tracked. Previously to that commit it
was possible to have field values being tracked whenever any other change
occurred. This feature has been removed to simplify tracking and avoid having
unnecessary values in the tracking table. In this commit we rename the
track_visibility parameter to tracking. Old parameter value is still supported
in mail for backward compatibility.
Commit https://github.com/odoo/odoo/commit/ec35eca7c6b772139c8fa143b388ad1d936bc9ea added sequence on tracking so that display of tracking values
is coherent through various chatter messages. To ease tracking configuration
it is merged with the tracking (old track_visibility) parameter. It means
tracking parameter can either be True (default sequence of 100) or an integer
giving the sequence to apply on the tracking.
Purpose of those changes is to simplify tracking configuration with studio
in mind. That way changing one parameter allow to customize the tracking of
fields in chatter.
Sequence field on mail.tracking.value model is renamed to tracking_sequence to
have a coherent namespace for tracking information. Tracking information on
ir.model.fields is also updated accordingly. To simplify manipulation boolean
value for tracking is automatically transformed into a sequence of 100.
This commit is linked to task ID 1903814 and PR #28430.
The fields remaining_leaves and leaves_count have the same computation
(two different methods but they compute the same quantity)
We still need to have two different fields, because they need to both be
in the view at the same time, but we can use the same computation for
both of them.
closesodoo/odoo#29879
Purpose
=======
We can't have only one report template for all the payslips. Some things
are specific to belgium, or another country. (For example, display the
amount on meal vouchers on the payslip). We should add an multi action,
and a button on the payslip form to print it.
Add a report field on a salary structure. This report is used on printing.
That way we can specify another report for a given salary structure and
print all the document of a employee with the correct report on each
payslip.
closesodoo/odoo#29674
We want to add new kinds of failures to the list in the systray, such as Snailmail or SMS failures.
Until now, failures linked to documents of the same model were grouped together in the systray.
Different types of failures should not be grouped in a single line so we add a '_failureType' variable to mailFailures and group them only if their type is the same.
closesodoo/odoo#29855
Add <sheet> tag on the form view for the following models:
- res.bank
- res.country
- res.country.group
- res.country.state
- res.partner.title
- res.partner.category
- res.partner.industry
[IMP] base: add sheet to countries form and add group names for clean xpaths
[IMP] base: add sheet to contact tags form
[IMP] base: add sheet to parter title form
[IMP] base: add sheet in sectors of activity form
[IMP] base: add sheet to federal states form
[IMP] base: add sheet to country group form
[IMP] base: add sheet to bank view and add group names for cleaner xpaths
closesodoo/odoo#27324
When creating refund order, Odoo copies the original order and put
some default copy data. All these things were put in the same method
which causes problems for extensions.
This commit split the refund method into multiple dedicated methods so
that others can modify/inject more data easily
closesodoo/odoo#29792
Purpose
=======
HR users wants to know if an applicant applied to multiple jobs
or if he applied in the past.
Specification
=============
Keep an history of applications based on email.
Add a stat button on the applicant form to display
other applications with the same email.
closesodoo/odoo#29613
Purpose
=======
We could want to retrieve the session user id when rendering the next
activities on the chatter (For example in the new approvals module on the
enterprise repository).
At the same time, we used 'web.session' to retrieve this valued instead
of 'self.getSession().uid' which is deprecated.
* portal, theme_bootswatch, web, web_editor, website
With less2sass and bs3tobs4 tasks, the assets structure was reviewed to
handle the specificities of both framework and to prepare for our next
odoo tasks. In particular, the assets_helpers and bootstrap overrides
were basically split into 4 parts: utils, primary variables, secondary
variables and bootstrap variables.
(see https://github.com/odoo/odoo/commit/6e4db7d13a926845bf82f5b035afede42d6d5a89)
Using the !default system for the bootstrap variables parts seems now
a good improvement. This is part of what this commit does: adding the
default flag for all bootstrap variables overrides and inverting the
order of the files in the _assets_backend_helpers and
_assets_frontend_helpers templates. This allows to avoid code like this:
portal:
```
$body-bg: white;
```
website:
```
@if $var != null {
$body-bg: $var;
}
```
This code makes the body white with portal or equal to $var with website
if $var has a value. The same behavior in the new file order is achieved
with:
website:
```
$body-bg: $var !default;
```
portal:
```
$body-bg: white !default;
```
This order is now also followed for the _assets_secondary_variables
templates (there are only a few).
This commit also make better assets hierarchy by making website inherit
from portal assets (instead of web) and portal inherit from web_editor
assets (instead of web) (thus relying on strong dependencies instead of
installation order which is not always right for migrated databases).
closesodoo/odoo#29757
The method override `_handle_request_noblock`
is there to solve a bug in Python socketserver library
which has been solved in
- Python 3.6: python/cpython@8b1f52b5a9,
- Python 3.7: python/cpython@9080824513,
through PR python/cpython#9952.
These revisions will be included in Python releases 3.6.8 and 3.7.2,
and the override will then become useless.
We therefore can remove the `_handle_request_noblock` override
as soon as the Python 3 releases installed on operating systems
supported by Odoo are above
- 3.6.8 for Python 3.6
- 3.7.2 for Python 3.7
closesodoo/odoo#29706
Yenthe666