With a recent commit[1], we now gather the chatter related data with a
single controller ('/mail/thread/data') which was a bit scattered
previously. With this controller, instead of searching in dedicated
model, we now simply use the main document/record itself and it's
fields whenever possible. For example, previously for the followers,
we used to search data from 'mail.followers' model, but now we simply
use `message_follower_ids` field of the record itself.
The problem with this approach is, if the record is archived, we won't
be able to fetch the related data. That leads to empty follower list/
activities and a trackback while getting suggested recipients.
This commit fixes the issue by loading the record even if it's
archived, and thus fetching the data required by chatter.
commit[1] - https://github.com/odoo/odoo/commit/e0913197ac84b25b40e7599a6432362141d104c9
TaskID-2748030
closesodoo/odoo#83731
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
When archiving a Tax, you do not want that action to
invalidate Sales Orders and Invoices confirmed in the past
and that were using it.
The purpose of Archiving it is that it would not appear
or be proposed to new items created.
Until now, we had an inconsistency between Sales Orders and Invoices
when a Tax was archived.
The tax "disappeared" from old SOs,
but the amounts remained unchanged, which created an inconsitency.
The domain in the field definition no longer works
because a custom domain in the view is shadowing the current domain.
task-2745094
closesodoo/odoo#83712
X-original-commit: 09f6d682669e4e9d898f89706fece3fa9ce59da3
Signed-off-by: Laurent Smet <las@odoo.com>
When creating automatic entries for multiple moves on different dates with the automatic entry wizard, the wizard would reconcile all the lines on the accrual account of the destination move with the lines on the accrual account of each accrual move. As this would imply reconciling the same lines multiple times, it triggers a reconciliation error.
What must be done is, for each accrual move, reconcile it’s lines with only the related lines on the destination move.
closesodoo/odoo#83732
Task: 2717578
X-original-commit: 502003ac548d6620374dfbab4fb7be6dee3c1bf5
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Florian Gilbert <flg@odoo.com>
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Sometimes _compute_percentage would return a percentage slightly over 100 due to a rounding error. This would then trigger the constraint asserting that percentage must be >= 0 and <= 100.
Task: 2717578
X-original-commit: 813d52ed7daff408819d8838c8c36fcee825905f
Part-of: odoo/odoo#83732
In case of a MRP subcontracting, it is not possible to process the
delivery with several backorders.
To reproduce the issue:
1. Create two products P_compo, P_finished
- Both storable
- P_compo must have the route "Resupply Subcontractor on Order"
2. Update P_compo's quantity: 5
3. Create a BoM:
- Product: P_finished
- BoM type: Subcontracting
- Subcontractors: a partner P
- Components: 1 x P_compo
4. In Inventory, create a planned transfer T:
- Operation Type: Receipt
- Receive From: P
- Operations: 5 x P_finished
5. Mark as Todo
6. Inventory > Resupply Subcontractor, find the delivery of P_compo for
P and process it
7. Back to T, set the done quantity to 1.25
8. Validate T (with backorder)
9. On the backorder BO1, set the done quantity to 1.0
10. Validate BO1 (with backorder)
11. Open the second backorder BO2 and validate it
Error: a Validation Error is displayed "You can not enter negative
quantities.", which doesn't make sense
The issue comes from the inner method `_get_available_move_lines` in
`_action_assign`. When validating a picking, at some point, we are here,
at the beginning of `/mrp_subcontracting._action_done`:
https://github.com/odoo/odoo/blob/6d6b2c41adfa842c82252373b3dbd1ed0a5ebc92/addons/mrp_subcontracting/models/stock_picking.py#L36-L37
To understand what happens next, we need to note that, in this method,
the associated MO will be marked as done later (on line 76). Back to the
current line (L37), we are calling `super` which leads to the
problematic `_get_available_move_lines`. Suppose we are on step 10 (we
are validating the first backorder), we have
https://github.com/odoo/odoo/blob/58a9f57c0827a51e46ef0f52a3d48ba343667fe0/addons/stock/models/stock_move.py#L1390-L1391
`move_orig_ids` contains two stock moves, each one associated to one MO.
However, as said above, the second MO is not yet marked as done, this
will be done later on in `/mrp_subcontracting._action_done`. Therefore,
`move_lines_in` is only defined with the first SM, from the first MO,
with a quantity of `1.25`
Further in `_get_available_move_lines`, we have:
https://github.com/odoo/odoo/blob/58a9f57c0827a51e46ef0f52a3d48ba343667fe0/addons/stock/models/stock_move.py#L1403-L1405
`move.move_orig_ids.mapped('move_dest_ids') - move` gives two SM, and
here is the issue: the second one is already processed, so both are kept
in `move_lines_out_done` and the sum of their quantity is equal to
`1.25 + 1 = 2.25`
Therefore, at the end of the method, when computing the difference, it
gives a negative difference. This negative value will be used to create
a SML and later on, it will trigger the validation error.
Once the above issue is fixed, there is another "invisible" issue that
need to be fixed: when generating several backorders on the deliveries,
only the first one will trigger the creation of a new MO. Suppose we are
back in `/mrp_subcontracting._action_done` (still on step 10 in the
above case), in the first for-loop:
https://github.com/odoo/odoo/blob/6d6b2c41adfa842c82252373b3dbd1ed0a5ebc92/addons/mrp_subcontracting/models/stock_picking.py#L39-L43
`move._get_subcontract_production()` returns the two MO (from the
initial picking and from the first backorder). However, since the first
one has already been processed, the if-condition is validated.
Therefore, this for-loop is done and the second MO is not processed (the
quantities are not recorded and its field
`subcontracting_has_been_recorded` is not defined to `True`). As a
result, still in `/mrp_subcontracting._action_done`, we are now in the
second for-loop:
https://github.com/odoo/odoo/blob/6d6b2c41adfa842c82252373b3dbd1ed0a5ebc92/addons/mrp_subcontracting/models/stock_picking.py#L71-L72
`_subcontracting_filter_to_done` removes the two MOs because the first
one is done and the second one has not its field
`subcontracting_has_been_recorded` set to `True`. The condition in the
first for-loop is not accurate enough.
OPW-2731658
closesodoo/odoo#83658
X-original-commit: 1b740ae148acfc832b124122763817b08ea110ab
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Before this PR, the query from _channel_last_message_ids could take a
significant amount of time.
This add an index to speed up the query.
task-2746108
closesodoo/odoo#83476
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Expected Behaviour
When a user get a mail from the data cleaning about records to examine, the View button should be linked to the same url as the 'here' hyperlink or not be in the e-mail.
Observed behaviour
Clicking the link in the View button lead to an error page
Reproducibility
This bug can be reproduced following these steps:
1. Duplicate a contact
2. Wait for the scheduled task to launch
3. Click on the View button of the mail you'll get about te duplicate
Problem Root Cause
This issue is coming from the way we create the 'View' and 'View Task' button, and can't be changed easily. The easier way to fix this issue is then to hide these button
Related Issues/PR
opw-2674138
closesodoo/odoo#83284
X-original-commit: 3a61747b366a315488837e2e560b305e89217dbd
Signed-off-by: Hendrickx Anthony (anhe) <anhe@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
It was only used one time on a unused field.
We don't want to keep useless fields anymore,
the migration is done for that.
task-2735546
odoo/upgrade#3194closesodoo/odoo#82727
Signed-off-by: Raphael Collet <rco@odoo.com>
Issue:
`_write` checked that the number of modified row in DB was equal to the
number of ids in the RecordSet (raise `MissingError` if not).
This behavior was only used by the ORM to retry
(with exists() on the RecordSet before) if the Missing Error raised.
Then it makes the job a second time (for no reason).
Then:
- Remove the check of number of row (and simplify the call of `_write`)
- Remove the useless return value (always `True`)
- Remove the `set(` before the `split_for_in_conditions`, it adds
randomness for nothing because the `_write` should be call without
duplicate id (even if it is not the case, we don't care).
task-2735546
Part-of: odoo/odoo#82727
The `column_format` of the `Field` class was unused and create useless
noise in the ORM. Then remove it and simplify some flows.
task-2735546
Part-of: odoo/odoo#82727
The `_sequence` was only used for the insertion of data in the DB for
the `id` value. But in Odoo, the `id` is always a `SERIAL`, then the
PostgreSQL fill already the value by the right SQL sequence. Then,
avoid doing the job of the DB by ourselves.
Sadly, we need to manage the case when we create an empty record to
always get a valid query.
task-2735546
Part-of: odoo/odoo#82727
Note: fix not necessary since odoo/odoo@https://github.com/odoo/odoo/commit/a62927e7e2d7df4047f8606b41e70ef61ac29b73 landed in master. This
forward port contains only the test.
Step to reproduce:
- Go to a project with visibility set on 'Invited portal users and all internal users'
- Go a task
- Send an follow invitation to Marc Demo (an internal user)
Intended behavior:
The mail has a 'View task button'
Current behavior:
No view task button
This behaviour is due to the function _get_recipient_data which is supposed to return groups when given pids but doesn't.
See _get_recipient_data docstring.
opw-2727410
closesodoo/odoo#83594
X-original-commit: d113cb6398806a1a744085d041b73b827f9f4ada
Signed-off-by: Damhaut Florian (flda) <flda@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently: "register payment" wizard allows selecting different bank accounts or even creating one when registering a payment on customer invoice/vendor refund.
Should be: the field should be set to partner_bank_id and be set as readonly. When cash journal is selected, "Recipient Bank Account" field should be hidden
Task ID: 2710936closesodoo/odoo#81319
Signed-off-by: Olivier Colson <oco@odoo.com>
As an overridable _neutralize model method was added in a previous
commit, the method is now implemented for various models.
closesodoo/odoo#67825
Related: odoo/enterprise#19042
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
An overridable model method was added in a previous commit in order to
neutralize a database.
This commit adds the implementation of this method on the `iap.account` model.
A _get_iap_config_paremeters method is also added on this model.
Each iap service must override this method to extend the list of
`ir.config_parameter` that need to be neutralized.
Part-of: odoo/odoo#67825
An overridable model method was added in a previous commit in order to
neutralize a database.
This commit introduce the implementation of this method for the payment
modules.
Also, a `_neutralize_fields` helper method is added on the
PaymentAcquirer model to simplify the neutralization of the various
payment modules.
Part-of: odoo/odoo#67825
When debugging a database, it's sometimes desirable to neutralize it to
avoid undesired side effects like sending emails.
This commit adds a generic method `_neutralize` on models to neutralize
the current database. This method has to be overridden by modules models
that needs to be neutralized.
A new CLI command `neutralize`is now available that will permit to
neutralize a database from the command line before starting
investigations.
Pay attention that the neutralize operation cannot be reversed and should
only be used on a database copy.
Task id: 1818795
Part-of: odoo/odoo#67825
With commit 7b165cd5, it was incorrectly assumed that PDT notifications
sent by PayPal could not be verified with the suggested method
(dedicated to PDT notifications) because they were missing some required
parameters. The code was thus adapted to have their verification done
with the method already in place for IPN notifications, as it seemed to
do the job. It turns out that the PayPal sandbox account that was used
at that time was not properly configured, and that PayPal was then
sending IPN-like notifications instead of actual PDT notifications,
which is the reason why the swap of methods worked.
Actually, once the account is properly configured, PayPal sends
correctly populated PDT notifications that must be verified with the
method dedicated to PDT notifications, as the one dedicated to IPN
notifications stops working in that case.
With this commit, the method used to verify the origin and integrity of
PDT notifications is replaced by the one that was previously removed.
The method is however implemented in a more defensive manner to:
1. accept and process the notification without verification if the
account is not properly configured on PayPal.
2. silently discard the notification if the acquirer is not properly
configured on Odoo. We then rely on the IPN (webhook) to confirm the
transaction.
task-2744043
closesodoo/odoo#83659
X-original-commit: 7367f543498810bbdb018aa3566c7afed5684436
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
In master, the tax template consistency test
is broken since 8fb53c53c3
Fix this to make sure we add an exception for
that new computed field as it should not be in
the template.
closesodoo/odoo#83724
Signed-off-by: Florian Gilbert <flg@odoo.com>
Recently, a lot of the network infrastructure code was rewritten. A lot
of this new code doesn't account for the possibility of being on an
external website, and so network requests made with relative URLs would
not make their request to the odoo server but to the server serving the
external page which would fail.
This commit fixes that by replacing the regular rpc service with one
that will add the correct prefix, as well as patching the
"browser.fetch" method to do the same. Additionally, the localization
service is now less fault-tolerant, and won't silently fall back to a
default configuration if it cannot get the translations from the server,
as such, the tranlsations route is made available cross-origin, which
has the added bonus of making translations available to the embeded
code.
opw-2677184
closesodoo/odoo#83690
X-original-commit: 5ec64d15197e8d6cc7b115aeaca99aa49de0f151
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Samuel Degueldre <sad@odoo.com>
With [1] in 13.0, the blog post layouts were reviewed. At the same time,
new demo data was introduced. By default, with demo data, you have now
two different blogs. The JS tour was adapted so that when you create a
new blog post, a step explains you have to select the blog you want to
create the post in with the dialog that opens. The main problem that
this PR aims to solve is that all users start without demo data and thus
with only one blog... so with the current tour, the users are blocked
very early in the tour as they do not have the dialog to select the blog
in which to create their blog post. The simple solution that was chosen
is to set the step as "auto", meaning it will only be used in runned
tours (like via python tests), allowing to still test the blog selection
dialog in our python test. Users will not be guided via a tip for this
specific modal but this is not a problem as this is very straightforward
to understand in the case the user explicitely created multiple blogs
before creating blog posts.
This commit also review commit merged at [2] which made that python test
more robust by not relying on the demo data. That was here improved with
explanations.
However, allowing the tour to go further than the blog post creation for
the user... revealed that the rest of the tour was still blocking the
user. The very next step is to modify the blog post title. That step was
simply not possible to consume. Indeed the tour system asks for a click
event on the title... which is never detected because our old editor
removes all click handlers on that specific top-level editable area. The
cleanest way of fixing that is actually to not wait for a click but wait
that the user actually types text. For this purpose a feature was
introduced in 14.0 with [3] (even if unfortunately, that commit was not
well split). Unfortunately again... that 14.0 feature is currently buggy
during test tours as choosing the "input" consumeEvent alongside the
"text" run method... changes the behavior of that "text" run method when
the affected element is a contenteditable element. That should be fixed
but this will be done in a further update. Meanwhile, this commit
chooses to use the consumeEvent 'mouseup' which circles around both
issues.
[1]: https://github.com/odoo/odoo/commit/bb0cdec4594fab8c22265ed8af0c2d431a263b72
[2]: https://github.com/odoo/odoo/commit/f16f2e212a30352ead86c2f876be02b5c5e23b07
[3]: https://github.com/odoo/odoo/commit/a34cd7c662b3753d630d83793ffcb53b4a0a92d2
Bug revealed by testing task-2728994
closesodoo/odoo#83721
X-original-commit: ca82efe0c7b9a5e98d5c9623b3ae0f1b88fc8091
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Purpose of this commit to add format_type option in daterange
widget.
So, In this add format_type option in nodeoption which convert
actual formatType to given format_type in option and add test
case for that feature.
task:2710539
Closes: #81630
Related: odoo/enterprise#22994
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
** = hr_timesheet,rating,sale_timesheet,sale_project
Purpose of this commit to improve generic UX of project app.
So, In this commit done the following point:
- change the label for 'planned_hours' field in project task form view.
- change demo user access right to project user instead project admin.
- display the rating_status and rating_status_period fields under the 'customer
ratings' feature in the settings.
- add 'project_id', 'mail_template_id', 'rating_template_id' fields in project
task search view.
- add open and closed filter in project search view.
- display 'assign to me' button secondary when user set on task.
- add tooltip for 'date_deadline' field in project form view.
- replace create_date field by write_date in rating views.
- change context of billable time stat button action.
- improve search view of project task.
- hide rating stat btn when satisfaction is 0%.
- change name of task create when SO confirmation.
- change name of project create when SO confirmed when there is only one SO
line contain service_tracking is 'only_project'.
- add id field in tree view of project task as option hide
task-2710539
closes: #81630
When a user clicks on 'could be used in' in the page properties after
chaing the URL, a list is displayed in a popup. This popup was
not properly rendered:
- the content could not be scrolled through, it was thus truncated
- the popup appeared behind the technical modal that kicks in on small
screens
Now the popup is better positioned, a scrollbar is available to access
its content when it is too long and on small screens it is displayed on
top of the technical modal, making it visible on small screens.
task-2092269
closesodoo/odoo#83693
X-original-commit: e2f1f4967a2dd4d730895e924f0c7ca02e23a17b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Jitendra Prajapati <jpr@odoo.com>
Co-authored-by: Benoit Socias <bso@odoo.com>
*: web_editor
Steps to reproduce:
- Activate the cookie dialog from the website settings
- Remove the backdrop from the cookie dialog
- Add some blocks to the cookie dialog in the website editor
until the dialog height is bigger than the page height.
Result:
The cookie dialog is not scrollable, so it's impossible to reach
the "I agree" button and close the dialog, leaving the user stuck
at the first page.
I check if the popup content is higher than the window. If it is, I
give priority to the popup scroll over the page one. I had to
overwrite the _showElement method to call _setScrollbar after
the content rendering, in this way I can get its correct height.
I also try to update the scrollbar each time a block in the cookie bar
has been changed and each time the window resize. This is optimize, so
if the overflow isn't changed from the last time I tried to update the
scrollbar no action will be taken. In this way you can always see the
whole popup without refreshing the page.
Also I have to set 'pointer-events' to none only if the popup is
smaller than the page itself (to interact with and scroll the
page behind), otherwise the popup won't be scrollable. I did
this by adding a class "s_popup_overflow_page" if the popup is
higher than the page and I adapted the pointer-events
property accordingly.
opw-2660786
closesodoo/odoo#83691
X-original-commit: 022a4486a99d855a3c6e2cef326bb3b0c5e66db9
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, it was not possible for a Buckaroo acquirer to
accept asynchronous notifications for payment updates. This is
important because, without them, an acquirer can only rely on
synchronous notifications (i.e. redirect requests from the provider's
checkout page) which can be unreliable and do not allow receiving
status updates, should payments take a bit longer to be confirmed by the
provider.
This commit adds a webhook controller whose route can be configured in
Buckaroo Plaza (backend) to send asynchronous notifications.
task-2687586
closesodoo/odoo#82922
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Co-authored-by: Lucie Van Nieuwenhuyze <luvn@odoo.com>
PURPOSE
Cleanup "Pay Now" notification template and their usage in "Send by email"
flows. Cleanup overall notification by email flow: rename methods, remove
outdated code, improve code clarity, prepare future improvements.
SPECIFICATIONS
Cleanup "Pay Npw" template: move buttons on the top, add subtitle, overall
cleaning of the content. It now looks more like the standard notification layout
with some model-based tweaks for invoices / SOs / POs, with less view-based
content.
Improve recipients computation: do it in batch, add more information when
fetching notification recipients information (follower status, lang, ...). Add tests.
Cleanup MailThread API and docstrings for notification methods. Improve flow
of values through notification methods. Make their purpose clearer.
Provide some master fixes for corner cases spotted while working on this
PR.
In any case see individual commits for more details as otherwise this message
would be a long concatenation of various purposes.
LINKS
Task-2712450 (Mail/Sale: Improve 'Pay Now' notification template)
Task-2726501 (Mail: Propagate message values in post methods)
Task-2732660 (Mail: Remove duplicate layout field on composer)
Task-2710804 (Mail: Clean Mail.Thread API)
Task-2739294 (Mail: Batch recipients fetch and improve its usage)
closesodoo/odoo#82167
Related: odoo/enterprise#23326
Related: odoo/upgrade#3142
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
PURPOSE
Allow to somehow decorate notification emails headers with a subtitle holding
the record name and some main informations.
SPECIFICATIONS
Next to access button in "Pay Now" notification email, display a subtitle
for some of the main "Send by email" based email flows. It should be something
like 'Invoice REF/01 \n35€ due 11/2022' for account.move or equivalent for
sale.order models.
Task-2712450 (Mail/Sale: Improve 'Pay Now' notification template)
Part-of: odoo/odoo#82167
When creating a new user, add a default signature if none is given. It
should be a simple one like
```
--
<user_name>
```
Implement it using an editable computed field based on name. That way users
can set it explicitly as void, but changing user's name sets a default one
when it is not set.
Task-2712450 (Mail/Sale: Improve 'Pay Now' notification template)
Part-of: odoo/odoo#82167
In this commit we get the old "Pay Now" behavior back that gives a standard
link to followers. It is done manually on sale order as it implements portal
rules. Follower group for notification layout is therefore activated.
Task-2712450 (Mail/Sale: Improve 'Pay Now' notification template)
Part-of: odoo/odoo#82167
Purpose of this commit is to add potential groups but de-activate them by
default. Indeed each group require about 20 queries for rendering and
sending. If no specific behavior (access button, content) is made for this
recipient group it can be included in lower-version of the group.
Specifications
* de-activate portal group in mail as it has no additional rights compared
to customers;
* add follower group but de-activate it for the same reason;
* activate portal group in portal_mixin and include links to the record in
notification emails, using standard mail/view link. ACLs are managed in
each specific model, generally based on followers;
Update a test in test_mail as it was playing with public and portal users
that are now not really differentiated when sending notification emails.
Better have more real-life scenarios with portal and internal users.
Task-2739294 (Mail: Batch recipients fetch and improve its usage)
Part-of: odoo/odoo#82167
Purpose of this commit is to improve notification recipients computation.
Code cleaning
* make it batch enabled. Currently it works only for a single record. It
should evolve towards real multi computation, allowing to prepare post
and notification in batch;
* better manage multi users. Now when several users are linked to the same
partner, we try to find an internal user or fallback on share user. This
is cleaned compared to a distinct done previously;
* support recipients without subtype (pids + records) as a new case to
include follower computation;
Improvements
* include follower status if linked to records (is_follower can be used
notably in link computation to redirect to the portal);
* fetch partner lang directly in the SQL query. While fetching partner data
let us add its lang. That way it will be easier to improve lang support
in layouts;
Task-2739294 (Mail: Batch recipients fetch and improve its usage)
Part-of: odoo/odoo#82167
Add a constraint directly at db level ensuring no duplicated notification
exist on partner / message pair, if partner is set. Partner can be void notably
with SMS notification process which may target numbers directly.
Task-2710804 (Mail: Clean Mail.Thread API)
Part-of: odoo/odoo#82167
Purpose is to have a white background like templates used in SO, invoices, ...
Task-2712450 (Mail/Sale: Improve 'Pay Now' notification template)
Part-of: odoo/odoo#82167
Purpose is to remove custom styling and use the 'Pay Now' notification layout.
Extra table is removed from template body (table with order name, 'sent by'
footer, ...) and only main content is kept. Some extra padding is removed.
Action now uses the 'Pay Now' email layout to add the access button, company
logo, footer, ... meaning it is now more standard.
An override of recipient groups and access button is also performed in order
to align header with email purpose. Link redirects to the /cart page (instead
of classic portal SO view for customers) and is labelled as 'Resume order'
(instead of 'Validate and Pay Order' used in portal).
Task-2712450 (Mail/Sale: Improve 'Pay Now' notification template)
Part-of: odoo/odoo#82167
* = sale, purchase
PURPOSE
Purpose of this commit is to improve the 'Pay Now' notification template
used notably when using the "Send by email" button on
* invoices
* sale orders
* RFQ and purchase orders
SPECIFICATIONS
Global specifications
* remove gray background that is around the white content (aka have an
email with an uniform white background);
* move button on top of email like other notification templates (top-left
and company logo is top-right);
* fix various small wording issues;
* fix signature usage;
Technical specifications
Remove custom definition of access links and labels in 'Pay Now' notification
template (``mail_notification_paynow``). It is now done at model level through
the ``_notify_get_groups`` that is generic to notification emails. This allows
to remove QWeb override in purchase and sale notably. Displaying access links
is now controller by the ``has_button_access`` value. Model computes links,
access and labels while view only displays what is requested. That way any
template can use those values instead of being defined in a template subject
to user changes.
Sale / Purchase
Overrides of those modules is not necessary anymore since button labelling
and URLs are managed at model level.
Purchase "specific" buttons for Accept / Update dates are now email layout
actions, like used in other modules like HR or Project.
Continuation of odoo/odoo#76418 .
Task-2712450 (Mail/Sale: Improve 'Pay Now' notification template)
Part-of: odoo/odoo#82167
This field is a duplicate of email_layout_xmlid and is actually never used.
Followup of odoo/odoo#76418 .
Task-2732660 (Mail: Remove duplicate layout field on composer)
Part-of: odoo/odoo#82167
* = account, purchase, sale
Purpose of this commit is to add signature only if really asked. A variable
is available for that purpose (``email_add_signature``, recently renamed from
``add_sign``). We also correctly check signature is not void or pseudo-void
using tool ``is_html_empty``. Indeed editor may generates pseudo-void content
like ``<p><br /></p>``.
As signature is not added when a template is used (see composer code) we ensure
it is defined in mail templates used in "Send by email" flows. Indeed we cannot
know if a template already has a signature or not. To avoid having twice a
signature no signature is added in email notification layout when a template
is involved.
Continuation of odoo/odoo#76418 .
Task-2712450 (Mail/Sale: Improve 'Pay Now' notification template)
Part-of: odoo/odoo#82167
In order to make fields a bit more explicit, let us rename "add_sign" to
"email_add_signature". It indicates it is linked to the email notification
process, adding the signature depending on the notification layout itself.
This is done on both mail.message and mail.compose.message models. It is
also updated as rendering value parameter used in notification emails.
Task-2712450 (Mail/Sale: Improve 'Pay Now' notification template)
Part-of: odoo/odoo#82167
Purpose of this commit is to make ``get_access_action`` private as it is not
necessary to expose it directly. Website management is also made explicit
using a ``force_website`` parameter instead of relying on context key of the
same name. This allows to better understand the method code flow.
Contains also some code fix / improvements :
* Website forum: update code to better skip the frontend redirection if the
forum is not active and frontend is not forced;
* Website slides: respect force website parameter in redirection;
Task-2710804 (Mail: Clean Mail.Thread API)
Part-of: odoo/odoo#82167
A method that actually runs on recordsets should not have a model decorator.
Even if there is no issue this is may be confusing.
Task-2710804 (Mail: Clean Mail.Thread API)
Part-of: odoo/odoo#82167
Purpose is to support portal parameters in ``_notify_get_action_link``. This
method generates a ``mail/view`` link that may redirect to frontend e.g. with
portal. We already support parameters coming from auth_signup and tokens from
portal. Supporting pid / hash allowing to post on documents using the frontend
chatter is the next step to generic links. This is just adding them to the
accepted like, not changing any current behavior.
Task-2712450 (Mail/Sale: Improve 'Pay Now' notification template)
Part-of: odoo/odoo#82167
If we call ``MailFollowers._get_recipient_data()`` with pids parameter being
set to None there is a crash that is easily solved( list(None), should take
list fallback before hand).
Task-2739294 (Mail: Batch recipients fetch and improve its usage)
Part-of: odoo/odoo#82167
stefanorigano (SRI)