summaryrefslogtreecommitdiff
path: root/addons/mail/static/src/js/models
AgeCommit message (Collapse)Author
2020-06-15[REF] mail, *: refactor messaging with OWLSébastien Theys
This commit is a significant rewriting of client-side discuss, chatter, chat window, and messaging menu using OWL. The behavior should be broadly the same, with some slight functional changes here and there. From a technical standpoint, the code of messaging is mainly organized in 2 main groups of modules: - models, which are logical entities that depict the client-side state of messaging as a whole. - components, which are in charge of displaying information from models. This refactoring also introduces new JS guidelines regarding folder structure (/static) and naming rules for JS modules. Community PR: https://github.com/odoo/odoo/pull/39023 Enterprise PR: https://github.com/odoo/enterprise/pull/6249 Task-1914207 This PR is a collaborative work by Alexandre, Julien, Sébastien and Xavier, with the precious help of Lucas to speed it up towards the end. closes odoo/odoo#39023 Related: odoo/enterprise#6249 Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com> Co-authored-by: Alexandre Kühn <aku@odoo.com> Co-authored-by: Julien Giannone <jgi@odoo.com> Co-authored-by: Lucas Perais <lpe@odoo.com> Co-authored-by: Sébastien Theys <seb@odoo.com> Co-authored-by: Xavier Dubuc <xdu@odoo.com>
2020-06-09[REM] im_support: remove im_support moduleSébastien Theys
The goal of the module was to communicate with livechat operators on our production server, except the feature is disabled on our prod and we don't plan to reactivate it any time soon. closes odoo/odoo#52691 Related: odoo/upgrade#1313 Signed-off-by: Christophe Simonis <chs@odoo.com>
2020-05-20[IMP] mail: display user avatar in chat-box headerHiral Bhavsar
PURPOSE We are currently working toward turning every user avatar (i.e. the round picture of the user) in a shortcut to open the chatbox to that user. It only makes sense to also have the user avatar in the header of the chatbox (like in Facebook) SPECIFICATION Replace the current IM status colored dot of the chatbox header by the same avatar/im_status compound currently used in the chatter. LINKS Closes https://github.com/odoo/odoo/pull/51258 Task-2256061 closes odoo/odoo#51258 Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
2020-04-17[IMP] mail, sms, snailmail, test_mail_full: adapt mail.notificationSébastien Theys
The purpose is to have more common code for failure and notifications, with less override in `sms` and `snailmail`. task-2176017 closes odoo/odoo#44170 Related: odoo/enterprise#9140 Related: odoo/upgrade#918 Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
2020-03-19[FIX] mail: correctly parse datetime returned from serverPierre Paridans
When a user is Out-of-Office, the return date is displayed as "Invalid date" on Safari (both iOS & macOS). The parsing of the date returned by the server was done using the Date constructor and passing the string as-is. This constructor delegates the parsing to the `Date.parse` method. But the DateTime format used to stringify dates in Odoo doesn't fully follow the ISO 8601, as required by `Date.parse()`: expected format: "YYYY-MM-DDTHH:mm:ss.sssZ" actual format: "YYYY-MM-DD HH:mm:ss" Also, Safari applies more strictly to this requirement than Chrome & Firefox, resulting in a parsing error in the former browser. This commit fixes it by using the utility function `str_to_datetime` from `web.time` to correctly parse this date, independently of the browser used. NB: as this issue is browser dependent, no test has been added. References: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/Date https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/parse https://tc39.es/ecma262/#sec-date-time-string-format Task ID: 2198486 closes odoo/odoo#47987 X-original-commit: b85a44aea9617b9018dd80d5f8159354bbc88f09 Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
2020-02-18[FIX] mail: no crash on receiving needaction on messaging not readyAlexandre Kühn
Before this commit, when receiving a needaction message while messaging was not ready (i.e. `/mail/init_messaging` not resolved), the web client crashed with the following error message: ``` TypeError: Cannot read property 'incrementMailboxCounter' of undefined ``` This happens due to reception of needaction message incrementing counter of mailbox Inbox, but this mailbox is only added after messaging is ready. This commit fixes the issue by directly adding inbox mailbox on starting the mail service. closes odoo/odoo#45442 X-original-commit: 741acb9f48f2d3542549791a8fd7d6fb318bc862 Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
2020-02-10[IMP] mail, test_mail, hr_holidays: remove obsolete out of officeSébastien Theys
The customizable "out of office" text was removed from the editable views as part of task-2053585, but some places in the code were still using it, even though it was never set anymore. This commit removes the obsolete code. Part of task-2171864 closes odoo/odoo#44968 Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
2020-01-31[FIX] mail: abstract getAvatarSource has defaultjerome hanke (jhk)
Steps to reproduce: - install sales - create a new quotation Previous behavior: the avatar next to the author's name is empty in the mailthread Current behavior: avatar is displayed as expected opw-2187231 closes odoo/odoo#44407 X-original-commit: 24ba9f9954a71eba46d44fe242cd2e6dba125da6 Signed-off-by: mightyjol <jhk-odoo@users.noreply.github.com>
2020-01-08[FIX] mail: faster opening of messaging menuAlexandre Kühn
Before this commit, opening the messaging menu might be slow. This was caused by the parsing of bodies of messages with lots of HTML nodes. Indeed, the body of a message is linkified and inlined, and both processes were quite slow due to their implementation: each node in the HTML were recursively parsed and re-assigning `innerHTML`. As a result, each node was triggering an HTML parse, which is very slow on complex nodes. This commit fixes this performance issue by speeding up inlining and linkifying of html strings. In the case of linkify, it now triggers an HTML parse only when necessary, while inlining now relies on its textContent value. These changes should drastically improve the speed of opening and rendering messaging menu, almost ten times faster. Task-Id 2076299 closes odoo/odoo#42949 X-original-commit: 8db0afb50ce0853a6a8ab7ee11dd5ed876abab64 Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
2019-12-12[FIX] mail: Timer(s) tests nondeterministic behaviorVincent Schippefilt
Timer test relies on setTimeout(..., 0) for its execution and its verification. However it seems that in the browser there is *not always* a guarantee that 2 setTimeout(...,0) will execute in a specific order. Delaying the verification by 1 ms : setTimeout(..., 1) should force the order of execution. closes odoo/odoo#41732 Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
2019-12-02[REF] mail, various: rename subtype parameter of message_post to subtype_xmlidThibault Delavallée
PURPOSE Clean posting process and improve mail.message definition and comprehension. SPECIFICATIONS In order to be more explicit subtype parameter is renamed to subtype_xmlid. It therefore clearly indicates it should be a valid subtype Xml ID. Support of ill formatted Xml IDs is removed because there is no reason to try to add some random prefix. Give something that exists or go to hell, punk ! LINKS Task ID 2071556 PR #38692
2019-11-30[IMP] mail: Unsychronize chat windows between mobile and desktopAdrien Dieudonne
Currently when you open, for example, 5 chat windows on the desktop, each of those windows will be opened on mobile as well. The big issue with that is that I have to shut down all windows before starting to work on the application. To make things simple, you have to explicitly open chat window to make it appears on mobile. Synchronization is blocked in both direction. We don't update the chat window state on the server and we no longer consider notifications (bus) about it. Tests were added in enterprise. Task ID: 1891952 closes odoo/odoo#41052 Related: odoo/enterprise#6943 Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
2019-11-29[IMP] mail: show out of office ribbon on discussmgh-odoo
This commit adds the out-of-office ribbon at the top of the conversation in the discuss app. Task-2066672 closes odoo/odoo#39362 Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com> Co-authored-by: Mohammed Shekha <msh@odoo.com>
2019-11-27[FIX] mail: reply to noteNicolas Martinelli
- Handle the notifications in Odoo - On any object, e.g. a SO, user A a note and ping user B - As user B, go to Discuss and reply to the note The reply is sent a regular message. Actually, everything is available to reply with the right message type in: https://github.com/odoo/odoo/blob/bae8ab7d93143e082e1d1a9cbe20a350c2d34d07/addons/mail/static/src/js/discuss.js#L1327 It is simply unset. opw-2088619 closes odoo/odoo#40946 X-original-commit: 84c8221c60e3483aa637abad057253424236af83 Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
2019-11-22[FIX] mail: Limit emojis quantityjbm-odoo
If the user put more than 200 emojis, we didn't replace emoji with image. But due to a typo in the code, this mechanism broke the discuss application. closes odoo/odoo#40734 X-original-commit: 0877cb6c84c768bd9fad46fa6f959635bb2353a5 Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
2019-09-27[FIX] mail: Support nameless attachmentsJairo Llopis
`ir.attachment` records do not require to have a filename set. In `AttachmentBox`, a filename is always set, although in case it's missing it was untranslated. I fixed that. In cases where `AttachmentBox` is not used but its underlying templates are rendered using other means, a user could get a client-side error like this one when browsing a record that had an attachment without filename: <details><summary>Error</summary> ``` Error: TypeError: dict.attachment.filename.split is not a function https://www.tecnativa.com/web/static/lib/qweb/qweb2.js line 469 > Function:26 Rastreo de error: anonymous@https://www.tecnativa.com/web/static/lib/qweb/qweb2.js line 469 > Function:26:45 _render@https://www.tecnativa.com/web/static/lib/qweb/qweb2.js:458:58 call@https://www.tecnativa.com/web/static/lib/qweb/qweb2.js:154:35 anonymous/<@https://www.tecnativa.com/web/static/lib/qweb/qweb2.js line 469 > Function:340:33 foreach@https://www.tecnativa.com/web/static/lib/qweb/qweb2.js:180:25 anonymous@https://www.tecnativa.com/web/static/lib/qweb/qweb2.js line 469 > Function:338:25 _render@https://www.tecnativa.com/web/static/lib/qweb/qweb2.js:458:58 call@https://www.tecnativa.com/web/static/lib/qweb/qweb2.js:154:35 anonymous/<@https://www.tecnativa.com/web/static/lib/qweb/qweb2.js line 469 > Function:27:31 foreach@https://www.tecnativa.com/web/static/lib/qweb/qweb2.js:180:25 anonymous@https://www.tecnativa.com/web/static/lib/qweb/qweb2.js line 469 > Function:11:23 _render@https://www.tecnativa.com/web/static/lib/qweb/qweb2.js:458:58 render@https://www.tecnativa.com/web/static/lib/qweb/qweb2.js:450:26 _render@https://www.tecnativa.com/web/static/lib/qweb/qweb2.js:480:29 call@https://www.tecnativa.com/web/static/lib/qweb/qweb2.js:154:35 anonymous@https://www.tecnativa.com/web/static/lib/qweb/qweb2.js line 469 > Function:20:30 _render@https://www.tecnativa.com/web/static/lib/qweb/qweb2.js:458:58 render@https://www.tecnativa.com/web/static/lib/qweb/qweb2.js:450:26 _render@https://www.tecnativa.com/web/static/lib/qweb/qweb2.js:480:29 call@https://www.tecnativa.com/web/static/lib/qweb/qweb2.js:154:35 anonymous@https://www.tecnativa.com/web/static/lib/qweb/qweb2.js line 469 > Function:15:31 _render@https://www.tecnativa.com/web/static/lib/qweb/qweb2.js:458:58 render@https://www.tecnativa.com/web/static/lib/qweb/qweb2.js:450:26 _render@https://www.tecnativa.com/web/static/lib/qweb/qweb2.js:480:29 call@https://www.tecnativa.com/web/static/lib/qweb/qweb2.js:154:35 anonymous@https://www.tecnativa.com/web/static/lib/qweb/qweb2.js line 469 > Function:11:31 _render@https://www.tecnativa.com/web/static/lib/qweb/qweb2.js:458:58 render@https://www.tecnativa.com/web/static/lib/qweb/qweb2.js:450:26 _render@https://www.tecnativa.com/web/static/lib/qweb/qweb2.js:480:29 render@https://www.tecnativa.com/web/static/lib/qweb/qweb2.js:450:26 render@https://www.tecnativa.com/mail/static/src/js/thread_widget.js:183:28 _fetchAndRenderThread/<@https://www.tecnativa.com/mail/static/src/js/thread_field.js:124:36 then/</</<@https://www.tecnativa.com/web/static/lib/jquery/jquery.js:3276:89 fire@https://www.tecnativa.com/web/static/lib/jquery/jquery.js:3119:58 fireWith@https://www.tecnativa.com/web/static/lib/jquery/jquery.js:3231:49 Deferred/</deferred[tuple[0]]@https://www.tecnativa.com/web/static/lib/jquery/jquery.js:3321:62 then/</</<@https://www.tecnativa.com/web/static/lib/jquery/jquery.js:3276:89 fire@https://www.tecnativa.com/web/static/lib/jquery/jquery.js:3119:58 fireWith@https://www.tecnativa.com/web/static/lib/jquery/jquery.js:3231:49 then/</</<@https://www.tecnativa.com/web/static/lib/jquery/jquery.js:3283:104 fire@https://www.tecnativa.com/web/static/lib/jquery/jquery.js:3119:58 fireWith@https://www.tecnativa.com/web/static/lib/jquery/jquery.js:3231:49 Deferred/</deferred[tuple[0]]@https://www.tecnativa.com/web/static/lib/jquery/jquery.js:3321:62 fire@https://www.tecnativa.com/web/static/lib/jquery/jquery.js:3119:58 fireWith@https://www.tecnativa.com/web/static/lib/jquery/jquery.js:3231:49 then/</</<@https://www.tecnativa.com/web/static/lib/jquery/jquery.js:3283:104 fire@https://www.tecnativa.com/web/static/lib/jquery/jquery.js:3119:58 fireWith@https://www.tecnativa.com/web/static/lib/jquery/jquery.js:3231:49 Deferred/</deferred[tuple[0]]@https://www.tecnativa.com/web/static/lib/jquery/jquery.js:3321:62 rpc/<@https://www.tecnativa.com/web/static/src/js/services/ajax_service.js:16:29 then/</</<@https://www.tecnativa.com/web/static/lib/jquery/jquery.js:3276:89 fire@https://www.tecnativa.com/web/static/lib/jquery/jquery.js:3119:58 fireWith@https://www.tecnativa.com/web/static/lib/jquery/jquery.js:3231:49 Deferred/</deferred[tuple[0]]@https://www.tecnativa.com/web/static/lib/jquery/jquery.js:3321:62 fire@https://www.tecnativa.com/web/static/lib/jquery/jquery.js:3119:58 fireWith@https://www.tecnativa.com/web/static/lib/jquery/jquery.js:3231:49 Deferred/</deferred[tuple[0]]@https://www.tecnativa.com/web/static/lib/jquery/jquery.js:3321:62 genericJsonRpc/<@https://www.tecnativa.com/web/static/src/js/core/ajax.js:65:18 then/</</<@https://www.tecnativa.com/web/static/lib/jquery/jquery.js:3276:89 fire@https://www.tecnativa.com/web/static/lib/jquery/jquery.js:3119:58 fireWith@https://www.tecnativa.com/web/static/lib/jquery/jquery.js:3231:49 then/</</<@https://www.tecnativa.com/web/static/lib/jquery/jquery.js:3283:104 fire@https://www.tecnativa.com/web/static/lib/jquery/jquery.js:3119:58 fireWith@https://www.tecnativa.com/web/static/lib/jquery/jquery.js:3231:49 done@https://www.tecnativa.com/web/static/lib/jquery/jquery.js:9275:42 callback@https://www.tecnativa.com/web/static/lib/jquery/jquery.js:9685:57 ``` The error is produced when trying to render this line: https://github.com/odoo/odoo/blob/66c5053a3d1f8cb456929453a62869c95eccf86a/addons/mail/static/src/xml/thread.xml#L506 </details> This patch ensures all attachment has a filename, and fixes that problem. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr @Tecnativa TT19555 closes odoo/odoo#37546 Forward-port-of: odoo/odoo#37253 X-original-commit: ebba3c9fa709dccf4cab91e9f37aa3eaa24c7d21 Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
2019-09-19[IMP] *: remove image_64 and clean viewsSébastien Theys
There are too many image sizes. Since they are stored resized this takes time to generate when saving a new image, it's more rows on the attachment table, more files on the disk, ... 64px is close enough to 128px that it can be removed without a big impact on download size. It will even reduce download and number of requests when both images are displayed because now only one has to be downloaded and then benefit from cache. The difference between the two is typically around 1.5kB which is negligible these days, especially when the request overhead is around 0.5kB already, not even taking into account other factors such as latency. If a 64px image must absolutely be returned, it is still possible to pass the size parameters to the image route. But the current guideline is to handle resizing in the views when necessary. Views ===== - remove width and height attributes when existing CSS rules are overriding them (eg. `.oe_kanban_avatar` in the right context) - add CSS rules instead of width and height attributes when possible - use `object-fit: cover;` where width and height are forced to avoid distortion of non-square images - for products, use `object-fit: contain;` instead, keep ratio but without crop - add new CSS rules where the expected size was max 64px*64px before due to the image size itself - remove `img-fluid` where using size classes to avoid conflicting rules task-2060865 closes odoo/odoo#36147 Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
2019-09-13[MERGE] forward port branch saas-12.4 up to fe59754c520Christophe Simonis
closes odoo/odoo#36721 Signed-off-by: Christophe Simonis <chs@odoo.com>
2019-09-11[MERGE] forward port branch saas-12.3 up to 50e571acf7cChristophe Simonis
closes odoo/odoo#36491 Signed-off-by: Christophe Simonis <chs@odoo.com>
2019-09-04[MERGE] forward port branch 12.0 up to 638eac9baeaChristophe Simonis
2019-08-30[FIX] mail: channel notification messages are never marked as unreadAlexandre Kühn
When a user either joins and leaves a channel, it posts a message of type 'notification' with either action as content. Before this commit, such messages above were incrementing the unread counter of the channel. As a result, the messaging menu was showing this channel as unread with this message. Messages of type 'notification' should never increment the unread counter of channel. This commit fixes the issue by preventing new messages of type 'notification' to increment the unread counter of a conversation. This should also prevent increasing the counter of the messaging menu, in addition to highlighting this channel as unread from the messaging menu. Task-Id 2059515 closes odoo/odoo#36293 Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
2019-09-03[FIX] bus, mail: correctly synchronize document chat windowsAlexandre Kühn
Before this commit, there could be an infinite loop when changing the chat window state of a document chat window. This is caused when mutiple tabs overwrite the chat window state with a different value everytime, resulting to an infinite loop. Accross multiple tabs, `setItem` and `onStorage` are not synchronous. That's why tabs should communicate through local storage events instead of actual value in the local storage. To illustrate the issue, suppose there are 2 tabs (T1 and T2) with one document chat windows (C) and the following user interactions: - T1 and T2 both have C open - on T1, user folds C - on T2, user folds C Now let's add an example of local storage (LS) logics that could apply from above example: - T1 and T2 both have C open - on T1, user folds C [1] T1 writes 'C folded' in LS - on T2, user folds C [2] T2 writes 'C folded' in LS [3] T2 detects 'C folded' in LS (from [1]) => T2 writes 'C folded' in LS [4] T1 detects 'C folded' in LS (from [2]) => T1 writes 'C folded' in LS [5] T1 detects 'C folded' in LS (from [3]) => T1 writes 'C folded' in LS [6] T2 detects 'C folded' in LS (from [4]) => T2 writes 'C folded' in LS etc... This scenario could have been easily prevented by not writing on local storage when the chat window state has not changed. However, this wouldn't fix this scenario that also introduces an infinite loop: - T1 and T2 both have C open - on T1, user folds C [1] T1 writes 'C folded' in LS - on T2, user folds C [2] T2 writes 'C folded' in LS - on T2, user unfolds C [3] T2 writes 'C unfolded' in LS [4] T2 detects 'C folded' in LS (from [1]) => T2 writes 'C folded' in LS [5] T1 detects 'C unfolded' in LS (from [3]) => T1 writes 'C unfolded' in LS [6] T2 detects 'C unfolded' in LS (from [5]) => T2 writes 'C unfolded' in LS [7] T1 detects 'C folded' in LS (from [4]) => T1 writes 'C folded' in LS [8] T2 detects 'C folded' in LS (from [7]) => T2 writes 'C folded' in LS [9] T1 detects 'C unfolded' in LS (from [6]) => T1 writes 'C folded' in LS etc... This commit fixes the infinite loop issue: - by turning local storage read during cross-tab communication into local storage event read instead. This should prevent race conditions based on read/write operations in local, since their order is not guaranteed accros tabs. - by isolating document chat window state to their own local storage entry. This should prevent a tab from notifying a chat window state that it didn't change, which may also result in an infinite loop. Some tests were adapted from the changes above. Also, some tests did pass thanks to local storage being mocked by a ram storage: the handler `_onStorage` should have been called, but it didn't because it was registered on the actual local storage instead of the ram storage. In order to make tests pass again, the following additional changes were required: - Cross-tab bus service now exports the unique tab ID with `getTabId`. - document thread entries in local storage now track the tab ID, so that self-tab ignore their own local storage writes. Task-Id 2034997 Closes #36177
2019-08-20[MERGE] forward port branch saas-12.3 up to 6f55fd65da8Christophe Simonis
2019-08-19[MERGE] forward port branch 12.0 up to 32039b2ab44Christophe Simonis
2019-08-06[FIX] mail: keep notification on receiving new messages from documentAlexandre Kühn
Revision on https://github.com/odoo/odoo/commit/17bb0ca443f54bc231b03794e776bbc6992ffdfa closes odoo/odoo#35497 Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
2019-09-03[FIX] mail: mention a channel from a channelDebauche Stéphane
Before this commit, when mentioning a channel from a channel, it crashed with following error: ``` TypeError: unhashable type: 'list' ``` This commit fixes the issue by providing a list of channel ids, instead of a list of `[4, channelID]`, when mentioning channels. closes odoo/odoo#36359 Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
2019-08-21[MERGE] forward port branch saas-12.4 up to f26de445e55Christophe Simonis
2019-08-09[FIX] mail: notify other tabs on document thread message postAlexandre Kühn
Before this commit, most new messages added to the mail manager were handled as if recently posted from a document thread. As a result, it was frequently setting a new item in the local storage to notify other tabs from these new messages. The intent of this behaviour is to notify other tabs of newly posted messages in a document thread, without using a longpolling notification. That means this logic should only apply on messages that have been recently posted on a document thread. Sometimes, this issue was breaking the local storage on Firefox. It showed the error message "Quota Exceeded Error" whenever `setItem` was used, even when items were removed beforehand. The capacity of the storage was only a few Kbs on this domain, far from reaching the maximum capacity. We think that this error comes from the concurrent `setItem` on multiple tabs, but this is very hard to reproduce. This commit fixes the issue by limiting the `setItem` to the tab that really posted the message. Tests have been adapted in order to pass only with this fix. note: backport of 12.2 4bde721f9 opw-2031960 closes #35588 Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
2019-08-07[IMP] *: fix typos in commentsmreficent
closes odoo/odoo#35404 Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
2019-08-05[IMP] mail, test_mail: new 'History' mailbox in DiscussNikunj Ladava
This commit adds a new mailbox in the Discuss app called 'History'. Messages that have been marked as read are moved to 'History'. Notifications are required to link history messages to users. So notifications are now deleted after they are more tha 6 months old. This means History mailbox keeps less than 6 months old messages. Note that this feature only works when user notifications are handled in Odoo. This can be set in the user preferences, under the "Notification Management" section. Task-ID 402597
2019-08-02[IMP] *: remove unnecessary image sizesSébastien Theys
The big images are probably never going to be used for the following models: - pos category - fleet brand - livechat channel - mail channel - payment acquirer And if big images are needed some day the model should use image.mixin instead. PR: #34925
2019-08-02[IMP] *: rename image fieldsSébastien Theys
image_original => image_1920 (now resized to 1920) image_big => image_1024 image_large => image_256 image_medium => image_128 image_small => image_64 image replaced by image_1920 (when writing) or by image_1024 (when displaying what was previously the big size) + add new intermediate format: image_512 PR: #34925
2019-07-26[MERGE] forward port branch saas-12.3 up to 40e8b67179fChristophe Simonis
2019-07-24[MERGE] Forward port of saas-12.2 to saas-12.3 up to 860ab5a1c28baMartin Trigaux
closes odoo/odoo#35119 Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
2019-07-12[MERGE] Forward port of saas-12.3 to saas-12.4 up to 87fc1554d6a1823Martin Trigaux
closes odoo/odoo#34820 Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
2019-07-12[MERGE] Forwardport of saas-12.2 to saas-12.3 up to 01365a3f625c9e7Martin Trigaux
closes odoo/odoo#34747 Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
2019-07-10[FIX] mail: show old messages /leave w/o reloadNicolas Lempereur
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>
2019-07-16[FIX] mail: re-render discuss on message_fetch with typing membersAlexandre Kühn
When (un)registering a typing members of a channel, the discuss sidebar must be re-render. This is necessary in order to display the typing indicator next to discuss items, i.e. '...'. When receiving a message from a typing member, this person no longer becomes a typing member. Before this commit, for each new messages, the discuss sidebar was re-rendered. This happens due to unregistering the author from the typing members of the channel, even when the author was not a typing member in the first place. With this commit, when the list of typing members of a channel does not change, the discuss sidebar won't re-render and slow down the whole UI. opw-2035443 closes odoo/odoo#33616 Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
2019-07-16[FIX] mail: auto-update out-of-office info on im_status changeAlexandre Kühn
Before this commit, chat window's out-of-office info did not change when direct partner's `im_status` is/was on 'leave'. Users had to reload page to see updated out-of-office info. Task-ID 2007663
2019-07-16[FIX] mail: notify other tabs on document thread message postAlexandre Kühn
Before this commit, most new messages added to the mail manager were handled as if recently posted from a document thread. As a result, it was frequently setting a new item in the local storage to notify other tabs from these new messages. The intent of this behaviour is to notify other tabs of newly posted messages in a document thread, without using a longpolling notification. That means this logic should only apply on messages that have been recently posted on a document thread. Sometimes, this issue was breaking the local storage on Firefox. It showed the error message "Quota Exceeded Error" whenever `setItem` was used, even when items were removed beforehand. The capacity of the storage was only a few Kbs on this domain, far from reaching the maximum capacity. We think that this error comes from the concurrent `setItem` on multiple tabs, but this is very hard to reproduce. This commit fixes the issue by limiting the `setItem` to the tab that really posted the message. Tests have been adapted in order to pass only with this fix.
2019-06-06[MERGE] forward port branch saas-12.3 up to 409679866b2Christophe Simonis
2019-06-03[MERGE] forward port branch saas-12.2 up to 995aa1685eeChristophe Simonis
2019-05-29[IMP] mail: improve user notification model in mail.messageXavierDo
Currently if a message has a res_id and a res_model it appears in the matching record's chatter. Its access rights are computed based on this record. This is the standard behavior of mail.message model. User notifications are currently built on messages not having model and res_id in order to avoid appearing on chatter. This has several drawbacks notably access rights, redirection to the record, systray, finding back records, ... This commit solves those issues by adding new message_type 'user_notification' that should be as a classic mail.message with model and res_id but without the whole notification mechanism and without being displayed in the chatter. An user notification is now a classic message pushed to a given partner only and not displayed in the chatter. Related to task 1943901 Linked to PR #32404
2019-07-29[MERGE] forward port branch saas-12.4 up to cda4f3c308cChristophe Simonis
2019-07-18[FIX] mail, sms: post sms message as a note on related document and apply ↵Thibault Delavallée
various fixes PURPOSE Improve use of SMS. Followup of merge 4287481bf03fbb6539313ff657af0ca58e2895e7 . SPECIFICATIONS Currently when sending an SMS through the UI a message is posted using the comment subtype. However it is better to lessen number of notifications and log using the note subtype as it is mainly a log to know something has been sent. Order SMS by ID desc to ease finding them in technical menu. Mail, sms: fix wording of mail / SMS failures Linked to task 1925950 and 1935280 Part of PR #34864
2019-05-20[FIX] im_support, mail: message with odoobot as authorAlexandre Kühn
Before this commit, the `author_id` of a message with odoobot was `"ODOOBOT"`. This leads to some issues due to `author_id` being considered as an array `[partnerID, name]`. Because of this, mail status manager was registering a partner with ID `"O"` (1st char of `"ODOOBOT"`) for fetching its `im_status`. Its `im_status` was never updated, since no partner has such ID. However, the mail status manager kept this partner flagged with missing `im_status` and still attempted to fetch its `im_status`, indefinitely. This commit fixes the issue by turning `author_id` of a message with odoobot into arrray `["ODOOBOT", "ODOOBOT"]`. That way, `author_id` of a message is always an array, and the `im_status` of `"ODOOBOT"` is no longer fetched.
2019-02-22[MERGE] forward port branch saas-12.1 up to 0f4abc5c228Christophe Simonis
2019-03-06[REF] mail: adapt code after jQuery updateVincent Schippefilt
Part of task 1896658 Co-authored-by: Aaron Bohy <aab@odoo.com> Co-authored-by: Christophe Matthieu <chm@odoo.com> Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com> Co-authored-by: David Monjoie <dmo@odoo.com> Co-authored-by: Martin Geubelle <mge@odoo.com> Co-authored-by: svs-odoo <svs@odoo.com> Co-authored-by: Vincent Schippefilt <vsc@odoo.com>
2019-02-13[IMP] mail: allow tracking on groups protected fieldsLucas Lefèvre
Purpose ======= Currently fields with a `groups` attribute can't be tracked. Otherwise changes would be visible by all in the chatter, including users which normally don't have the access rights because they are not members of `groups`. Specification ============= Filter tracking field values according to the `groups` attributes. Users without the access rights should not see them. If a message is only composed of tracking values and the user doesn't have the rights to see them, an empty message should not be displayed.
2019-02-14[FIX] mail: enable seen feature only on direct chatsAlexandre Kühn
Revision on https://github.com/odoo/odoo/commit/844fb2b51ea7cfa557b19466c0a53dde19433e7a There were performance issue with the seen feature in multi- user channnels, therefore it has been disabled for them. As a result, only direct chats have this feature.
generated by cgit v1.2.3 (git 2.25.1) at 2026-10-23 21:58:39 +0000