When creating an invoice with 'Down payment' option for an SO, it should
first consider income account of the 'Deposit Product'. if it does not
have one then it should consider that product category's income account.
Fixes#23100
Task# 1819531
Remove the valuation stat button as we say that from now on, to
understand the current value of a product, you should go through the
valuation ation and its stat button.
We add the valuation at date wizard by re-using the quantity at date
wizard and adding a context key to separate the both.
The same view/action is used when openning the current or at date
valuation, only the `to_date` context key is changed.
For the standard and average cost method, we use `qty_available` at date
and the `product.price.history` table.
For FIFO, the normal way would have been to get the `qty_available` at
date and value this quantity with the more recent IN moves at this date.
But there's two main obstacles preventing to use this solution:
- when editing a done move to change the quantity, the change is
reflected at the date, the `qty_available` at date will be incremented
- in the same usecase, the remaining_qty and remaining_value is
incremented in place, which mean that even if the layer was already
consumed, it's now appearing again at the bottom of the fifo layer
Fixing this issue by adding a stock move at the date of today instead of
editing in place in v11 and adding a proper "cost layer" model in master
was deemed too complex as well as unnecessary by our bosses
So we now say we continue to update in place, and when looking at the
quantity at date
- if periodic, we sum the value of the move since the beginning of times
- if perpetual, we sum the balance of the account move lines since the
beginning of times. Also, in this case, the quantity at date is
computed across account move lines too, via the "quantity" field on
aml.
This commit adds three non stored computed field:
- qty_at_date: will be computed across stock moves if fifo periodic and
across account move line if fifo perpetual to reflect the design
choice: if periodic, we *really* edit in the past ; if perpetual, no,
the change is done at today's date
- stock_fifo_real_time_aml_ids: the used aml to compute qty_at_date
- stock_fifo_manual_move_ids: the used move to compute qty_at_date
stock value should be recomputed when the standard price change
it is not optimal since it is updated in fifo after a delivery but
needed when working with standard cost method
remaining_value should also be part of the depends since the current
value depends on it
Properly set the quantity field on the account move lines when
exceptions happen (unlock and edit: only the difference is set as
quantity, negative stock and vacuum: no quantity should be set).
When applying a landed cost, no quantty should be set neither.
This is a preliminary work to bring the valuation at date wizard to v11.
Update the value on the moves when exceptions happen (unlock and edit,
negative stock).
This is a preliminary work to bring the valuation at date wizard to v11.
We also update the value on moves in the standard cost method to stay
consistent.
- `_run_fifo` now returns the used value in the negative stock case
- we simplify the `_fifo_vacuum` method so that the `remaining_value`
always represent the not yet compensated value
- we adapt the tests to reflect theses changes ; the value is not the
initial valued amount but is updated upon exceptions
Replace `httprequest.stream.read()` by `httprequest.get_data()` so the
payload content remains available: get_data stores the request body (by
default) so it remains available for alternative processing or checks
(MAC checks for webhook validations for instance). With `stream.read()`,
once the data is read if it's not stored separately it is lost.
Have a task (A) with two subtasks (B and C)
Archive C
Before this commit, when using timesheets, the task A hours was misconputed and did not take C's timesheet into account
After this commit, hours are accounted for even if their task is archived
OPW 1829658
closes#23920
Issue: when displaying the shortcuts with ALT key, when a dialog is open
the shortcuts are displayed in absolute position above the gray overlay
of the dialog, so it is possible to click on the buttons of the
shortcuts.
This fix will remove this possibility.
Reproduce the issue:
- open the manual reconciliation (it is a client action)
- add a reconciliation (using the + sign)
- expand it (using the > sign)
- put the focus on the first field and hit TAB
--> you would expect that the focus moves to the second field
--> what happens is: the focus stays on the first field
Before this fix, when in a client action (or any place that contains
fields) that contains fields, the keyboard navigation did not occur
correctly because the default behavior of the TAB key was prevented.
After this fix, if the navigation_move event was not stopped, we allow
the default behavior of the TAB key.
If a user set a procurement to the day N, the procurement datetime field would
be set to day N at midnight. So any negative timezone make it appear that the
procurement is set to day N-1.
opw 1831272
d28f8f704f carefully clears only the
relevant bit of the cache (only the top-level object which we're
exporting), however the commit did not considert that _export_rows
calls itself recursively for relational fields, and thus when
exporting relational fields the relation would become the new
top-level and get cache-cleared on every iteration, significantly
slowing down cases where such records are shared and would need to be
re-fetched every iteration, even more so if they're somewhat/somehow
expensive.
OPW-1833545
OPW-1836361
While c059e7b93c64b9dd9bc96eeb6ee5cadf significantly lowers the cost
of generating xids, a safety invalidate cache can regress cases
significantly e.g. 18s -> 430s (7mn) for some recursive exports of
xids as the cache would be completely cleared *after each record*
requiring complete fetching & recomputation of the following records.
Fix by only clearing the cache if we've actually had to create
xids *and* only for ir.model.data records.
It's possible that clearing the cache isn't even necessary at all (?),
check with @rco-odoo
OPW-1835226
In the form view, a new problem appeared since we introduced the extra device
size_class: the buttonbox was folded for large screens, even if there is
only two buttons.
The reason is that the form renderer code used a list to map size class
numbers to the number of buttons allowed to be displayed. With the
extra size class, this number was undefined, which caused an issue.
The discuss application starting process is strongly asynchronous.
However, it relies implicitely on the fact that the widget is not
destroyed in its starting process. For example, if the widget is
detroyed before the updateChannel method is called, then any call to the
chat manager service will return undefined and the widget will crash.
When discuss is destroyed exactly between the start and the end of the
creation of its search view (which is asynchronous), then it is possible
to have a crash, because the search view will be destroyed when the
do_search method is called.
Note that we had to fix discuss mobile as well:
The _setChannel method is supposed to return a deferred, but the mobile
override did not return it. As a result, a test in the mobile suite
failed because this.alive takes a deferred in argument.
In the form view, a new problem appeared since we introduced the extra device
size_class: the buttonbox was folded for large screens, even if there is
only two buttons.
The reason is that the form renderer code used a list to map size class
numbers to the number of buttons allowed to be displayed. With the
extra size class, this number was undefined, which caused an issue.
The discuss application starting process is strongly asynchronous.
However, it relies implicitely on the fact that the widget is not
destroyed in its starting process. For example, if the widget is
detroyed before the updateChannel method is called, then any call to the
chat manager service will return undefined and the widget will crash.
When discuss is destroyed exactly between the start and the end of the
creation of its search view (which is asynchronous), then it is possible
to have a crash, because the search view will be destroyed when the
do_search method is called.
Note that we had to fix discuss mobile as well:
The _setChannel method is supposed to return a deferred, but the mobile
override did not return it. As a result, a test in the mobile suite
failed because this.alive takes a deferred in argument.
The discuss application starting process is strongly asynchronous.
However, it relies implicitely on the fact that the widget is not
destroyed in its starting process. For example, if the widget is
detroyed before the updateChannel method is called, then any call to the
chat manager service will return undefined and the widget will crash.
When discuss is destroyed exactly between the start and the end of the
creation of its search view (which is asynchronous), then it is possible
to have a crash, because the search view will be destroyed when the
do_search method is called.
Note that we had to fix discuss mobile as well:
The _setChannel method is supposed to return a deferred, but the mobile
override did not return it. As a result, a test in the mobile suite
failed because this.alive takes a deferred in argument.
Purpose
=======
The method compute is annoying for the following reasons:
- 'compute' is difficult to grep
- Developers don't understand that they can specify the company and
the date on which we want to convert the amount. This is quite
error prone because if these parameters aren't specified, they are
set by default to the company of the current user and the current
date (today).
- Passing parameters is the context is not a correct way to call a method.
Furthermore, using with_context is not really good for the performance too,
as the record as to be rebrowsed, the computed fields have to be
re-evaluated
Specification
=============
- Introduce a new method '_convert'. This method takes 2 more
parameters: 'company' and 'date'.
- Deprecate 'compute' and '_compute'. Log a warning to notify that we
should use '_convert'.
Revision on https://github.com/odoo/odoo/commit/32b8cec5361174c92c45a4975d4e02f1fb448aa2
Before this commit, when we switch channels in the Discuss app, the breadcrumb
was visually not updated: it keeps the name of the first opened channel.
With this commit, the breadcrumb is updated on each change of channel, so that
it displays the name of the currently opened channel.
Technical details:
This is due to a change of logic of updating the GUI of the breadcrumb:
before the refactoring above, discuss had to pass the content of the
breadcrumb to the control panel, in order to update the breadcrumb visually.
After the refactoring, the action manager should warn the control panel to
update the breadcrumb on any change of the title. This is already the case
for `ir.actions.act_window`, but not for all types of client actions.
When Odoo display a phone number number, on phone or if VOIP is
installed a invisible `­` character was added from 9.0 up to
saas-11.2 so an applications such as skype would not be concerned with
the number.
But if someone copy-pasted from this to somewhere else in Odoo, we would
get incorrect number with this invisible caracter. So this change make a
special case for the "FieldPhone" so the character is removed from data
saved.
opw-1834858
closes#24223
Before this rev., a crash occured when a default_get returned a
command 0 (CREATE) for a one2many, with a value for a date(time)
field (e.g. [0, false, {some_date_field: '2018-12-08'}]). This
was because the related values (inside the commands) weren't
parsed. This only impacted date and datetime fields, for which the
parsing converts the string into a moment instance.
Fixes#23672
The built-in Odoo profiler can be used directly into the logs. This
information was not given in the documentation. This commit add it. An
example on how to use is shown as well as the produced result.
Have the create_date field displays on a one2many list
Try to add a record onto the list
Before this commit, when the virtual record is added onto the list
it crashes because the datetime field is undefined and cannot be parsed
After this commit, It doesn't crash though the value would have to wait the save on the main record
to be updated (because it is the create_date)
OPW 1834250
closes#24097
- Go to Timesheets > Add a Line (grid view)
- The view opened is `view_timesheet_form`
- Add a description with several lines
- Go to Project, and display the timesheet entries.
- Print the report "Timesheet Entries"
The lines in the description are merged into one single line.
Since it is possible to write a description on several lines, the report
should keep the formatting.
opw-1830703
Recently, rev. 5b3cb812b added a new custom event ('update_filters')
handler to the ActionManager, and rev. 69c9500 added an option
('keepSearchView') to doAction (which can be called by triggering
up event 'do_action').
Both events ('update_filters' and 'do_action') can be triggered by
controllers, and when those controllers were in the dashboard, a
crash occured when they triggered those events. In particular, they
are triggered by the new 'web_dashboard' view, respectively when
clicking on an aggregate and when clicking on the subview button to
open it full screen.
The crashes occurred because the events weren't intercepted by the
dashboard, so they bubbled up to the ActionManager which couldn't
handle the requests properly as it wasn't aware of those sub
controllers.
As there is no search view in the dashboard, the 'update_filters'
event simply needs to be stopped (we can't handle such a request
in the dashboard), and for the 'do_action' event, the
'keepSearchView' option must be forced to false as there is no
search view to keep (we thus force the ActionManager to create a
new one).
Instead, create a new BoardView (in JS only) instead, referenced by
specifying js_class="board" on the fly on the root node of the
arch of the board view.
This ensures that the dashboard addon doesn't impact the FormView,
and this is necessary to ensure that the next commit doesn't break
anything.
The former version of the tax adjustment wizard was copying the selected tax on both the credit and debit line of the created journal entry. Although it was fine for the belgian use case (since the report was taking only the sum.debit or sum.credit to gather data for grid 61/62), this was a stupid limitation as it was preventing to use that wizard to touch any grid using sum.balance (as both lines would be taken into account and cancelling each other).
To enhance/fix this, we introduce a fields.selection in the wizard to depict if the tax needs to be copied on the debit OR the credit line.
Inspired by ticket 1826242.
When creating a timesheet, several fields need to be recomputed:
- `currency_id`
- `group_id`
- `department_id`
- `is_timesheet`
- `validated`
When `validated` is computed before the other fields, the recomputation
will lead to an `AccessError` because of the rule
`hr_timesheet.timesheet_line_rule_user`.
Since the test `test_timesheet_validation_user` expects an
`AccessError`, the test succeeds. However, from time to time,
`validated` is computed last => the `AccessError` is not raised.
Actually, a `ValidationError` should be raised in this case (from the
`create` override in `timesheet_grid`).
This commit is a cherry-pick of 802339c12d
and dcca2e8b9d
In arabic, with the version localization of bootstrap we use the week
starts on saturday. But the version of bootstrap-datetimepicker we use
in 10.0 and saas-14 is 3.0.3 which only fully supports week starting
on sunday and monday.
Thus in arabic, the column title in the date picker would be:
Sunday <- Monday (ﻥ, ﺙ, ﺭ, ﺥ, ﺝ, ﺱ, ﺡ)
Instead of what the numbered days in the calendar are shown as:
Friday <- Saturday (ﺱ, ﺡ, ﻥ, ﺙ, ﺭ, ﺥ, ﺝ)
This issue doesn't happen in saas-15, 11.0 and over since the library
has been updated with ad6fd5f8 and the as of version 4 supports any
starting day of week, with this change:
https://github.com/Eonasdan/bootstrap-datetimepicker/commit/557b657
opw-1825640
closes#24200
In 93147fb4 the issue that only one page of barcode were printed was
solved.
But there is still an issue since the container element is itself a
page, we got an additonal page with all barcode on it.
To solve this we use a 'report.html_container' instead of
'report.basic_layout' which doesn't wrap the content with a
`<div class="article" />` element.
opw-1827673
closes#24201
Here is the issue that initiated this work: the bank reconciliation tour
sometimes failed in community. The reason was that the discuss client
action seemed to be loaded after the tour started, and interfered with
the second step of the tour.
What happened exactly was the following:
- web client is loaded
- initial action is starting (but not complete) (this is discuss)
- tour manager is loaded and starts the reconciliation tour
- the reconciliation tour changes the url to trigger an hash change
- the web client calls loadState on the action manager
- the action manager perform a doAction with the tour url
- the discuss client action is now ready, and replace the reconciliation
action
- the tour is broken.
The underlying cause is really a generic problem: the action manager
does not add the client action starting process in its 'dropprevious'
concurrency primitive. This is probably not really an issue for the
act_window actions, since they have custom loading code that make sure
the loading process is put in the drop previous, but it is definitely a
problem for all client actions.
The solution is quite simple, and should also protect the act window
renderers: put the action controller in the drop previous
In Less, the size_class XL is now defined and can be used in media-queries.
It is also added in JS for the sake of consistency.
This new size is needed for a fix in enterprise.
Whenever a widget is destroyed, it should be as inactive as possible.
Before this commit, it could happen that a widget was destroyed after
the willstart method, but before the start method. In that case, bad
things could happen.
For example, the discuss client action tries to look up some information
into the session, with the getSession method. This causes a crash
whenever the widget is destroyed.
Kirti Choudhary