Before this commit, we could not remove an attachment in the composer
by clicking on the white-cross icon that is shown on mouse hover.
This was due to the handler function picking the wrong DOM element
as target for reading on the attachment ID: it should pick the target
of this handler function, and not the specific target below the mouse
on click. For instance, let's consider this HTML snippet for the button:
```
<div class='delete' data-attachment-id=100>
<span class='cross-icon'>X</span>
</div>
```
where the handler function is called when clicking on `div.delete`.
When we click on `span.cross-icon`, it triggers the handler function
of `div.delete`. The MouseEvent object contains the following property
values:
- `target`: the `<span>` element
- `currentTarget`: the `<div>` element
The handler function of `div.delete` deletes an attachment by looking
into the `data-attachment-id` attribute of `div.delete`. It should
always pick `div.delete`, even when the user clicks on `span.cross-icon`.
The computation is badly implemented. Wrong
data struture used at the wrong moment.
This commit fixes it: remaing hour in overview
is SOLD qty - DONE qty (sum of timesheets).
Task #1857652
- Create 2 Companies A & B
- Set User B in Company B
- Record some `mail.activity` for User B on a lead belonging to Company
B.
- With a manager user in Company A, go to Kanban view of leads and
remove filters => all leads, including leads in Company B, are
displayed
An access error occurs.
`read_progress_bar` method, tries to access the field `activity_state`
which is: `states = record.activity_ids.mapped('state')`. The state of
a `mail.activity` is using the tz of the partner. To read the
`activity_state` of a lead, one needs to access
`record.activity_ids.user_id.partner_id.tz`
=> multi-company security rules raised
opw: 1850984, 1859470
Suppose there is a one2many field embedded in a one2many,
(say we are viewing record A with one2many field B itself with a one2many C).
Furthermore, there is a second page of the one2many field B.
If an onchange is applied on B, then the server replies with a 1 command for all
B records attached to the currently viewed object A.
This includes a list of commands [[5], [4, C_id]*] for each B record,
in particular B records that are on the second page.
Since they are on the second page, they might not have been fetched by the
frontend; in that case the corresponding C_ids are thus unknown.
As a consequence, on save the frontend sends a command 0 to create the records
for all unknown C_ids.
Since it doesn't have any value to give to the 0 command, the row creation
usually crash in the backend.
Another wrong behaviour is fixed at the same time: if the server sends an update
on the list of C ids with 4 commands.
In that case, if the record has not been prefetched, we have no way to know
if the list changed or not.
To solve this, when we receive the 4 commands by the server, we send back 4
commands.
coauthored by @aab-odoo
opw 1835936
Before this commit, there was a traceback in the following scenario:
Let's have a kanban view with groupby and a domain.
If we clear the domain then clear the groupby, there could be a crash.
This crash occurs because when we clear the groupby, it performs a `reload`,
and assumes that the datapoint contains grouped data. However, if this
computation takes some time, it is possible to overwrite the datapoint so that
there is no longer grouped data.
This commit fixes the issue by enforcing at most 1 execution of the method
`reload` active at any time. Consequently, successive reloads operations are
now much slower.
Note that it uses the single non-reentrant mutex on the basic_model to enforce
this rule, which means:
- No more concurrent `reload` and `save`.
- If an execution having the mutex in `reload` come accross the same mutex,
it is blocked forever. This is hopefully not the case at the moment,
however a reentrant mutex should be considered in the future.
The barcodes modules had documentation only available on apps.odoo.com,
following a recent change, odoo modules are not displayed on
apps.odoo.com anymore.
Thus this commit merges the documentation onto the module description so
it is available on the module page.
opw-1846035
closes#25621
Clicking outside the new content options should close the overlay.
Every options are triggering a JS event (mostly opening a modal) that works
fine.
But the 'New Job offer' options is simply a href link which is not going
through anymore since there was a call to `preventDefault`.
opw-1860196
As `pre-` migration scripts may use the registry, we must ensure that
all fields are set up before execution in order to have a consistent
registry.
This is required when loading a registry which contains modules to
install/upgrade without `-u` flag. In this case, the setup was only done
*after* module loading.
The purpose of this commit is to hide the Create menu when the user click on
any area other than the link icons.
Note: It was already the case in V10.0 since the options were inside a modal.
Natively bootstrap would close the modal when clicking outside of it.
We lost that behavior while refactoring in V11.0 with 297297696 that
replaced the modal by a pseudo-dropdown
opw-1860196
Closes#25389
The function _get_graph computing the dashboard graph must take the timezone of the user
into account to compute the right start_date S and the right end_date E.
The query made on model 'report.pos.order' by read_group in _graph_data must take the
timezone of the user into account to substract the right offset to compute the start_date S
and end_date E in UTC because the result returned by read_group is formated in the timezone
of the user afterwards.
Example:
In function _get_graph:
Start_date in 'Asia/Ulaanbaatar' timezone = 2018-06-05
End_date in 'Asia/Ulaanbaatar' timezone = 2018-07-04
So End_date - Start_date + 1 = 30
In function _graph_data:
Start_date in 'Asia/Ulaanbaatar' timezone = 2018-06-05 00:00:00
End_date in 'Asia/Ulaanbaatar' timezone = 2018-07-04 23:59:59
So in UTC -9 hours:
Start_date in UTC = 2018-06-04 15:00:00
End_date in UTC = 2018-07-04 14:59:59
SELECT min("report_pos_order".id) AS id,
count("report_pos_order".id) AS "date_count" ,
sum("report_pos_order"."price_total") AS "price_total" ,
date_trunc('day', timezone('Asia/Ulaanbaatar',
timezone('UTC',"report_pos_order"."date"))) as "date:day"
FROM "report_pos_order"
WHERE (((("report_pos_order"."date" >= Start_date) AND
("report_pos_order"."date" <= End_date)) AND
("report_pos_order"."config_id" in (1,2,3))) AND
("report_pos_order"."state" in ('paid','done','invoiced')))
GROUP BY date_trunc('day', timezone('Asia/Ulaanbaatar', timezone('UTC',"report_pos_order"."date")))
ORDER BY "date:day"
And the result of this request will be between 2018-06-05 00:00:00 and 2018-07-04 23:59:59 but
before the fix the result was between 2018-06-05 00:09:00 and 2018-07-05 08:59:59 and then
End_date - Start_date + 1 was equal to 31. That's why a "IndexError: list index out of range"
can be raised in _get_graph.
In this way, no mismatch is possible between the datas computed by _graph_data and the dict
"values" allocated by _get_graph.
opw:1862996
These two columns are used to compute the mailing statistics, to be
displayed in the kanban dashboards. Adding them makes the dashboards
a lot faster on large databases (e.g. a few milliseconds instead of
several seconds)
The kanban view displays mailing statistics for all mailings that are
sending or done. To compute these statistics, it uses the `total` as the
expected number of emails to send. This `total` used to be computed as
the number of records matching the mailing filter.
This is both slow (filters are seldom written in an optimized way), and
incorrect because the recipients were frozen when the email was sent.
The number of matching records may have changed since then.
To fix both problems, introduce a new `expected` computed field that
simply returns the number of emails that were put in queue at the time
of sending, and thus represent the real number of expected emails.
This field is computed along with the rest of the statistics.
The framework supports a special `group_expand` attribute on fields,
to provide a helper method that expands the list of columns in a
read_group (typically meant to display empty columns in kanban views)
See rev. 580e78ad37
More efficient, and less code.
Have a view with a field as:
<field name="stuck_in_the_middle" attrs="{'readonly': [('with_you', '=', False)]}"/>
Before this commit, the contents of attrs were parsed and merged into the modifiers
and the attrs attribute of the node was deleted
which might cause divergence between reality and tests
After this commit, the mock server does what the server does in this case
closes#25583
Problem: create a bank statement with a line that has a positive amount
and a line that has a negative amount. Both line does not have a partner
Then click on reconcile to open the reconciliation widget, notice the
message stating that we have to select a partner or choose a counterpart.
Select a partner on both line, behavior is different for the line with
credit > 0, the message still says "select partner or choose counterpart"
This commit fixes this problem.
Before this commit:
* Install module A
* Edit a view from module A, add a custom field
* Uninstall module A
* Reinstall module A
* Try to access the module A's previously modified view
-> Can't access the view, or even sometimes the app at all.
Cause:
When uninstalling module A, the custom field added to module A's is
properly unlinked, however the custom/studio view is not unlinked, therefore
the view references a field that no longer exists, when accessing the
view it will obviously crash (sometimes the traceback is not even
displayed to the user!).
Solution:
Emulate an ondelete cascade for child views only when in uninstall mode.
Steps to reproduce the bug:
- Create an invoice with positive lines and negative lines and with a total equal to zero
Bug:
In some cases total amount is equal to -0.0 and it raised:
"You cannot validate an invoice with a negative total amount"
The field amount_total is a monetary field, so it's computed in the precision
of the currency of the invoice.
opw:1862439
Steps to reproduce the bug:
- Go on a SO and click on "Send by email"
- Remove the attachment and click on "Add an attachment"
- Choose an attachment A and remove it by clicking on the cross
- Click on "Add an attachment" and choose the attachment A
Bug:
The attachment didn't appear in the modal.
opw:1862482
There is no reason to prevent creating a menu linked to a top menu
It does work to have only one parent level as a menu
Error reported during technical training
Steps to reproduce the bug:
- Create 3 stockable products P1, P2, P3
- P1 is tracked by serial numbers
- Create a BOM for P3 with one P1 and one P2 as components
- Set the quantity on hand to 5 for P1 and P2
- Create a MO for P3, produce it and mark the MO as done
- On the MO in the sheet "Consumed product", the quantity_done for
P1 and P2 are equal to 1.0
- Change the tracking of P1 to "No tracking"
Bug:
- Check the sheet "Consumed product" on the MO and the quantity_done
was equal to 0.0 instead of 1.0
opw:1856340
This changes the order in which the data and the views are loaded.
Caused a problem in some fringe cases.
Install then uninstall project, playing around with discuss, when reinstalling project ,
system is trying to notify a partner and the weird order
in which the data and the views are loaded makes it bite the dust
opw:1861157
In stock.move.lots.form view, the field product_uom must be readonly like
the field product_uom_qty.
Fine tuning of this commit: 2ab3fa86fe
opw:1861321
In stock.move.lots.form view, the field product_uom must be readonly like
the field product_uom_qty.
When creating a raw material, it was not possible to add a stock move line
with a finished product for a product which is not tracked.
The consumed field must be readonly in mrp_production_form_view view to avoid
to send to the server wrong value manually set.
opw:1861321
Extension of commit c4f5b9f751
Instead of disabling only the button on which the user has clicked, we
disable all 'Add to Cart' buttons until the end of the transaction.
Closes#24853
opw-1858080
Odoo Translation Bot