Ease the understanding of the notifications sent when users are assigned to an
activity.
Improves mail layout re-usability by replacing the 2 existing layouts:
- message_notification_email --> mail_notification_layout: a little more generic
(introduce a list of subtitles instead of a unique one) and defined as the default
layout. Note the rework version done to support outlook client in
odoo/odoo#92847 has been integrated
- mail_notification_paynow --> mail_notification_responsible_signature_layout:
inherited from mail_notification_layout with just the signature changed.
Technical note: the customization of data sent to the email layout template
(here subtitles) should be done by overriding
mail_thread._notify_by_email_prepare_rendering_context on the model.
But in this case, we send an activity (ex.: todo) for a model (ex.: crm.lead)
which involves 2 models. Data from both models must be sent to the template
layout. To solve this problem an optional parameters to
mail_thread.message_notify has been added: subtitles. This allows the
caller which knows about the 2 models to set the values for subtitles for
the template.
Task-2801600
closesodoo/odoo#88466
Related: odoo/enterprise#31281
Related: odoo/upgrade#3620
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Make mail_notification_layout as the default mail template and remove
message_notification_email. We now only have 2 main notification mail layout
templates (outside of a light one): the default one and one that inherits from
it to only change the signature to the responsible instead of the author one.
In this operation the layout of message_notification_email has been integrated
in mail_notification_layout to support outlook mail client for which
message_notification_email has just been reworked (odoo/odoo#92847).
Technical note: we have integrated the "internal communication" banner from
"message_notification_email" into the new default template
"mail_notification_layout" which cause one added query in the test for querying
the flag internal from mail.message.subtype.
Task-2801600
Part-of: odoo/odoo#88466
"mail_notification_paynow" mail template layout has been renamed to
"mail_notification_responsible_signature_layout" as it now only differ by the
signature. It allows to use it more widely.
Task-2801600
Part-of: odoo/odoo#88466
Ease the understanding of the notifications sent when users are assigned to an
activity or a model (task, lead, ...).
Technical note:
- the customization of data sent to the email layout template (here subtitles)
should be done by overriding
mail_thread._notify_by_email_prepare_rendering_context on the model.
But in this case, we send an activity (ex.: todo) for a model (ex.: crm.lead)
which involves 2 models. Data from both models must be sent to the template
layout. To solve this problem an optional parameter to
mail_thread.message_notify has been added: subtitles. This allows the
caller which knows about the 2 models to set the values for subtitles for
the template.
- mail_activity._render_notify_header has been added to render the subject and
subtitles using the language of the recipients through the context lang
variable.
- a generic mail notification template has been added and the specific
mail_notification_paynow has been derived from it as the only change is the
handling of the signature.
Task-2801600
Part-of: odoo/odoo#88466
Current behavior:
If you create a promotion program that applies on specific products that
have different taxes, the maximum amount of the promotion was not
respected. For example, if you had 2 products with 2 different taxes you
could have 2 discounts with the maximum amount of the promotion program.
Steps to reproduce:
-Create 2 products A (15$) and B (25$) with different taxes T1 and T2
-Create product C (30$) that we will use to activate the promotion
-Create a promotion program, based on product C, that applies
on products A and B. It should have a max amount of 40$ and
a discount of 100%.
-Go in the PoS application and apply the new promotion program on a PoS
and start a new session.
-Add 2 products A and 2 products B to the order, then add product C. The promotion
is applied but it creates 2 discount lines of 30$ and 40$ which is more than the
maximum amount of 40$ set in the promotion program
opw-2927711
closesodoo/odoo#99778
X-original-commit: ae03982f53f382b0689befe267fd3820ceafb385
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Masereel Pierre <pim@odoo.com>
In order to avoid empty contract histories when there are existing but
cancelled contracts, cancelled contracts are now also included in the
contract history.
task-2939158
closesodoo/odoo#99767
Signed-off-by: Kevin Baptiste <kba@odoo.com>
This PR addresses 2 issues in kanban views with progress bars:
1) When updating the field on which the progress bars are computed in a record, an inert "Load more" button would appear
2) After updating said value, the progress bars would not be recomputed
Both of these problems have been fixed.
Enterprise PR: https://github.com/odoo/enterprise/pull/31126
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#99748
Related: odoo/enterprise#31126
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit adapts the InventoryReportList view along with a refactor
of the "record-updated" event API: as it now contains records related
to the one that triggered the event, there is no need to traverse the
model to find them anymore.
Part-of: odoo/odoo#99748
This commit addresses 2 issues in kanban views with progress bars:
1) When updating the field on which the progress bars are computed in a
record, an inert "Load more" button would appear
2) After updating said value, the progress bars would not be recomputed
Both of these problems have been fixed.
Part-of: odoo/odoo#99748
Remove the security group introduced in odoo/odoo#97988 as it's
redundant with the group_hr_user.
task-2929518
closesodoo/odoo#100127
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Spreadsheet template feature is a feature enterprise but some part of
the code is located in community following a split in the modules.
The code is moved where it belongs.
closesodoo/odoo#100120
Related: odoo/enterprise#31292
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
This is the behavior when creating a res.partner.bank from the res.partner form view. Other views allowing such manual creation were missing this behavior.
closesodoo/odoo#100103
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
When a selection start from a table and finish outside editable, the
toobar was disable but should be enable.
task-2982630
closesodoo/odoo#100091
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit
The call to `historyunPauseSteps('handleSelectionInTable')` is not
called without a mouseup.
If called from `historySetSelection` in an undo and multiples commands
were to be called before a mouse up, no step would be created.
Also, `observerUnactive` and `observerActive` should be used rather than
`historyPauseStep` and `historyUnpauseStep` for mutations that are
visual and local to the user.
task-2982429
Part-of: odoo/odoo#100091
Add a relative global filter for the last 90 days, and one for the last
180 days.
Odoo task 2968572
closesodoo/odoo#100085
Related: odoo/enterprise#30949
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Before, when using a cash basis tax in the bank reconciliation widget, the account chosen for the tax line corresponded to the tax transition account. This was wrong: since the entry is already reconciled, we want to use the actual repartition account, as nothing will move this amount from the transition account afterwards.
Indirectly linked to OPW 2865789
closesodoo/odoo#100105
X-original-commit: bd7d21493490a0341621b36082051478ff2293bb
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Laurent Smet <las@odoo.com>
Steps to reproduce:
- Create a transfer and choose whatever operation
- Enable detailed operations option for the operation
- Check availability and set quantities
- Cancel the transfer then Go to Product Moves
Current behavior:
- todo filter is broken, it shows canceled moves
Desired behavior:
- Show only moves that are assigned or waiting
- Task id: #2981249closesodoo/odoo#100115
Signed-off-by: Tiffany Chang <tic@odoo.com>
To reproduce the issue:
(Need delivery)
1. In Settings, enable "Packages"
2. Create a product P:
- Type: Consumable
- Weight: 1kg
3. Create and confirm a SO with 1 x P
4. Open the related Delivery Order
5. Put in pack
5. Open the detailed operations of P
6. Edit the destination package
Error: on the package form, the computed weight is 0kg, it should be 1kg
We should provide the `picking_id` in the context so that the compute
method can do its job:
https://github.com/odoo/odoo/blob/5a8690b35a2fa9c5ed81d858ac0d170beaabaaf9/addons/delivery/models/stock_picking.py#L14-L18
OPW-2972868
closesodoo/odoo#100099
X-original-commit: d11d6662a470e3a078fb2162a775ad35d9228cb7
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
If `_merge_moves_fields` is called with a recordset of several SM, and
if there are more than one `self.picking_id`, the method will trigger a
`ValueError` (Expected singleton)
OPW-2861605
closesodoo/odoo#100087
X-original-commit: d3924054437cb2add044f51a3c03346a67f24674
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Also get rid of {'column_invisible': False} in modifiers
e.g. in the account move list
Before:
```xml
<field name="invoice_partner_display_name" string="Customer" modifiers="{"readonly": true, "column_invisible": false}"/>
```
After:
```xml
<field name="invoice_partner_display_name" string="Customer" modifiers="{"readonly": true}"/>
```
closesodoo/odoo#100084
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
This commit is three-fold:
1) we now honnor attributes `create` and `import` which can be
set to a falsy value in archs (and in these cases, we disable
the import feature)
2) we converted the base_import test suite to use the owl views
3) we whitelisted the base_import addon for the lint/prettier
script
closesodoo/odoo#100026
Signed-off-by: Géry Debongnie <ged@odoo.com>
This seems to be caused by changes in odoo/odoo#97984
The tests didn't seem to be executing since they had legacy dependencies
closesodoo/odoo#100025
Signed-off-by: William André (wan) <wan@odoo.com>
The pregenerate of assets_bundle should be done maximum two times
- at the end of an install/update if the module test_assetsbundle is
installed
- at the beginning of post_install tests
Currently, during the nightly (install and all tests are ran at the
same time), the pregeration of assets is triggered at the end of some
tests
File "/home/xdo/osrc/master/odoo/odoo/tests/common.py", line 319, in _tearDownPreviousClass
super()._tearDownPreviousClass(test, result)
File "/usr/lib/python3.8/unittest/suite.py", line 300, in _tearDownPreviousClass
previousClass.doClassCleanups()
File "/usr/lib/python3.8/unittest/case.py", line 731, in doClassCleanups
function(*args, **kwargs)
File "/home/xdo/osrc/master/odoo/odoo/modules/registry.py", line 704, in reset_changes
self.setup_models(cr)
File "/home/xdo/osrc/master/odoo/odoo/modules/registry.py", line 306, in setup_models
model._register_hook()
File "/home/xdo/osrc/master/odoo/odoo/addons/test_assetsbundle/models/ir_qweb.py", line 13, in _register_hook
The registry.updated_modules is set to allow post_install tests
to select the right tests to execute. This is a way to define if we
updated some modules loading this registry. This list is unfortunatelly
not emptied before running the test, meaning that if register hook are
called on the same registry again, pregenerate will be executed
a second time.
A solution here is to check if the registry is not ready,
meaning that this is the load_modules call to register_hook
and not the setup_models one
closesodoo/odoo#100079
Related: odoo/enterprise#31271
Signed-off-by: Raphael Collet <rco@odoo.com>
Tooltips (and aria-label) should be used when the content of the element
is not self explanatory; but in the case of the create/save/edit buttons
available in several view control panels (kanban,list,form), tooltips
with dubious usefulness were added (e.g. "Create record" when you hover
on a button labeled "CREATE" is not really an information bomb).
Since these buttons tend to be used in tours, and the "coucouilles"
of the tours will also be some sort of tooltips, it means that you
can have frequent weird visual interactions between nunuts and stupid
tooltips.
This commit removes these stupid tooltips.
Feedback-2973374
closesodoo/odoo#100078
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Imagine a form view with a one2many editable list, containing a
required field. Open an existing record, s.t. in the one2many
there's already a sub record. Modify that subrecord, s.t. the
required field is unset (e.g. empty it, or it can be unset from
the beginning, but then modify another field). Then save the main
record. Before this commit, the record could be saved.
In this situation, the modified one2many record isn't valid, so
we shouldn't be allowed to save. The view should remain in edition
and the invalid field should be indicated.
This commit fixes this issue.
closesodoo/odoo#100059
Signed-off-by: Géry Debongnie <ged@odoo.com>
Change made:
1. In the bills: Payment reference and recipient bank will be editable all the time
2. Change in the filter of payment view
3. Search amount in the payment view
closesodoo/odoo#99990
Task-id: 2978033
Related: odoo/enterprise#31226
Related: odoo/upgrade#3880
Signed-off-by: William André (wan) <wan@odoo.com>
Commit [1] introduced t-cache on the footer making it cached depending
on its website id. This is wrong as the footer can be visible or hidden
depending on the page it is currently rendered in.
This commit adapt the t-cache so that the footer is cached based on the
page.
Steps to reproduce:
- Go in edit mode and click on the footer
- Turn off "Page Visibility"
- Save
Footer is now hidden on every page depending on which page rendered it
first.
[1]: https://github.com/odoo/odoo/commit/b0a2a41d78292cb8b9e53788d40c6dc5915a466dclosesodoo/odoo#99832
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
On mobile, in list view's selection mode, both the left & right bottom
parts of the ControlPanel are displayed but only the left one
(containing the selection banner and actions menu) should be displayed
(and take the full width).
Also, small alignment adjustments.
closesodoo/odoo#99483
Related: odoo/enterprise#31269
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Before this commit, if the Layout's `display` props is a dynamic value
coming from the parent Component (ie. a getter on the component that
controls which parts of the ControlPanel should be displayed), this
value isn't applied after the first initialization.
This commit fixes it by extracting the `display` logic applied in the
constructor to a getter (moving from initialization only to once
called).
Part-of: odoo/odoo#99483
The purpose of this commit is to add a quick create button at the bottom
of each column in order to facilitate the user when he wants to quickly
create a record.
It was already possible to quick create a record in the kanban view.
To do so, the user needed to click on the quick create button placed
on top of the kanban view, forcing the user to scroll to the top of
the view if he consults records at the bottom.
task-2823605
closesodoo/odoo#98703
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
In order to support US and EU at the same time, we're
adding 0.25 as `pos_bill` and removing the 500 one.
Increasing the height of the `MoneyDetailsPopup` to avoid
having a scroll bar while having default data.
closesodoo/odoo#98315
Signed-off-by: Masereel Pierre <pim@odoo.com>
Steps to reproduce (technical):
1. Create a custom view from GraphView and register it in `viewRegistry`.
2. Inherit the `stock.stock_report_view_graph` view and set the `js_class` attribute.
3. Go to any stockable product form view and open the Stock forecast from the smart button.
Result:
The `js_class` is completely ignored.
Explaination:
The view is not loaded like any other regular view. It's loaded in a fragment that's
part of the `stock.ReplenishReport`. When doing so, the `js_class` attribute was ignored.
closesodoo/odoo#100072
X-original-commit: 0b10866a0c66bfcd170bfe6887202e05a0089394
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
In this commit two errors in the rendering of the mega menu are fixed:
* the position of the mega menu when the option `Sub Menus` is `On Hover`
this bug is due that we show the mega menu manually adding the `show`
class on the element in our code. However, in the `On Click` mode,
it's Bootstrap's javascript that handle the show/hide state.
Bootstrap adds the `show` class and also adds the attribute
`data-bs-popper="none"` to the element. In `On Hover` mode this
attribute was missing.
* the render of mega menu in the `+ icon` (`o_extra_menu_items`).
This error occurs because in Bootstrap 5 the width is set with the
`width` property and in Boostrap 4 it was `max-width`. In Odoo
`col-XX-YY` CSS rules are overridden when the mega menu is in the
`+ icon`, but the `max-width` was not changed by `width` during the
Bootstrap 5 migration.
closesodoo/odoo#100068
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
The history of this one is kind of tricky, to say the least.
A fix in the theme install process was done in 14.0 with [1].
It came with a `standalone` test in the `design-themes` with [2].
It had to be a `standalone` test since it is playing with module
operation, which is forbidden in the regular testing suite (sadly).
Since this new test was the first `standalone` test in the
`design-themes` repository, it actually wasn't even properly tested for
months before we realized it. It was missing some runbot configuration
in the nightly build to include the `design-themes` repository in the
standalone testing suite.
Once the runbot configuration was correctly fixed, the test wasn't
working anymore in 15.3 and later version because of some change in the
httpocalypse [3] which made the `MockRequest` not behaving as expected.
Indeed, with [3] the request's context had to be updated through
`update_context` which wasn't adapted/working with `MockRequest`.
Then, since [1] (merged in 14.0) was ported in saas-15.3 at [4] (where
[3] also exists) it was the first time a test using `MockRequest` was
ending up calling business code doing a request's context change.
The business code doing `update_context` and called through the test in
`MockRequest` was then not doing anything and not changing the
`context`. The test was then failing despite the behavior/normal code
base working properly.
This commit makes the request's context change working with
`MockRequest`.
Some people think `MockRequest` should disappear, but right now that's
how it is, we are still using it as this is really useful to be able to
test business code in a frontend context without going through a tour.
For what it's worth, multiple time the community asked us to move it
outside the website module, but also multiple other internal team in
odoo. So, while it might be better or not correct in some cases (mainly
python super), the tool is useful.
[1]: https://github.com/odoo/odoo/commit/b8a24efa71daea1f96465b780f4f0e384ce74703
[2]: https://github.com/odoo/design-themes/commit/4de16d85b7f7d69212576eede82e8a15190d357b
[3]: https://github.com/odoo/odoo/commit/f61aa39ff1190f66cebb8efb8432723214932161
[4]: https://github.com/odoo/odoo/commit/14387f36438b731753e2e7169f54865b123cdcfaclosesodoo/odoo#100070
X-original-commit: 885ce02a15dc093ff98822f80b22c4415fa9cceb
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
In a form view, modify a record s.t. a required field is unset,
and then click on the pager to navigate to the next or previous
record. Before this commit, a notification was displayed (because
a required field is unset), but we switched to the other record
anyway.
This commit restores the desired behavior, which is to stay on the
current record to let the user fix it or discard it.
closesodoo/odoo#100050
Signed-off-by: Géry Debongnie <ged@odoo.com>
From a (e.g.) list view, click on "Create". In the form view, fill
in some fields, but leave a required field empty. Click on the
breadcrumbs to come back to the list. Before this commit, a
notification was displayed (because some required fields are
unset), but we left the form to come back to the list anyway.
The desired behavior is to stay on the form view, and display a
notification indicating that some fields are invalid.
In legacy views, we rejected promises to indicate that we couldn't
leave. This is a pattern we tried not to use anymore in new code.
Instead, we return a promise (if the method is async obviously)
which resolves to a boolean value, indicating if it works or not.
As a consequence, the action service wasn't properly dealing with
new views, as the promises they return always resolve.
This commit fixes the issue by adapting the code in the action
service.
Part-of: odoo/odoo#100050
Before this commit, the title of the SelectCreateDialog opened
when clicking on "Add a line" in a Many2ManyField was always
"Select Records" (the default value), whereas in this case, we
want to see "Add: something", where `something` is the `string`
attribute of the field (which can be overriden by an attrs on the
field node in the arch). This commit restores the desired behavior.
closesodoo/odoo#100046
Signed-off-by: Géry Debongnie <ged@odoo.com>
When stopping the server, all cursors are closed. The issue is that
the ImDispatch thread is kept alive until the main thread exits.
This can lead to errors during server stop: the ImDispatch thread
could try to poll an already closed connection thus raising a
`psycopg2.InterfaceError` exception.
This commit solves the issue by hiding the interface error when
it occurs during server stop.
closesodoo/odoo#100002
X-original-commit: 83777078f1be093c218267c8282e8c11f4fb4e8d
Signed-off-by: Julien Castiaux <juc@odoo.com>
Have a x2ManyField displayed as a (non-editable) list view, and
with a context defined on the x2m field node in the arch. Before
this commit, this context wasn't propagated to the dialog opened,
for instance, when adding a new record. It is now the case.
To make the tests pass, we also needed to make a slight change in
the BasicModel, as it didn't correctly process the context when
adding a new record with additional contexts (e.g. in x2many list
views with custom `<creates>`.
closesodoo/odoo#100000
Signed-off-by: Géry Debongnie <ged@odoo.com>
Odoo's Mergebot