Before this commit, when we have a notification in the messaging menu (systray)
that comes from a message in inbox which isn't linked to a document
(e.g. a task), clicking on it result in a crash.
This issue comes from a typo of a recent js mail refactoring [1]
Although this is only a 1-line fix, there are no tests on the messaging menu
widget in the systray. Therefore, this commit also introduces some basic tests
of this widget, in addition to the test related to the fixed issue.
[1] https://github.com/odoo/odoo/commit/02ec09cb1c3e2d7bc7968f40c18f2208d7f3f498
Revision of https://github.com/odoo/odoo/commit/c778de44c7cd9b7ef5a9a91738164ab0ebd0ca06
The commit above changed the composer in order to add colored text for mentions
(instead of textarea, it uses a div with contenteditable).
Some tweaks were made in order to preserve the css style of the composer, but
there were some leftovers:
- placeholder "Write Something" should be more transparent
- cursor hover on placeholder should be of type text
- text is not vertically centered with the input container
- there should be no focus border when the composer has the focus
- "Send" button is vertically misaligned by 1 pixel off in discuss
This commit solves all of the above problems.
As a result, the css style of the composer should look almost similarly to the
one in v11.
There's a certain configuration of UOM that is not correctly handled in
the v11 stock:
- create a move with an UOM having an higher factor than the product's
UOM
- this higher UOM has a rounding of 1.0, meaning it doesn't allow
partial reservation
- use the product's uom in this move and enter quantities that aren't
expressible in the move's uom
A practical example is to set the rounding of dozen at 1.0, set the uom
of a product to units, create a move for a dozen and create a new move
line with 8 units.
The first issue is the `quantity_done` field, that uses an half-up
rounding on the `qty_done` field of each move line and sum them. When
applying this logic to the previous example, `quantity_done` field would
be 1.0, meaning we won't make a backorder for the missing 4 units. We
fix these issue by summing a non rounded qty_done and afterwards
rounding this value to the general products'UOM. This mean
`quantity_done` is technically not be expressible in the move's uom, but
keeping this value close to the reality will allow to handle the
backorders and extra moves correctly.
The second issue is that the backorder is always expressed in the move's
uom. In the previous example, this would mean creating a backorder of 0
dozen. In v10, an error was throwed, saying this operation is
impossible.
The `_prepare_move_split_vals` previously always received the quantity
of the backordered move in the uom of the original move. This is a
remnant of the v10 implementation where, if the quantity to backorder is
not expressible in the original move's UOM, an error was throwed. We now
pass the used uom via a context key to not update the method signature,
as it is probably legitimately overidden by custom modules. This way, in
the previous example, a backorder of 4 units is created.
The last issue is in `_action_assign`. Let's say you have 8 units in
stock and you want to reserve a dozen, the system will reserve 8 units
and then convert back 8 units in dozen, meaning a dozen was reserved.
This resulted in awkward situation where more items than available were
reserved, and the famous "cannot unreserve more than what's available in
stock" was throwed at almost each operation. To solve this, we convert
the not-yet reserved quantities back and forth in both uom. This
prevents partial reservation when not allowed, which is good. We had to
adapt some lines of `_action_assgn` that expected
`_update_reserved_quantity` always at least partially reserved the move.
It is now possible that it doesn't reserve anything.
We also normalize the quantity with a greater decimal precision when
deciding if we open the immediate transfer wizard or not (in the
original exemple, if you enter a single unit the immediate transfer
wizard would be openned because 0 was done in the UOM of the dozen). We
also prevent to enter `qty_done` on the move line if the value doesn't
honour the rounding of the UOM.
We introduce two tests, a simple `_action_assign` in MTS and a more
complete MTO scenario with backorders, extra moves and invalid qty_done.
opw-1835186
opw-1835946
Restore behaviour of not adding the separating dot if the module field
of an ir.model.data record is empty. This is useful/important for
interop with external systems.
When a record fields are prefetched, the currently accessed record is
prefetched as well as PREFETCH_MAX (=1000) minus currenly accessed
records.
Since 439fa826 the id field was thought as "prefetched" but was not,
which caused that in an onchange, we would have a prefetching as follow
for 1200 records:
- get records 1-1000
- get record 1001 (1001-1200 INTERSECTION 1-999 (id) + 1001 (current))
- get record 1002 (1002-1200 INTERSECTION 1-999 (id) + 1002 (current))
- get record 1003 (1003-1200 INTERSECTION 1-999 (id) + 1003 (current))
- ...
- get record 1200 (1200 INTERSECTION 1-999 (id) + 1200 (current))
So we would do 201 queries instead of 2 when prefetching the records.
The added test without this change failed the query count with:
"AssertionError: 284 not less than or equal to 5 : admin"
opw-1837548
opw-1837552
closes#24326
The notification manager was removed and replaced by a notification
service. Some tests were forward ported after this change, so they need
to be updated to the new system.
- Create a stockable Product A
- Get create an incoming picking at date D for A
- Go to Inventory > Report > Inventory, and search for the the inventory
at date D-1.
- A should appear with a quantity on hand of 0.
- Filter on 'Available Products'
The product still appear in the list with a quantity on hand of zero.
The optimized method `_search_qty_available_new` is used, although it
doesn't take into account dates.
The original use case for this optimized method was to quickly get
products with stock on hand, i.e. products with quants without needed
information of stock moves.
opw-1833510
- Create a MO for Product A with quantity to produce of 2
- Produce 1
- Open the associated BOM, and add a line to the bom
- Go back to the MO and try to update the qty to produce to 1
Traceback: division by 0
opw-1838006
The portal view for tasks previously listed all task of all projects
without grouping them. It was a problem, mainly when we want to make
the distinction on project label_tasks, to make the difference
between tasks, issues, ... Grouping task by project by default allows
to show the label_tasks before each project.
Grouping the tasks removes the possibility to define a primary
ordering. We want to be able to ungroup the tasks in some cases.
The implentation was done in the portalsearch bar adding
a group by option. The portal proposes two grouping options,
project (by default) and none (to keep strict ordering).
Task: #1827950
PR #23769
this.call('web.Notification', 'notify', params)
Display a notification at the appropriate location, and returns the
reference id to the same widget. Note that this method does not wait
for the appendTo method to complete.
@param {Object} params
@param {string} params.title notification title
@param {string} params.message notification main message
@param {string} params.type 'notification' or 'warning'
@param {boolean} [params.sticky=false] if true, the notification will stay
visible until the user clicks on it.
@param {string} [params.className] className to add on the dom
@param {function} [params.onClose] callback when the user click on the x
or when the notification is auto close (no sticky)
@param {Array<Object>} params.buttons
@param {function} params.buttons[0].click callback on click
@param {Boolean} [params.buttons[0].primary] display the button as primary
@param {string} [params.buttons[0].text] button label
@param {string} [params.buttons[0].icon] font-awsome className or image src
@returns {Number} notification id
this.call('web.Notification', 'close', notificationId)
Here is a scenario that could happen before this commit:
1. go to a list view with more than one record, say 3
2. click on the 3rd record to open the form view
3. the pager says 3/3
4. click on edit button
5. click on discard button
6. the pager says 1/3 (but the record displayed is still the same)
It is often necessary to restore the offset for the sub records, because
the number of pages in a one2many could have changed. However, it is
not a good idea to do that for the main record, since it interferes with
the usual flow of operations.
Currently, the default field widget of type html is not defined in the
web addon, but in the web_editor addon. It uses the summernote library
and different assets.
The web_editor addon is defined with auto_install=true, so it is usually
not an issue. However, it could happen that there is some issue with
the web_editor asset bundles. In that case, any form view with a field
of type html will crash.
With this commit, we define a default widget of type html in the web
addon. This will render as text (so, not exactly what one might
expect), but it is still better than making the web client unusable.
Previsouly, the m2o fields in writeoff creation mode of manual reconciliation widget were always empty because of a bad domain filtering out all the existing records (company_id was unknown).
We now display all the existing currencies (even the unactivated) instead of a link to activate more of them, and upon the save we make sure to activate the selected currency if it's not yet the case. That's better from a point of view since it avoids jumping off of the screen then come back to make this setting
A whole XML file was missing in the initial import which had as effect to still display 'TIN' instead of 'VAT' in the res.company form view even if the module was installed
As we have two parallel tasks changing the rights for the approval of
leaves, we have to make sure that it stays coherent.
Basically by default an hr_holiday manager can approve anything and the
hr_holiday officer can only approve the leaves of his department and
cannot approve his own leaves.
But you can override this behaviour by setting the Validation By to
"Manager" which will force the leave to be approved by an hr_holiday
manager.
The label and the help message for override limit were confusing, it is
now changed for a less confusing label and help message.
Another confusing thing is that when having a leave type able to
override the limit it should not be visible in the allocations hence it
should not be possible to set the visibility option.
Assume a custom field F is defined on model 'res.partner'. The setup of F may
silently fail because of missing stuff. In that situation, setting up the
field inherited from F on model 'res.users' should also silently fail.
To reproduce the bug, install Invoicing, create a related custom field F on
'res.partner' with 'property_account_position_id.active', and install another
module. Setting up F after loading module 'base' will fail because the field
'property_account_position_id' does not exist yet. The error is not caught by
the inheritance of F on model 'res.users', and the installation crashes.
When phantomjs crashes, an error is logged only when the crash is a segfault.
From time to time, we see on the runbot some crashes without any
informations. When digging in the log files, it appears that the exit value
of phantomjs is -6 (that could correspond to the SIGABRT signal).
With this commit, the error message will clearly show the return code
and, above all, it will show that the test failed due to a phantomjs
crash.
When calculating the stock_value of a product,
the system will take into account all the locations
that have this company as company. (that way if owner_id
is not set, the company_id on the location is the owner (virtual: not set))
The Qty on Hand field takes into account however
the quantities that are in the warehouses.
This could lead to weird situations where the Quantity On Hand is 0
and so the record is not shown, while the stock value is positive.
(e.g. stock in Transit)
In order to use the same logic for both fields, we pass company_owned=True
in the context.
Assume a custom field F is defined on model 'res.partner'. The setup of F may
silently fail because of missing stuff. In that situation, setting up the
field inherited from F on model 'res.users' should also silently fail.
To reproduce the bug, install Invoicing, create a related custom field F on
'res.partner' with 'property_account_position_id.active', and install another
module. Setting up F after loading module 'base' will fail because the field
'property_account_position_id' does not exist yet. The error is not caught by
the inheritance of F on model 'res.users', and the installation crashes.
OPW 1835872
In the table of the project overview, we want the
milestone Sale Line not to be included in the remaining
computation of the SO (sold - done column), because selling
milestone product may not be expressed in Hours.
This commit excludes those line from the computation, and
aoivd displaying those 2 columns for this kind of table
rows. Also, it adds italic style on milestone lines to
indicate to users that they are not included in remaining
value.
Task #1834454
- Fix an issue where the transaction were always set a 'form_save' thus always creating payment tokens.
- Fix an issue where when the customer paying while not being logged in was crashing.
The issue is due to the fact that we are creating payment transactions linked to no partners, doing so it crashing the code when creating the payment token with no partner set.
Martin Trigaux