With the current test_main_flows dependencies, the tour does not pass in community.
Since rev. odoo/odoo@32db86e the `extra_trigger` waiting for `payment_method_id` is
never reached because the onchange who is supposed to display this field hides it
because there is only one payment method on the journal.
The second payment method is added by the module account_check_printing but we don't
want to add it in the dependencies because this module is not very common.
Note that this `extra_trigger` was meant to wait for the onchange triggered by the journal
modification on the 'Register Payment' modal but this modification is not useful as the
journal is already 'Bank (USD)' by default.
closesodoo/odoo#30023
Currently, res.partner has:
1. `website_id` field hardcoded in website module
2. `website_published` field from website `website.published.mixin` in
website_partner module.
At the end, the res.partner model has all the field of the mixin
`website.published.multi.mixin` without having the mixin.
As a result, we have all the multi-website fields but we don't have access to
the mixins methods & computes.
Now, we use the `website.published.multi.mixin` on res.partner in website
module even if `website_published` is not needed if website_partner is not
installed.
+ add tooltip to `website` field to prevent warning since 2 fields would have
the same label
closesodoo/odoo#29711
Before this commit, when changing the website field in a record form view,
the is_published field would be force to false, ending unpublishing the record
if it was published.
That behavior was coming from the fact that is_published field is missing from
the form view. Thus, onchange on website is triggering a recompute server side
without is_published as the JS framework is not sending the field.
The ORM is then fallbacking on default Boolean value (False) for is_published
when sending back the onchange result.
This would only appear on object with 'website.published.multi.mixin' and with
website_id in the form view.
Replacing website_published by is_published will fix the behavior and has more
sense has website_published is the 'is_published' state in a website context.
In the backend, we are not in a website context.
task-1919689
* portal, web_editor
Anchor Link:
- Some visual improvements of the link dialog.
- New 'Page Anchor' field.
- System by default: top and bottom.
- Shows existing anchors.
Creation of the anchor:
- New option 'Anchor Name' to be able to create an anchor.
task-1913458
closesodoo/odoo#29150
**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
qsm-odoo