This commit updates the parameters passed to the IAP SMS API route
("/api/sms/3/send") to include the DB UUID.
closesodoo/odoo#159714
Task: 3829793
Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>
When sending an SMS via the action from the sale order view
(specifically with sale_subscription), it is possible to specify a
number to send the SMS to. However, if the specified number
is identical to the partner's number (the number of the sale order's customer),
Odoo attempts to send the message twice, resulting in duplication.
[This commit change]
This commit addresses this issue by ensuring that additional numbers
are skipped if they are the same as the partner's number.
[Reproduce]
- Install mass_mailing_sms, sale_management, and sale_subscription modules.
- Add an SMS token to the IAP account.
- Create a contact (C) with a valid phone number.
- Create a new quotation with contact (C) as the partner.
- Go to Actions > "Send an SMS Text Message" (requires the sale_subscription module).
- Do not change the contact number on the pop-up (ensure it matches C's phone number exactly).
- Bug: Odoo attempts to send two SMS messages, with the first being successful and the second resulting in an error.
opw-3596207
closesodoo/odoo#159677
X-original-commit: 131b0eccb00d24f0525a6a541221bfd2c66cb04b
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
*: account_edi, hr_work_entry_contract, l10n_ch, l10n_latam_check,
mail_bot_hr, sale, sms, survey, website_slides, pos_online_payment
This commit follows the margin variable introduced in the
`form_controller.scss` file. It removes the margin customizations
applied on the alerts which are rendered above a form sheet to let the
CSS rule handle the spacing.
task-3577058
closesodoo/odoo#156927
Related: odoo/enterprise#58282
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
For a first iteration, Russian translations were done using DeepL using
1 large .pot file of all the standard modules to translate (e.g. no
localizations, no test modules, etc). Unfortunately for some reason
doing a msgmerge with the existing ru.po files didn't seem to work, so
old "Translators" metadata at top of files were lost (maybe they will be
re-added during next Transifex sync?)
Part-of: odoo/odoo#152285
When a 'scheduled_date' is given to posting API notifications are delayed.
They are send using a cron running on a schedule model. However SMS are
not respecting this parameter. This is now fixed.
We also use sql.now() instead of datetime.now() when checking notification
delay. This leads to values that are consistent through the transaction
and avoid non deterministic behavior.
This leads to fixing a global mock of "cr.now" that has unexpected side
effects in composer tests. Indeed now that the scheduled notification checks
cursor now instead of datetime now this global mock leads to some notification
not being sent. We now mock cr.now() only for creating records, allowing
to effectively test templates using create_date for dynamic scheduled date
computation.
closesodoo/odoo#150911
Related: odoo/enterprise#55052
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
do not compare types, for exact checks use `is` / `is not`,
for instance checks use `isinstance()`Flake8(E721)
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Steps:
- Open field service
- Go to Calendar view
- Click on any data, so that the popover opens.
- Click on the SMS button to send a message.
Issue:
- When we try to send the message, the traceback comes with the message
'Component is destroyed'.
Cause:
- When we try to send the message using 'Send SMS', before that the popover
opened gets destroyed. The popover and wizard are different 2 components and
hence we aren't able to control them.
Fix:
- We are performing load and notify methods only if the status of the component
is not destroyed.
task-3386925
closesodoo/odoo#144255
X-original-commit: 49b5054d0d530c3935cf053ae994dbebc12f1e04
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Since commit 550595d, it's no longer necessary to change the endpoint to
the IAP services test server.
closesodoo/odoo#141930
X-original-commit: 16a649231fcf98f2b3bae9e297ea892b9c93e3f9
Signed-off-by: Florian Daloze (fda) <fda@odoo.com>
Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>
Currently both incoming and outgoing emails are using the same 'email'
message_type. However both flows are not linked in any way.
Purpose of 'message_type' is to distinguish who generated the message.
In this case incoming emails are generated by the mailgateway while outgoing
emails are generated by mailins e.g. using the composer in mailing mode.
We now distinguish outgoing emails from incoming emails by using a specific
type for outgoing emails. Addons are updated accordingly.
Default 'message_type' value when removing sms/snailmail/whatsapp is now
'comment' instead of 'email', as default value of messages should be
comment as discuss is the main source of messages.
Task-3285720
closesodoo/odoo#139814
Related: odoo/enterprise#49597
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Commit b05e7e4da0 rightfully removed the _compute_name dependency on
context keys (a bad idea for stored computed fields), but this change
could lead to UX frustrations (Server Action names getting reset all the
time despite what the user may have used as a name before) and UX issues
(e.g. triggering a recompute by accident at module removal that could
reset all 'code' action names to 'Execute Code').
This commit simply removes the automated naming feature from the base
module and moves the logic to the base_automation module - and only
computes automated names based on the link with an automation rule or
not (so 'standalone' server actions need a name given by the user at all
times).
Task-3450200
Part-of: odoo/odoo#138804
- Slight reword of the 'type/state' field labels for server actions
- Re-ordering of 'type/state' values
- Form view changes
- Allow hiding model in display_name of ir.model.fields base on context
key (avoid technical details when they are not needed)
Task-3450200
Part-of: odoo/odoo#138804
Also impacts test_mail_sms.
Purpose: let a cron do delete records to end the
sending transaction sooner.
Removing the foreign key between sms_sms and mailing_trace
is necessary as traces may have to be updated due to
delivery reports.
This is why we do it here and not with notifications
because only traces will trigger updates of a possibly
massive number of records and repeated concurrent updates.
We also replace the now obsolete "sms_sms_X" prefix as there
are not many "sms_id" to distinguish from.
Task-2560666
Part-of: odoo/odoo#133392
Also impacts mass_mailing_sms, test_mail_sms,
test_mass_mailing
This PR adds support to receive sms delivery reports.
Before this PR, an SMS was considered 'sent' when successfully
handled by the third party. The user couldn't know if/when an
SMS was actually sent for delivery or delivered to the
recipient's device.
This was similar to the behavior for emails as delivery reports
are not commonly used (and not supported in Odoo).
With this work, the SMS `pending` state is introduced in mail,
mass_mailing, sms and mass_mailing_sms contexts although only fully
used in the latter two modules (+tests of course).
Because of the huge cost related to upgrading very large existing
databases, the following compromises were made:
1. An email and sms notification/trace SENT means DELIVERED.
Those that are sent but NOT DELIVERED are PENDING.
The difference between email and sms traces reinforced with this PR
is that an email sent will be counted as "sent" ~ "delivered"
unless an error is returned for emails while for SMS it can only be
reached if a delivery report is received.
2. The Link between an SMS uuid (shared with trusted parties) and
the tracking records (notifications or traces) is done via an
explicit relationship table (sms_tracker) instead of via a new field.
This however allowed to nicely concentrate the state update logic.
A `process` state is added to represent an intermediate
step in the sending process, such as held at IAP for SMS.
A few adjustments are also included to update for IAP api v3.
Also, adapts and includes new tests.
Task-2560666
Part-of: odoo/odoo#133392
Name was hard to grasp what it means, when in practice it refers to
showing discuss failures in messaging menu. The "group" part just
refers to a failure being conceptually uniquely defined so that it
sometimes group notifications together as a single failure entry
in the messaging menu.
This rename will help simplifying insert flow with this model.
[REF] mail: slightly simplify Notification.insert()
Format `persona` so it can be immediately inserted in JS model.
[REF] mail: simply Notification/Failure.insert
[REF] mail: introduce computed fields on discuss models
Some models have no concept in server, so the formatted data require
specific handling to make some client-side specific models. This is
notably the case with `Failure` model, which is used to group
failure notifications per model for the specific showing in UI.
In order to simplify update so they consists to simply adding data
from server, these models should be inserted automatically depending
on changes from inserted data. Since these models come from
relational fields that must be computed outside of server data, we
add support to computed fields: such relational fields can have their
value automatically computed based on the state of the current
record.
[REF] mail: remove Record.atomically and Record.onChange
These were added to reactive seeing intermediate state in models,
which were caused by `RecordList.sort()`.
This commit removes them and adapt specifically `RecordList.sort()`
so intermediate states during sort is not exposed in the actual
value of the many field.
Part-of: odoo/odoo#138760
The aim of this commit is to improve the impact and rendering of app
icons in bright and dark mode. It also reduces the size of svg files.
To achieve that, this commit updates the colors to flat colors. This
change will make the icons stand out and improve their readability.
task-3072562
X-original-commit: 667a19162b74fb6554a2389ba9c6e69de4ff5113
Part-of: odoo/odoo#138279
Replace all the calls to get_resource_path to the better file_path or
directly use file_open when not needed
Doing both a get_resource_path and file_open means checking twice that
the file exists.
Doing a simple path concatenation before a file_open is safe.
If given to another method (e.g. etree.parse), calling file_path is
the prefered method.
Note that get_resource_path used to return False when the file does
not exists while file_path/file_open raises a FileNotFoundException
closesodoo/odoo#135607
Related: odoo/upgrade#5187
Related: odoo/enterprise#47475
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Odoo Translation Bot