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
This commit refactors the method '_bom_find' in order to search bom based on their type.
This allows to handle the cases where a Kit has the route 'Manufacture' set.
TaskID: 1863856
With this commit, the routes of the components of a kit are applied instead of the routes on the kit itself.
To do this, a refactor of '_adjust_procure_method' was made in order to use it on stock.moves
The method '_adjust_procure_method' was moved to the stock module in order to be used in a future task concerning repair orders ( TaskID: 1887961).
TaskID: 1863856
Avoids querying and updating an ir.config_parameter which (according to
rco) blows the caches (of all workers) every time it happens, which is
inconvenient.
closesodoo/odoo#29066
While many crons will process some sort of queue and can either delete
or mark items as processed, others are more concerned with time ranges
and may not want (or be able to) write on the objects to mark them as
processed. In that case, crons maintaining a processed date range is
useful.
Task 1912648
In the BoM structure and cost report the purpose of _get_bom_reference
was to add content with an override in order to display it directly in
the column BoM. It could be improved by using the classic display name
and add a name to column in order to use an xpath in another module.
The function _get_bom and _get_bom_line can also be used in order to
introduce extra content directly in the column added with an xpath.
Task ID : 1875677
closesodoo/odoo#26493
Task #1909424
The mass_mailing module used a lot of JS "include" to override
the behavior of the kanban view and the html_frame widget.
This commit cleans the overrides by using proper inheritance with "extend"
instead of "include".
It also slightly changes the current behavior of the mass_mailing kanban view
to disable the drag and drop feature only when the view is grouped by "state" or "email_from".
(Before this commit, the drag and drop feature was disabled for ALL fields).
closesodoo/odoo#29452
In the KanbanRenderer, the _setState method extracts the groupBy field name and tries
to get the field information from that string.
When the field is a date/datetime grouped by day/week/month/..., the field name becomes "my_date:month".
This prevents the gathering of state information since those information are stored in a dictionary with a 'my_date' key.
This commit will detect if the field has additional grouping info (:month, :week, ...) and clean the name
with a substring before accessing the state dictionary.
The KanbanRecord config was not correctly taken into account when
initializing the columnOptions (for the KanbanColumn).
This completely prevented overriding the KanbanRecord in the kanban view if the KanbanColumn
was used for rendering (= when the view was grouped by a field).
Ics file generation should be possible even when only event is
installed as it is a basic feature of events.
Moreover we need to be able to generate such files in order to replace
the old outlook api used in the event templates, api which is not
supported anymore.
We decided to use ics files because it is supported by most calendar
schedulers hence working with outlook.
Linked to task #1853063closesodoo/odoo#28477
Feedback should be the first part of the message without title
to make it more concise.
If the activity has a note, the note should be displayed
but after the feedback.
We can also remove the field feedback that was not so useful
since it was only written just before unlink. Feedback is now
passed as another parameter to the template.
Task: 1918392
closesodoo/odoo#29605
Romain Derie