19.0 discuss on direct sms messages#129
Open
nicolaepostica wants to merge 62 commits into
Open
Conversation
… autovacuum idle channels
… + _computeDiscussAppCategory)
group_connect_admin has no implied_ids to group_connect_user (Odoo 19 privilege groups are mutually exclusive), so admin users were excluded from connect_messages channel membership and could not see the Messages sidebar category in Discuss.
group_connect_user record rule restricts connect.message to sender_user only; agents reading inbound messages via Discuss hit an access error. Use sudo() for the display-only status/type fields in _to_store.
Notes posted in connect_messages channels have subtype_xmlid=mail.mt_note and must not be sent to the customer. Guard added in both JS (skips setting message_type=connect_message for notes) and Python is_outbound check (belt-and-suspenders server-side guard).
When _connect_send_outbound calls send()/send_whatsapp() the message is already in the discuss.channel thread; posting an additional chatter note on the partner record creates a duplicate. Add skip_chatter=False param to both senders and pass True from _connect_send_outbound.
datetime.now() returns naive local time; Odoo stores all datetimes in UTC. Replace both occurrences with fields.Datetime.now() so the idle threshold and unpin_dt are computed in UTC on any server timezone.
When an inbound SMS is received and has a chatter target, record the chatter mail.message as mail_message_id so it stays the canonical link. _connect_post_inbound now only sets mail_message_id on connect.message when it is not already populated, preventing the discuss mirror from overwriting the chatter reference.
Replace this.rpc (not a method in Odoo 19) with the standalone rpc function from @web/core/network/rpc. Relocate the AI completion button from after FileUploader (wrong area) into mail.Composer.extraActions so it sits alongside the emoji and other footer action icons.
…Discuss with Create Contact - Skip res.partner auto-creation in receive() when no matching partner found - Always mirror inbound to Discuss (remove if partner: guard) - _get_connect_channel: support phone-number-only channels (no partner) - _to_store: expose connect_partner_id + connect_number to frontend - Add connect_create_partner / _connect_link_partner methods - Frontend banner in Discuss composer: "no contact" + Create Contact button - 4 new tests covering number-only channel and contact creation flow
…ervice; icon-only button with title tooltip
…n above Invite People)
… sidebar; auto-select WA provider
…tect from whatsapp: prefix)
…s with a linked partner
Two bugs: - store_service_patch.js used thread.connectProvider (Composer getter, undefined on Thread); always sent 'sms' even for WhatsApp channels. Fixed to use thread.connect_channel_provider directly. - _connect_send_outbound used the agent user's configured outgoing callerid instead of the Twilio number the customer originally messaged. Now reads to_number from the last inbound connect.message on the channel and uses it as the callerid/WhatsApp sender. WhatsApp sender is matched by number field; SMS callerid is used directly from to_number. Also removes the hard-coded res_model/res_id='res.partner'/False when no partner is linked.
- Number-only connect_messages channels (no partner yet) showed "+" as the letter-avatar because the channel name starts with the phone number. Now shows default_contact.jpg for those channels. - Add "Open Contact" thread action (three-dots menu, above Create Contact) for channels that already have a linked partner; opens the partner form view in the current window.
Inbound WhatsApp connect.message records store from_number with the 'whatsapp:' prefix, but the discuss reply path passes the bare E.164 recipient. The 24h-window lookup searched from_number = recipient and never matched, so replies sent within the window were wrongly rejected with 'contact window expired' (and the whole message_post rolled back, losing the typed reply). Add the 'whatsapp:' prefix back for the lookup.
… bridges
Inbound receive() and outbound send() tag the target record's chatter
(mail.message.message_type) and mail.notification.notification_type with the
connect message_type. After lowercasing connect.message.message_type to
'whatsapp', those bridges passed an invalid value ('Wrong value for
mail.message.message_type: whatsapp'), aborting receive() before the Discuss
mirror ran. Add _mail_message_type() to translate to the capitalized 'WhatsApp'
the mail selections expect; sms/mms pass through unchanged.
…ails) Posting the inbound mirror with the comment subtype made Odoo email the contact's followers, which fails (red 'delivery failure' envelope) when no SMTP is configured and would spam agents on every inbound in prod. Use the internal note subtype: the message stays in the chatter history and agents still see it in the Discuss channel.
# Conflicts: # connect/models/message.py
…Discuss, quote replies - Inbound from a known partner now also posts a copy to the partner's own record chatter (deduped against the resolved target record). Unknown numbers still live only in the Discuss channel. - Outbound sent from a record's chatter (SMS/WhatsApp composer) is mirrored into the existing Discuss thread when one exists (never creates one). - Inbound replies (WhatsApp OriginalRepliedMessageSid) quote the parent's Discuss mirror via parent_id so the thread shows it as a reply. - Split the overloaded connect.message.mail_message_id: it now holds the chatter copy; new channel_message_id holds the Discuss mirror (used for the reply quote and the status-bubble bus push).
… message - New 'Archive' thread action on connect_messages channels unpins the conversation (thread.unpin -> channel_pin), removing it from the sidebar without leaving the channel. - _connect_resurface(): on inbound/outbound mirror, re-pin members who had archived the thread and push the channel to their Discuss sidebar so it reappears live when a new message arrives (replaces the bare unpin_dt reset).
The connect_messages sidebar category set serverStateKey 'is_discuss_sidebar_category_connect_messages_open' but that field was never defined on res.users.settings, so the category header couldn't collapse/expand (set_res_users_settings dropped the unknown key and the client never received the open-state). Add the boolean field (default True) so the toggle persists, matching the built-in channel/chat categories.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.