This commit moves the finished quiz modal into a dedicated dialog widget.
It will lessen the "slide_course_quiz.js" code length and simplify the dialog template.
Task ID : 2126621
PR : #40801
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
An override of toggle_active was present to ensure that activities
would be removed before archiving records; this commit adapts this
mechanism to take custom active fields into account, since they are
now supported at ORM-level by getting the active field through the
`_active_name` model attribute instead of blindly using the `active`
hard-coded field that was used until now..
closesodoo/odoo#40109
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Uninstalling an imported module leaves behind an ir.module.module entry
which is entirely useless: it cannot be reinstalled without re-uploading
the module.
A quick solution is provided here by simply cleaning up after the
uninstallation and deleting the ir.module.module records of imported
modules that just got removed.
Another possibility could be to store the uploaded module for good in
an attachment and re-load it from there upon re-installation, but that
would lead to some conflict with Studio, as uninstalling the
studio_customization module usually means you want to get rid of it for
good.
While x_name has long been automatically supported as an equivalent
of name, x_active was not.
This commit adds this behaviour OoB, both in the ORM and the web client.
On the ORM-side, a new `_active_name` attribute is supported on models.
This attribute specifies the field that should behave as an active marker
for records of the model. It is supported the same way `active` has been
until now (filtering by the `active_test` context key and toggled by the
`action_archive`, `action_unarchive` and `toggle_active` methods).
Although no check has been added on the field's type, it is assumed to
be a boolean field (the same way no check is present on the `(x_)name`
field).
On the client-side, the list view and form view now both support
detecting the presence of either `active` or `x_active` on records,
automatically adding an '(Un)Archive' button in the Action menu if such
a field is detected.
Note that the ORM implementation does actually need the field to be named
in any specific way, but since the web client has no mechanism to load
information regarding a model (the lifecycle of an action loading
includes loading the action, view and record(s) but no generic
information about the model itself besides what is included in the
views), we restrict the field's name to `(x_)active` to avoid confusion
as any other name would work at the ORM-level but not in the client.
In the future, the client might be able to more elegantly get
information about models, but this was not the scope of this change and
this solution should cover most cases.
Note that the `active` field will always takes precedence over the
`x_active` field to avoid confusing the polarity, even if both fields
are present on the model.
In the case of a custom field, it might be slightly annoying that the
default value of a Boolean field is `False`, which means that upon
adding the column, all existing records are automatically archived. This
can easily be worked around using an `ir.default` record for that
particular field and an update of existing records (e.g. through the
list view). The goal of this change was not to make it easy to add
support for custom active fields, but to make it possible - we have
therefore kept this implementation which introduces few changes while
adding enough flexibility for developers.
See https://twitter.com/zubair_shafiq/status/1202587553871880192?s=20
for more info regarding supporting any `_active_name` in the web client.
Co-authored-by: Raphael Collet <rco@odoo.com>
Channels uses tags allowing to categorize and filter content. For that
purpose a m2m exists between channels (slide.channel) and tags (slide.channel
.tag). The 2many relationship from tags to channels holds however a wrong
comodel name. It has no impact on code since relationship table is
correctly defined and current code does not use the channel_ids fields
from tags.
closesodoo/odoo#42244
X-original-commit: 46c3ac94485292c59fdfe4b21a8e32eef9d1f998
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Activate a Fiscal position with a defined tax mapping(i.e. 15%). Add to a
product the same tax. Set the tax to be included in price.
In POS Settings add the default fiscal position as the one from before.
Now open POS and add the product.
The total price calculated will be wrong: the tax is added twice, one
from the product line and one from the localization.
Mimic the behavior as in
https://github.com/odoo/odoo/blob/saas-12.3/addons/account/models/account.py#L1512closesodoo/odoo#42194
X-original-commit: db16d119f02ed5244482276a3701d3d3ab2fdb7b
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Revision on [1].
Commit above made changes to test helper `nextTick()`, so that it
waits for `window.nextAnimationFrame()` (shorten, 'rAF'). This was
useful to wait for OWL rendering, since OWL renders on next animation
frame.
From a theoretical standpoint, the helper should wait at least as
much time as before, as it adds either no slowdown (rAF is readily
available), or a few milliseconds wait (rAF waits for next available
animation frame).
However, some old tests show non-deterministic behaviours, resulting
to crashes [2]. It suggested, for some reasons, that `nextTick()` did
not wait long enough for re-render... Which is surprising considering
explanation above!
Some of these tests have been fixed, assuming it was caused by un-
guaranteed order of successive `setTimeout(0)` [3]. Unfortunately,
this does not explain why it never crashed before the change on
`nextTick()`...
After investigation, we think that this behaviour comes from rAFs
having their own task queue, which no longer guarantees that queued
tasks happen after queued micro-tasks:
When the requested next animation frame is readily available, the
callback of `requestAnimationFrame()` is immediately called and waits
for `setTimeout(0)`. The `setTimeout(0)` await is resolved before any
other queued async micro-tasks, so that `nextTick()` is resolved
sooner than expected. This would explain how `nextTick()` does not
wait long enough for rendering from the loads of resolved Promises,
even though there is a promise resolution after `setTimeout(0)`.
This commit fixes the issue by moving the await `setTimeout(0)`
before the rAF call, so that it correctly waits render from chain of
resolved promises (since the `setTimeout(0)` is awaited in the same
main task queue).
[1] https://github.com/odoo/odoo/commit/b0941d19a07b08fabc64a284b58e57edc46203dd
[2] http://runbot.odoo.com/runbot/build/771505 and http://runbot.odoo.com/runbot/build/752855
[3] https://github.com/odoo/odoo/commit/6cbfdbce2d0f1b567b6a6d6f637fe2a476980accclosesodoo/odoo#42123
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
When a manufacturing order was created through a stock rule, the `delay_alert`
feature was broken. Indeed, we should store on the order the `delay_alert` value
similar to what we do with the `propagate_date`, `propagate_date_minimum_delta`
and `propagate_cancel` fields.
We thus add the missing field and add the values in the multiple prepare methods.
We also the missing values for `propagate_date_minimum_delta` and `propagate_date`
in `_get_move_raw_values`.
task-2154781
closesodoo/odoo#42032
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
`propagate_date` enables the automatic rescheduling which could lead to hard to
understand behavior if a manufacturing order is planned, i.e. if the work orders do
have their leaves booked in the workcenter calendar. We thus disable the
automatic rescheduling in this scenario.
task-2154781
date help: "Move date: scheduled date until move is done, then date of actual move processing")
As this behaviour is also wanted when the onchange mechanism do not work
(ie in a manufacturing order move raw and finished), we move it to write.
task-2154781
Before this patch, writing on the `date_expected` field on the raw moves did not
update the `date_planned_start` (but writing on `date_planned_start` did write on
the raw AND finished moves `date_expected`).
This proved to be wrong: having the same `date_expected` on both raw and finished
moves did not make sense (the manufacturing order is not instantaneous). It also
makes difficult to make the rescheduling work: the rescheduling is done on the stock
moves and thus updates `date_expected` on the raw moves. If this information is not
transmitted to the manufacturing order, we won't be able to continue the rescheduling
on the finished moves (the idea is to update the raw moves which will update the
date_planned_start which will update the date_planned_finished which will update the
finished moves)
To have a more sane system, the `date_planned_start` and `date_planned_finished` are
computed (with an inverse) on the raw and finished moves `date_expected` (similar to
what's done on the picking model). There's a tweak though: as `run_manufacture`
creates first the order with a `date_planned_finished` and then confirm it (which will only
create the finished move at this moment), there's no place to write `date_planned_finished`.
The compute thus defaults on `date_deadline` which is stored and the finished moves
will be created later on with this value.
We implement the same logic `_onchange_date_planned_start` in `write` so that it doesn't
only rely on the onchange mechanism and the rescheduling can work when changing the
`date_expected` on a child mo for example.
task-1970595
- Before this commit file name is Timer.js which create issue in macOS
due to non case-sensitive harddisk partition. So file renamed to timer_mixin.js
closes#42232
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Remove the create_edit option when creating a new lost reason to avoid
displaying an unnecessary wizard.
task-2155189
closesodoo/odoo#42120
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When exporting fields, the reward attempts fields were split from each other. By grouping them, it allows
easier management from user as all rewards fields are now grouped in the export wizard.
Additionaly, they are also grouped in the dropdown for custom filter.
task-2155189
closesodoo/odoo#42103
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Since the name updates are done in onchanges, the relational values
may be newIds and therefore we have to use their _origin for comparisons.
closesodoo/odoo#42217
X-original-commit: 9c303bfd4f8eeb1c6892349c59f70347a11ff71f
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The `color` attribute allows specifying a field by which the calendar
view will color the event entries in the view.
In views where this attribute is not defined, the event was instead
given the `text-white` class, which rendered the event invisible in the
calendar, save for a slight left-border.
This commit just use the 1st color class by default in such cases,
ensuring all events are visible.
opw-2145652
closesodoo/odoo#42200
X-original-commit: 375b34be6ef198753f52a650159edee4d1883006
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Ensure that expression.OR and expression.AND and some other
expression.py methods do not propagate or rely on TRUE_DOMAIN and
FALSE_DOMAIN that may be muted on some instance.
For example, if we did:
self.search(expression.OR([]))
then in the search method we do something like:
received_domain.append(('res_field', '=', False))
before this commit, FALSE_DOMAIN would be altered for any succeeding code
that try to use it in `[(0, '=', 1), ('res_field', '=', 'False')]`.
Without the changeset, the added test would fail with:
[(1, '=', 1), ('id', '=', 1)] != [(1, '=', 1)]
[(0, '=', 1), ('id', '=', 1)] != [(0, '=', 1)]
[(0, '=', 1), ('id', '=', 1)] != [(0, '=', 1)]
[(1, '=', 1), ('id', '=', 1)] != [(1, '=', 1)]
[(1, '=', 1), ('id', '=', 1)] != [(1, '=', 1)]
note: another commit referenced in #41968 should make the TRUE_DOMAIN
and FALSE_DOMAIN immutable.
related to work on opw-2154448
closes#42107closesodoo/odoo#42222
X-original-commit: 303ce32e6ccd7432b96ffae545e4a6eced68ae84
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
* website, website_mass_mailing
Instead of a custom string, use the name of the snippet when displaying
an 'invisible' snippet in the 'invisible elements' section.
This commit also fixes a font-awesome bug introduced with the library
update revert.
Part of https://github.com/odoo/odoo/pull/41789closesodoo/odoo#41789
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
* website, website_mass_mailing
Instead of triggering an event on the invisible element when its related
button in the left panel is clicked, the invisible element's options are
now toggled (shown if were hidden and hidden if were shown). To do that
the new 'onTargetShow' and 'onTargetHide' methods are called, and the
appropriate action can be done there.
Those two new methods are also automatically called in other cases:
- When dropped in the page, after onBuild, 'onTargetShow' is called
for any snippet.
- Before cleanForSave: 'onTargetHide' is called for snippets with the
'o_snippet_invisible' and 'onTargetShow' is called for the others.
In case the element visibility should be toggled another way (like the
close button of a modal), the option can trigger_up an event named
'snippet_option_visibility_update' with a 'show' parameter so that the
the UI is updated accordingly (and so that the options are hidden if
necessary).
Part of https://github.com/odoo/odoo/pull/41789
Snippet enabling operations and snippet edition operations were mutexed
individually. In fact it simplifies the code and it is probably better
to chain all snippet operations, through an unique mutex.
Part of https://github.com/odoo/odoo/pull/41789
Before this commit, users encountered some difficulties to tap/click
on the "optional columns" dropdown in list views.
This issue only occured on Chrome: rather annoying to use the mobile app.
"width: 10px" was used in inline list view but didn't have any sense
in the other case. Worse still, Chrome miscalculated the size of the
clickable area by a smaller one.
This is due to the fact that we add some padding that exceed 10px.
See:
https://github.com/odoo/enterprise/commit/2f1320557ec67a741201d73a23a9782ec8f9b3bb#
opw-2071605
closesodoo/odoo#42210
X-original-commit: 28b6e9c99c77230dc19808718cd6f6f8aec0db5d
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Before this -
If we have follwing configuration -
Manufacturing -> Propagate Cancel -> True
Buy -> Propagate Cancel -> True
* BOM of a Car -
1) Component 1 -> Iron (MTO & Buy)
Now create a SO of product Car and confirm it.
It will create a MO (Car) and then PO (Iron).
Now if PO is cancelled, it will cancel its
move_dest_ids and on change of it MO will be
cancelled but delivery move will remain ongoing.
When action cancel is called on a move raw, it will
check if the production order is also cancelled.
If the MO is cancel, in this case cancel also its
move finished.
Task-2117832
closesodoo/odoo#42209
X-original-commit: 9522e51a3b290c91f23658a4fb781003ff1fd8d2
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Access rights
=============
Purpose
-------
Currently, the lowest access right level for Timesheets allows a user
to see the timesheets from all employees. Some companies do not want
to have this information shared.
As we already have three levels of access rights, creating a new one
would be too much. Instead, we are using this opportunity to
clean/simplify the current access right levels.
Specification
-------------
Remove the current access rights and replace them with the following:
- 'See own timesheets' the user can:
- read/write/create/delete his own timesheets only
- cannot timesheet on projects whose Visibility is set on
'Invited employees' if the user is not a follower
- see the 'My Timesheets' and the 'Timesheet App' menus
- 'See all timesheets' the user can:
- read/write/create/delete all timesheets
- cannot see the Timesheets of Projects whose Visibility is set
on 'Invited employees' if the user is not a follower
- see the 'My Timesheets' + 'All Timesheets' + 'Timesheet App' +
'To Validate' menus
- validate the timesheets of whom he is the 'Timesheet
Responsible' or the 'Manager'
- 'Administrator' the user can:
- read/write/create/delete all timesheets
- see all menus
- validate the Timesheets of all employees
- Write tests
New Validation Process
======================
Purpose
-------
Currently, timesheets are validated by employees as a whole. However,
as a manager, it is difficult to evaluate the timesheets of an
employee for projects you know nothing about. Therefore, it would make
more sense for a manager to validate the timesheets of his projects
and to leave the rest to the other managers.
In addition, having a date on the employees leaves room for error and
performance issues, so we are introducing a new checkbox at the
timesheet level.
Specification
-------------
Remove the 'Timesheets Validation Date' field on the employee
- replace it with a 'Timesheet Validated' checkbox (hidden field) on
the timesheet entry
- By default, this field is set to false
- Once the manager validates the timesheets, switch the field to
true
- Filtering on 'Validated' timesheets should display timesheets for
which 'Timesheet Validated' is true
- Filtering on 'Non-Validated' timesheets should display timesheets
for which 'Timesheet Validated' is false
Rename the title of the validation menus into:
- To Validate > Last Weeks -> Timesheets from Last Week to Validate
- To Validate > Last Month -> Timesheets from Last Month to Validate
Grid view: display projects on which the user timesheeted in the
past 30 days (group_expand), or the employees who timesheeted in the
past 30 days for the 'To Validate' menus)
Open the 'To Validate' menus on the oldest non-validated timesheet
you can find.
Clicking on 'Validate' should validate all the timesheets displayed
on the screen. List all the elements displayed in the view based on
the group by applied in the 'Validate the timesheets' modal.
When validating timesheets, bypass timesheets that were already
validated in the past in order to avoid performance issues
Timer list
==========
Purpose
-------
Have an overview of the timesheets you need to do during the day.
Easily track time spent on tasks using the timer instead of having to
write down somewhere at what time you started an activity. Allow more
flexibility if an activity if interrupted by another one (so you
don't need to do mental arithmetic to determine how much time the
first activity took substracted by the time spent on the second
activity).
Specification
-------------
- Move the time from fsm to hr_timesheet.
- Add fa-play-circle and fa-stop-circle icons in the 'My Timesheets'
menu:
- on the left of the 'Duration' field in the list view
- on the top right corner of the kanban card in the kanban view
- on the right of the first column in the grid view
- Display these icons
- for non-validated timesheets only
- if the Encoding Unit is Hours
- Clicking on the play button should start and display the timer and
switch to the stop icon
- Clicking on the stop button should halt and stop displaying the
timer and switch to the play icon
- While the timer is running, the 'Duration' field should not
be editable
- Only one timer can run at the same time. If the user clicks on the
start button of timesheet B while the timer is running for
timesheet A, timesheet B should start and timesheet A should stop.
Time selection when invoicing
=============================
Purpose
-------
Allow selecting a timeframe to invoice when the user is invoicing on
a periodical basis. For instance, the user invoices each time at the
end of the month. For some reason (he got sick, there was a bank
holiday...), he only invoices of the 4th of the following month.
Now the timesheets that are about to be invoiced include some that
were recorded in the meantime.
Specification
-------------
- Add an 'Invoice timesheets up to mm/dd/yyyy' field on the Invoice
Creation modal
- display this field only when creating an Invoice for a Service
whose Invoicing Policy is on 'Timesheets on tasks'
- not required
- Set today's date by default
- if this field is set, the quantity to invoice should only
include the not yet invoiced (and validated) timesheets up to
this date (included)
- if this field is not set, include all not yet invoiced (and
validated) timesheets without distinction.
- Add the following tooltip: Only timesheets not yet invoiced
(and validated, if applicable) up to this date included will be
invoiced. If no date is indicated, all timesheets not yet
invoiced (and validated, if applicable) will be invoiced
without distinction.
Miscellaneous
=============
Purpose
-------
Small usability improvements.
- Move 'Create SO from Task' to sale_timesheet -> Means Enterprise to
Community).
- Add the pivot view to the 'All Timesheets' menu
- Add the 'Today' button on the grid view of all menus (see the
Reporting > Timesheets by Project menu for reference)
closesodoo/odoo#40495
Taskid: 2088586
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Co-authored-by: Lucas Lefèvre <lul@odoo.com>
Co-authored-by: Yannick Tivisse <yti@odoo.com>
Following the removing of the vendor and customer field, when we wanted to display customer in the back end, we saw all. We added a default filter when clicking on the menu button that displays only customer with a customer rank higher than 0.
We also increase their customer ranks everytime they make an order in the front end.
closesodoo/odoo#41769
Task-id: 2092483
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
TaskID: 2088586
When the user has the access right : 'See my timesheets'. He can only
see his timesheets. Thus, in sale order, we want to display the real
total number of hours spent on the 'Hours Recorded' stat button.
When the encoding is in Days and not Hours, the total number on this
stat button is not correct. This commit correct the total number.
TaskID: 2088586
In 'My Timesheet' menu, in grid view when there is no record, the view
displays an empty list tooltip. With this commit, the 'All Timesheets'
menu, the empty list tooltip is also used when no record is displayed.
TaskID: 2088586
When we launch the timer, if the clock of the client isn't correctly synchronize
with internet, we can't correctly display the timer,
because the clock of the server can be in advance.
The solution is to call the server to have this time and use the timer
only with the time of the server.
TaskID: 2088586
The timer use in project > task can be usable in community and not only in enterprise.
move timer constraint from sale_timesheet_enterprise to hr_timesheet
TaskID: 2088586
Some changement in project overview to match with the access rights
in Timesheet.
When the user has the lowest access right, the user may not see the
timesheets of other users in the project overview. The total of hours
spent must be equal to the number of recorded hours. But the
remaining hour of the sale order must be corresponded to the reality
and not only depending of the record that the user may see.
Move the _domain_employee_id method from timesheet_grid into this
module. Because this method is used for project overview into
sale_timesheet module.
TaskID: 2088586
Add an 'Invoice timesheets up to mm/dd/yyyy' field on the Invoice
Creation modal. This field is only visible when we want to create an
invoice for a Service whose Service Policy is set on 'Timesheets on
tasks'.
This field allows to invoice the timesheets of a service up to the date
set on this field.
Before this commit, when we create the account.moves.line records, we
link timesheets of a service to an invoice. Now, we need to check which
timesheets are invoiced, because with the adding of the date for the
creation of invoices, we cannot invoice the timesheets after to this
date. Then, the process is done at the end of '_create_invoices' in
'sale.order' model when the invoices are created.
Override an ir.rule in accout module, because this rule accept all
account.analytic.line in its domain and we don't want to accept all
timesheets when the user has the access right : "See own timesheets".
Therefore, we need to override this rule to apply the others rules in
this model for the timesheets.
TaskID: 2088586
Beside this override, the records in timesheets often change order
because the date field is a date type and then, many timesheets can
have the same date, thus the order isn't the same every time.
When we remove this override in account module, the default order is
restore for account.analytic.line model and it's 'date desc, id desc',
with this order, we keep the same order every time in the different
views of timesheet.
TaskID: 2088586
Timer in the list and kanban views :
----------------------------------
In kanban and list views, It's possible to update the 'unit_amount'
field with a timer. The user can easily launch the timer in these views
for one of his timesheets.
One timesheet can be launched at the same time, when the user start a
timer for a timesheet and start another timer for another timesheet, the
first timer stop and the new timer start.
The timer is usable only if the encoding unit is 'Hours' and the
timesheet is not validated. To do this : a new computed field 'display_timer'
is created in account.analytic.line, this field is set to True is the
encoding unit is 'Hours'. With this field, we can easily hide and display
the timer in different views.
The user can only use the timer for his timesheets. Because the user
with the access rights to see all timesheets might launch and/or stop a timer of a
timesheet of other user. That is the timer must be accessed only in 'My Timesheets' menu.
Add pivot view for 'All timesheets' menu.
Creation a timer_mixin :
----------------------
With this timer mixin, we can have a generic timer to use in other
models that they need to use a timer like account.analytic.line and
project.task models
The timer in account.analytic.line model has changed to use the timer
mixin.
Specific behaviour of the timer :
-------------------------------
When the user use the timer and the minutes spent with the timer is less
than 1 minute, we don't add in unit_amount of timesheet. If the
unit_amount is equals to 0 and minutes spent of timer is less than 0.
Then the timesheet created by the timer is deleted because it is useless to
have a timesheet with unit_amount set on 0.
Misc :
----
Add some styles for the timer button and for the 'unit_amount' field when the
timer is running.
remove duplicated fields in tree view (record
id='timesheet_view_tree_user')
TaskID: 2088586
The low level access right is now "See my timesheets".
This access disallow to a user to view and manage the timesheets of others users.
When the visibility of a project is set on "Invited employees",
the users with the access rules : 'See my timesheet' and
'See all timesheets' can show the timesheets, if these users
follow the project.
Issue
- Download the customer db: stargue-inc
- Go on the website in mobile mode
Traceback & the second item in the carousel is not displayed.
Cause
Traceback: we use `this.$iframe` without checking if it's defined
Second item not displayed: the first video promise is overriden
by the second video promise.
Solution
Check if this.$iframe is defined and resolve the old promise
instead of overriding it.
OPW-2152690
closesodoo/odoo#42139
X-original-commit: f5f569b4705f37865cb976a4df10a0d9f388fae2
Signed-off-by: Jason Van Malder <jvm-odoo@users.noreply.github.com>
- Create a move line from stock to shelf1 with PACK1
- Create a move line from stock to shelf2 with PACK1
- Validate
It should be be blocked. The contents of a package should all
be in the same location since the pack itself is in a location.
It's due to commit 78d6f46 that fix a rounding error.
However it should check for quants that have quantity since they
represents the package content.
closesodoo/odoo#42134
X-original-commit: 78fba949790f2b1ecd3ba1bf60fb34c30d17769e
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
* web_editor
Previously, increasing the number of columns on the tabs snippet would
cause the newly created tabs to toggle the original tabs instead of its
own, this was caused by an oversight where the columns were clone
directly using jQuery, and the snippets' the onClone method was not
called on the newly created columns (here, tabs). This commit move the
responsibility to clone onto the SnippetsMenu so that it can create the
appropriate snippetEditor if needed and call its onClone method.
task-2070643
closesodoo/odoo#42130
X-original-commit: 77ebadfe6ada8ad1fa4d6e476b9534f252499d92
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The attribute "groups" on filters and fields in a search view arch was not taken
into account anymore.
Now items that should be invisible are not anymore available for selection
in the interface (as expected) but are still activable as search defaults
(and the corresponding facets appear if needed).
Task ID: 2081450
closesodoo/odoo#42125
X-original-commit: ca2514a9fbcd693752367cb566d5c11165b40bd4
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Validating a move line will remove the reservation on other move line
that will take quantity on the same quant.
The querry searching for those move lines needs the state of their
relative stock move to be neither 'done' nor 'cancel'. This constraint
add a join in the SQL querry that slow largely the request
This commit removes the `move` state in the querry and replace it by the
the move line state to speed it up.
Thanks to
https://github.com/odoo/odoo/commit/39b65efbad36a0b63de5d148bc575eaf15b60653
and
https://github.com/odoo/odoo/commit/23e77b80336514d07504c35d717d4573bed90071,
it's will give the same result as the
move line state is related stored of its relative move.
opw 2126433
closesodoo/odoo#42170
X-original-commit: dbc664e5d5f28d6fdd8f791ee349a842fd7d22d0
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Accountant who change the lock date is not always a pos user, and then
cannot read pos sessions.
closesodoo/odoo#42156
X-original-commit: 8c6aa24525eca434b6f85b56c10c45b33cc05a43
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Patrick Hoste