Purpose of this commit is to better include SMS notifications when posting a
message. SMS is now just another way of notifying people along with Inbox and
email. Following recent mail merge improving notification mechanism [1] we
have to define a _notify_record_by_sms method on mail.thread.
When a message_post is done using message_type being ``sms`` notification type
of customers is set to sms. Customers can be computed on model (generally based
on partner_id field) or directly set usign partner°ids. Notification model is
updated to store this information directly inside the notification itself.
An new ``_message_sms`` helper method is introduced in SMS module allowing
to send messages using sms type and notification with a reduced parameters
number. It is just a shortcut to message_post, easier to use. Either it
computes default recipients on the record set, either it is based on given
partners and numbers to notify.
The following use cases are notably supported
* default computation: find customer, notify by sms;
* force recipients to notify by sms (partner_ids);
* give a set of numbers to notify by sms (sms_nubmers), not necessarily
linked to existing partners;
* force number / customer relationship independently of mobile number defined
on customer (for example when sending an SMS directly from a mobile field
on a lead linked to a customer);
Tests are updated accordingly. Performance tests are added in order to have
some insights on queries generated when sending SMS, like already done for
mail.thread alone.
Related to task 1922163
Linked to PR #33510
[1] see be27955136: performance and notification code improvements
Co-Authored-By: Thibault Delavallee <tde@odoo.com>
Co-Authored-By: Pierre Rousseau <pro@odoo.com>
This commit prepares SMS refactoring by updating some mail models. Purpose
is to be able to store SMS notification information inside existing mail
flow and models.
Main changes
* mail.notification: define a notification_type field to store the medium
used to notify people. In mail two ways exist: inbox and email. It will
ease introduction of SMS notification mechanism. This field replaces the
is_email boolean field;
* mail.notification: make res_partner_id field not required. This means
notifications could be linked to something else than a partner. An SMS
for example. For Inbox and email notifications partner is still required
and a constraint is added accordingly;
* mail.thread: let notification methods handle the creation and update of
their notification instead of creating them in _notify_thread and tweaking
them in sub notification methods;
* mail.thread: clearly move inbox-style notification in its own method like
notify by email;
Some lighter code changes
* propagate message_type to notification recipient computation. It will
allow for example to be more precise when computing a notification type
depending on the message_type. For example, send a notification by SMS
when the message_type is SMS;
* ease inheritance of ``_notify_thread`` by returning computed recipients
data. It will allow to work on it without having to re-compute it;
* propagate kwargs from message_post and message_notify to notify methods.
This allow to avoid depending on context and set explicit parameters.
Drawback is that message_post and notify must separate kwargs used to
create a message and those that are propagated to notification methods;
* update various notification check to ensure they work on email
notifications, notably the resend and cancel wizards;
One side effect of this commit is that notifications are created by the
relevant notification method. Previously all notifications were created
by writing on needaction_partner_ids fields then updated according to the
notification process. Notably there could be too much notification created
when sending emails due to _notify_customize_recipients not being correctly
synchronized with notification. This issue is now solved as only really
sent emails create notifications.
Migration tips
* notification_type: notification.is_email and 'email' else 'inbox';
* remove is_email;
Related to task 1922163
Linked to PR #33510
Usecase to reproduce:
- Connect on demo user (inventory user)
- Go on product page and click on stat button for 'quantity on hand'
> AccessError on decimal.precision object
due to commit a1eb000c93
When the user click on 'report inventory' button it will garbage
collect the remaining quants without quantity. In order to do it,
it needs the precision rounding in order to have a rounding and do
not let quant without significant quantity.
closesodoo/odoo#34780
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Usability improvement because when the user click on inventory
report it's mainly in order to edit/check its current stock since
commit da33eb36b8
This change redirect the user directly on stock.quant tree view
and add an inventory at date button in the control panel. This
button will open the same wizard than previously and ask for a
date. The same principle is used for valuation layer.
Co-authored-by: svs-odoo <svs@odoo.com>
Task: 1880379
This commit introduces back the value by location feature dropped in v11.
The feature was dropped because we implement financial fifo, thus the
value by location does not make sense for this cost method.
This commit introduces an estimation of the value by location in fifo.
Task: 1880379
Purpose
=======
While cleaning the stat buttons across all modules, we decided
to move the (un)archiving from stat button to actions in the
'Action' dropdown.
The goal was to lighten the content of oe_button_boxes by clearing
out stat buttons.
The general idea is that stat buttons should be a redirection,
either to a set of records or to an alternate view of the current
one (there are some exceptions though).
The toggle_active stat button is an action, quite similar to a
deletion in most cases.
There are two main ways of using the 'active' field:
- archiving a record (often because it cannot be deleted since it
is linked to another record, like a res.partner used in validated
account.invoices)
- activating a record (with configuration objects like currencies,
languages, or taxes)
In the first case, the option is advanced, akin to deletion. Just
like deletion, its place is in the action dropdown, not the
formview itself.
It is nevertheless important to inform the user whether the record
is archived, but it is not necessary to inform him when it isn't.
In the second case (much less common), the 'activation' of a record
can simply be made available by adding the active field directly in
the formview.
Specification
=============
1/ web: Always display (un)archive buttons in Action on form views
Purpose
-------
While cleaning the stat buttons across all modules, we decided to move
the (un)archiving from stat button to actions in the 'Action' dropdown.
Specification
-------------
If the record has an 'active' field, display an action 'Archive' in the
2/ all: Remove active stat button on all views
Purpose
-------
While cleaning the stat buttons across all modules, we
decided to move the (un)archiving from stat button to
actions in the 'Action' dropdown.
Specification
-------------
Remove the 'active' stat buttons in all views
3/ web: Call 'toggle_active' instead of 'write'
Purpose
-------
Currently when clicking on 'Archive' or 'Unarchive' on the list view,
we write directly on the record {'active': False}, instead of calling
toggle_active. Missing that way implementation of numerous business cases.
Example
- Archive a record --> archive its next activities
- (Un)Archive a user --> (Un)Archive its partner
- (Un)Archive a product variant --> (Un)Archive its template if
there is only one variant
- Archive an employee --> Open a wizard to choose an exit plan + describe
the departure reason
- Archive a route --> Archive its procurement rules
- ...
Specification
-------------
- Call toggle_active instead of write when calling toggleActive in the web
client.
- On the other hand, use actionArchive and actionUnarchive to apply the
toggle action on the related records only.
4/ web: Remove toggle_button widget
This widget is not used anymore, as all the stat buttons have been removed
from the views.
5/ base,mail,...: Redisplay active field in some views
Purpose
-------
In the following views, add the 'active' field in the formview
as specified in the screenshots:
account.view_tax_form (account.tax) https://nimb.ws/08WqXP
crm_iap_lead_website.crm_reveal_rule_form (crm.reveal.rule) https://nimb.ws/xPHSiT
delivery.view_delivery_carrier_form (delivery.carrier) https://nimb.ws/yq3eDS
base.view_rule_form (ir.rule) https://nimb.ws/MBi2Ix
lunch.lunch_alert_view_form (lunch.alert) https://nimb.ws/DRdK4Z
mail.mail_blacklist_view_form (mail.blacklist) https://nimb.ws/xBq9ut
base.view_currency_form (res.currency) https://nimb.ws/FXG9oA
base.res_lang_form (res.lang) https://nimb.ws/eSr0dM
6/ web: add a new ribbon widget (POC)
Purpose
-------
The ribbon widget adds a ribbon on the top right of a form
to make some status more visible.
You have to specify the text attribute to show the text on
the ribbon. You can also specify a bg_color attribute to
color the background with a bootstrap background color class.
Note: This is an ugly draft of the final widget, that is supposed
to land in master in a few days. As this PR brings a lot of
functional changes in several files, it has become quite difficult
to maintain it over the days.
The final responsive version will come with:
https://www.odoo.com/web#id=2032621&action=333&active_id=965&model=project.task&view_type=form&menu_id=4720
7/ base,mail,...: Add ribbon widget everywhere on archived records
Purpose
-------
In the following views, add a bg-danger ribbon with label 'Archived'
only visible when active=False:
account.account_tag_view_form (account.account.tag)
analytic.view_account_analytic_account_form (account.analytic.account)
analytic.account_analytic_tag_form_view (account.analytic.tag)
account_asset.view_account_asset_form (account.asset)
account.view_account_position_form (account.fiscal.position)
account.account_incoterms_form (account.incoterms)
account.view_account_journal_form (account.journal)
account.view_payment_term_form (account.payment.term)
website_blog.view_blog_blog_form (blog.blog)
website_blog.view_blog_post_form (blog.post)
calendar.view_calendar_event_form (calendar.event)
crm.crm_case_form_view_leads (crm.lead)
crm.crm_case_form_view_oppor (crm.lead)
crm.crm_lost_reason_view_form (crm.lost.reason)
sales_team.crm_team_view_form (crm.team)
documents.document_view_form (documents.document)
event.view_event_form (event.event)
website_event_track.view_event_track_form (event.track)
fleet.fleet_vehicle_view_form (fleet.vehicle)
fleet.fleet_vehicle_log_contract_view_form (fleet.vehicle.log.contract)
website_forum.view_forum_forum_form (forum.forum)
website_forum.view_forum_post_form (forum.post)
gamification.badge_form_view (gamification.badge)
helpdesk.helpdesk_sla_view_form (helpdesk.sla)
helpdesk.helpdesk_team_view_form (helpdesk.team)
helpdesk.helpdesk_ticket_view_form (helpdesk.ticket)
hr_recruitment.hr_applicant_view_form (hr.applicant)
hr_appraisal.view_hr_appraisal_form (hr.appraisal)
hr_contract.hr_contract_view_form (hr.contract)
hr.view_department_form (hr.department)
hr.view_employee_form (hr.employee)
hr.hr_employee_public_view_form (hr.employee.public)
hr_holidays.edit_holiday_status_form (hr.leave.type)
hr.hr_plan_view_form (hr.plan)
hr_payroll.hr_salary_rule_form (hr.salary.rule)
hr_work_entry.hr_work_entry_type_view_form (hr.work.entry.type)
lunch.lunch_product_view_form (lunch.product)
lunch.lunch_supplier_view_form (lunch.supplier)
mail.mail_activity_type_view_form (mail.activity.type)
mass_mailing.view_mail_mass_mailing_form (mail.mass_mailing)
mass_mailing.view_mail_mass_mailing_list_form (mail.mass_mailing.list)
maintenance.hr_equipment_view_form (maintenance.equipment)
maintenance.maintenance_team_view_form (maintenance.team)
marketing_automation.marketing_campaign_view_form (marketing.campaign)
mrp.mrp_bom_form_view (mrp.bom)
mrp_plm.mrp_eco_view_form (mrp.eco)
mrp.mrp_routing_form_view (mrp.routing)
mrp.mrp_workcenter_view (mrp.workcenter)
point_of_sale.pos_config_view_form (pos.config)
product.product_pricelist_view (product.pricelist)
hr_expense.product_product_expense_form_view (product.product)
product.product_variant_easy_edit_view (product.product)
stock_landed_costs.view_stock_landed_cost_type_form (product.product)
product.product_template_form_view (product.template)
project_forecast.project_forecast_view_form (project.forecast)
project.edit_project (project.project)
project.view_task_form2 (project.task)
industry_fsm_report.project_worksheet_template_view_form (project.worksheet.template)
quality.quality_point_view_form (quality.point)
base.view_res_bank_form (res.bank)
base.view_partner_form (res.partner)
base.view_users_form (res.users)
sale_coupon.sale_coupon_program_view_form_common (sale.coupon.program)
sale_management.sale_order_template_view_form (sale.order.template)
sale_subscription.sale_subscription_alert_view_form (sale.subscription.alert)
sale_subscription.sale_subscription_template_view_form (sale.subscription.template)
sign.sign_request_view_form (sign.request)
sign.sign_template_view_form (sign.template)
website_slides.view_slide_channel_form (slide.channel)
website_slides.view_slide_slide_form (slide.slide)
stock.view_location_form (stock.location)
stock.stock_location_route_form_view (stock.location.route)
stock.view_picking_type_form (stock.picking.type)
stock.view_stock_rule_form (stock.rule)
stock.view_warehouse (stock.warehouse)
stock.view_warehouse_orderpoint_form (stock.warehouse.orderpoint)
survey.survey_form (survey.survey)
website_crm_score.view_crm_score_form (website.crm.score)
website_twitter_wall.website_twitter_wall_view_form (website.twitter.wall)
8/ hr: Fix departure wizard activity generation
Purpose
-------
If the fired employee has no access to the hr.employee model,
the departure wizard will lead to a traceback, as we try to
create an activity on a model for which the user won't be able
to resolve it.
Create an activity on the related partner instead.
9/ web: Make archive:unarchive buttons manage returned actions
Purpose
-------
When calling toggle_active, you may sometimes retrieve an action to
execute. For example, when archiving an employee, it opens a wizard
to provide information about the departure, and choose an offboarding
plan.
This commit modifies the way toggleActive, actionArchive and
actionUnarchive works to manage this behavior.
TaskID: 2030440
closesodoo/odoo#34496
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
When calling toggle_active, you may sometimes retrieve an action to
execute. For example, when archiving an employee, it opens a wizard
to provide information about the departure, and choose an offboarding
plan.
This commit modifies the way toggleActive, actionArchive and
actionUnarchive works to manage this behavior.
Purpose
=======
If the fired employee has no access to the hr.employee model,
the departure wizard will lead to a traceback, as we try to
create an activity on a model for which the user won't be able
to resolve it.
Create an activity on the related partner instead.
Purpose
=======
The ribbon widget adds a ribbon on the top right of a form
to make some status more visible.
You have to specify the text attribute to show the text on
the ribbon. You can also specify a bg_color attribute to
color the background with a bootstrap background color class.
Note: This is an ugly draft of the final widget, that is supposed
to land in master in a few days. As this PR brings a lot of
functional changes in several files, it has become quite difficult
to maintain it over the days.
The final responsive version will come with:
https://www.odoo.com/web#id=2032621&action=333&active_id=965&model=project.task&view_type=form&menu_id=4720
Purpose
=======
Currently when clicking on 'Archive' or 'Unarchive' on the list view,
we write directly on the record {'active': False}, instead of calling
toggle_active. Missing that way implementation of numerous business cases.
Example
- Archive a record --> archive its next activities
- (Un)Archive a user --> (Un)Archive its partner
- (Un)Archive a product variant --> (Un)Archive its template if
there is only one variant
- Archive an employee --> Open a wizard to choose an exit plan + describe
the departure reason
- Archive a route --> Archive its procurement rules
- ...
Specification
=============
- Call toggle_active instead of write when calling toggleActive in the web
client.
- On the other hand, use actionArchive and actionUnarchive to apply the
toggle action on the related records only.
Purpose
=======
While cleaning the stat buttons across all modules, we
decided to move the (un)archiving from stat button to
actions in the 'Action' dropdown.
Specification
=============
Remove the 'active' stat buttons in all views
Purpose
=======
While cleaning the stat buttons across all modules, we decided to move
the (un)archiving from stat button to actions in the 'Action' dropdown.
Specification
=============
If the record has an 'active' field, display an action 'Archive' in the
dropdown if the record is active, else display an action 'Unarchive'.
The 'Archive' action should ask to the user if he's sure he wants to
make this action.
Future runbot improvement may share sources between build,
meaning that sources will be readonly to avoid any interaction.
_touch() was supposed to handle ro filesystem but
f7130556 introduced a new test that was not working
in this case.
Instead of trying to touch file and pseudomocking the result
if the filesystem is readonly, this commit add a real patch
on getmtime.
cherry-pick of b295723c99closesodoo/odoo#34823
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Make use of the new tax model to suppress 'adjustment' type for taxes, and refactor the generic adjustment
wizard so that it direcly sets tags on the account move lines generated instead of needing an tax.
[IMP] l10n_be: remove taxes of type 'adjustment'
closesodoo/odoo#33669
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Future runbot improvement may share sources between build,
meaning that sources will be readonly to avoid any interaction.
_touch() was supposed to handle ro filesystem but
f7130556 introduced a new test that was not working
in this case.
Instead of trying to touch file and pseudomocking the result
if the filesystem is readonly, this commit add a real patch
on getmtime.
cherry pick of b295723c99closesodoo/odoo#34815
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Future runbot improvement may share sources between build,
meaning that sources will be readonly to avoid any interaction.
_touch() was supposed to handle ro filesystem but
f7130556 introduced a new test that was not working
in this case.
Instead of trying to touch file and pseudomocking the result
if the filesystem is readonly, this commit add a real patch
on getmtime.
cherry-pick of b295723c99closesodoo/odoo#34816
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
An use a model translation
The message is now stored on the ir.model.constraint record
Create external id for ir.model.constraint
In the future, _constraint will be removed so a second cleanup will occur
Task-id: 1999315
Pad: https://pad.odoo.com/p/r.2e88f9120528b70db08ad7d727ab7cccclosesodoo/odoo#33522
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Store the SQL constraint message directly in the field `message` of the
corresponding `ir.model.constraint` record, and manage translations from
there. Those records are given an XML id in order to be tracked in PO
files. The translation type 'sql_constraint` is removed.
Let's assume a one2many field (editable list) in a form view with
a many2many (e.g. many2many_tags), and an onchange on the one2many
such that, when a row is added to the relation, the server returns
update commands for (a subset of) the records being already in the
relation. For thoses updated records, the many2many field needs to
be read (the onchange only returns the ids in the relation).
Before this rev., the many2many field was read independently for
each record in the one2many. This could cause a performance issue
on large relations. For instance, this was the case on
account.invoice records with a lot of lines.
Issue 2027356
closesodoo/odoo#34785
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Since commit 9fbb4fb, the `title` attribute is added
to list views `<td>`. The title value is given
by field utils formatting methods, according to the
field type. However, for boolean fields, the formatting
method does not return a string but a jquery element
(unless `forceString: true` is given as an option).
Hence, the displayed title is `[Object object]`.
After this commit, boolean fields do not have any title.
closesodoo/odoo#34657
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit replaces the usage of `formData.delete()` as it is not supported
by Internet Explorer and Safari Mobile.
closesodoo/odoo#34787
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Some leftovers of
https://github.com/odoo/odoo/commit/beaa30a3d1843de43a45f419bfbc1bfa7613a920.
Fields have been renamed according to the following mapping:
residual_signed -> amount_residual_signed
reference -> ref
State 'open' does not exist anymore, use 'posted' and combine it with
'invoice_payment_state' instead.
When answering a quiz, the button "Check your answers"
is not displayed when not in fullscreen.
JS error: `def.resolve is not a function`
because an already instantiated Promise does not have a
resolve function.
A promise cannot be resolved from outside its callback scope.
closesodoo/odoo#34762
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, if we had a livechat channel with a user and:
- in backend use command "/leave" to leave and unpin conversation
- [do not reload the page (or there is no issue)]
- then the user sends a new message
The chat window opens just with the new message. Fetched previous
messages are ignored due to being already in the mail manager, and
links between these messages and the threads were never updated.
With this commit, when fetching messages that are already in the mail
manager, these messages are linked again to threads.
This commit also fixes an issue in which messages moderated with
status "accepted" were not correctly removed from the moderation
mailbox. This problem occurred after the fix on re-linking messages
to threads.
opw-2031270
closes#34761
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
- When creating a vendor on lunch without setting explicitly the
`responsible_id`, `default_get` should return the current user id.
Instead it returns the current user's partner id.
closesodoo/odoo#34759
Signed-off-by: Nicolas Seinlet (nse) <nse@odoo.com>
Go to the database manager, configure a password either via the
interface either via the `admin_passwd` `.odoorc` config file. Click on
the backup menu, let the `password` field empty and submit the form. The
modal is closed without any warning and no query is sent.
The problem is that even if the field is marked as `required`, there is
a event listener that catch the `onsubmit` event and close the modal
even if it is not valid.
opw-2031461
closesodoo/odoo#34669
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Setup a multi-company account and multiple website (one for each
company), create a mail campaign from a different company than the
superuser, send the emails and unsubscribe, the company logo is the logo
of the company the superuser is in instead of the logo of the company
sending the email.
opw-2026528
closesodoo/odoo#34701
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Before this commit, when a direct message chat was renamed, it
crashed with the following error:
`TypeError: Cannot read property 'toLowerCase' of undefined`
This occurs because the name of the dm chat changed from the RPC
response. However, no new name was provided, thus it sets its
name to `undefined`.
Test has been adapted in order to reflect that the server does not
response with new name after RPC `channel_set_custom_name`.
closesodoo/odoo#34641
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
The patch fa492d87f4 has been backported
from Odoo 12.0, that runs on Python 3.
The string '\n\n({} {}, {} {})' to be formatted is a byte-string in
Python 2, while the return value of _() is always a unicode-string.
As format() is (too?) nice, it attempts to convert the unicode-strings
into ascii in order to inject them in the format pattern.
With some languages that are written in ascii, this works -- by chance.
When you use non-ascii languages like Japanese, it fails.
We then fix that issue by using unicode-strings in the formatting
pattern.
#OneCharacterPatch B-)
opw-2032016
-----------------------------
For full technical understanding:
Python 2.7.16 (default, Mar 11 2019, 18:59:25)
[GCC 8.2.1 20181127] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> '{}'.format('test')
'test'
>>> '{}'.format(u'test')
'test'
>>> '{}'.format(u'エ')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode character u'\u30a8' in position 0: ordinal not in range(128)
>>> u'{}'.format(u'エ')
u'\u30a8'
closesodoo/odoo#34698
Signed-off-by: Richard Mathot (rim) <rim@openerp.com>
Removed classes "default-label" and "label" as they weren't required and
were giving a bad look to tag.
Task-2031724
closesodoo/odoo#34647
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Steps to reproduce the bug:
- Create two companies C1 and C2 where C2 is the child of C1
- Create two purchase taxes T1 and T2 where T1 is in C1 and C2 is in T2
- Create a prodcuct P with T1 and T2 as supplier taxes
- Be in C1 as current company
- Create a RFQ and add P
Bug:
T1 and T2 were set on the order line of P instead of T1
PS: This fix is insired from product_id_change in model sale.order.line
opw:2032113
closesodoo/odoo#34658
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
