Odoo - The current checkout of upstream Odoo

Age	Commit message (Collapse)	Author
2018-11-26	[IMP] mail: Allowing drag/drop files/images on mail composer	Dharmang Soni
	By this commit user can upload attachments by drag and drop in chatter composer. This feature can be used from discuss UI, chat windows and form view chatter. Before this commit chatter unlinks the attachment if another attachment uploaded with same name. Criteria for removing duplicate attachment is changed with this commit. Now it will remove the attachment based on name and size of attachment. The reason for this change is, when you upload image with same name from different directory with old condition it was not possible to attach more then one image/file of same name. Related to task #32469 Closes #18914
2018-07-27	[REF] web, mail: get rid of the btn-icon class	qsm-odoo
	That was pretty useless, better use the btn-secondary class and add particular rules to `.btn.fa` if necessary.
2018-07-27	[REF] *: BS4, adapt media queries	qsm-odoo
	media queries that target a specific screen size handled by bootstrap have now a more convenient way to be defined: ``` @media (min-width: $screen-sm-min) { ... } -> @include media-breakpoint-up(sm) { ... } ``` ``` @media (max-width: $screen-sm-max) { ... } -> @include media-breakpoint-down(sm) { ... } ``` ``` @media (min-width: $screen-sm-min) and (max-width: $screen-sm-max) { ... } -> @include media-breakpoint-only(sm) { ... } ``` ``` @media (min-width: $screen-sm-min) and (max-width: $screen-md-max) { ... } -> @include media-breakpoint-between(sm, md) { ... } ``` Also, bootstrap has changed the values for its default screen sizes: ------------------ \| BS3 \| BS4 \| ------------------ 0 \| XS \| XS \| -> Portrait Mobile 576 \| / \| SM \| -> Landscape Mobile 768 \| SM \| MD \| -> Portrait Tablet 992 \| MD \| LG \| -> Landscape Tablet / Small Desktop 1200 \| LG \| XL \| -> Desktop ------------------ While it is possible to configure BS variables to behave as BS3, we took the decision to keep the BS4 variables untouched. BS4 system seems indeed better and having the purest bootstrap possible is better for Odoo to be used as a framework.
2018-07-27	[REF] *: get rid of vendor prefixes	qsm-odoo
	BS4 do not provide vendor prefixes scss mixins anymore as it is meant to be used with the 'autoprefixer' library. As we only support the last version of every major browsers in Odoo, we took the decision to not use the library as it was also complex to integrate in Odoo. We decided to do the library's work by hand if it ever become necessary.
2018-07-02	[REF] mail: JS mail refactoring	Alexandre Kühn
	---------------------- Summary ---------------------- The purpose of this commit is to improve the JS code of the `mail` module. It applies the new coding guidelines and makes some changes on the design of some modules, such as the old ChatManager module. Here is a short summary of the changes that have been made: 1. New coding guidelines - snake_case to camelCase - prefix private attributes and methods with '_' - jsdoc on most methods - one class per module 2. Rename/Merge some classes - 'chat manager' becomes 'mail manager' (internal) and 'mail service' (external) - 'chat window manager' is now included in mail manager - 'thread' widget now named 'thread widget' 3. New model abstraction for mail objects: - modules 'mail.model.' - modeling: 0..1 0..1 * ThreadWindow <------> Thread <-------> Message / \ / \ Thread With Cache Document Thread / \| \ / \| \ Mailbox Channel Support Channel \| \| DM - Thread: the superclass of threads. - ThreadWindow: the window component of a thread. - Message: mail objects representing messages. - Thread With Cache: threads that can be used with search view (Discuss app compatible). - Document Thread: represents the thread part of a chatter. - Mailbox: represents what was previously called 'static' channel, e.g. 'Inbox'. - Channel: mail objects representing channels, including livechat. - DM: special kind of Channel for 1:1 communication in the backend. - Support Channel: special channel for im_support module. This new modeling approach let us easily add features on all threads, such as the possibility to put any thread in a small window. ---------------------- Known issues ---------------------- [Already Present in Master] 1. When the Discuss app is in the background with 'Inbox' as the selected Thread, when clicking on a document thread preview in the messaging menu of the systray, the rainbow man appears. 2. When a document with the chatter is in the background, when receiving an inbox notification from this document thread, the document thread is automatically marked as read, which removes the notification right away. 3. Sometimes, opening a DM window from the "blank" thread window does not work. 4. Reply-to feature on Inbox is not working: no message is sent in the document thread. 5. On the first login of admin user with demo data, the inbox counter is wrong (it displays 6, instead of 3). Explanation after investigation: > On page load, it fetches the correct number of Inbox messages (3), but the server notifies of 3 needaction messages right away, so it wrongly assumes these are new needaction messages. > Not possible for web client to detect that these messages should not increment the Inbox counter while keeping same API. 6. Notifications for new document thread messages only work when the user sets 'handle with Odoo' for the Notification Management in the preferences. > due to notifications on the longpoll bus for document thread messages that come from needaction notifications. > requires server-side changes to send notification on the longpoll bus to mentionned user. [New] 7. When receiving a message on a unjoined channel, thread window flickers ('open' > 'close' > 'open') Explanation after investigation: > JS logic: a) On auto-join, ask server to join the channel and get channel infos. b) The info tells the channel is not detached, but JS code makes decision to detach it, and tells server the channel is now detached. c) From (a), server notifies on longpoll bus the state of channel, which is not detached. The web client thinks that the window state of the channel has been changed somewhere else, and the channel is now closed. d) From (b), server notifies on longpoll bus the state of channel, which is detached. The web client opens the thread window of this channel. > The flicker didn't occur before refactoring because the web client was only updating the model of channel when it receives the longpoll notification. > Server behaviour on 1st longpoll notification is necessary for cross-tab synchronization for channel window state. > New design implies that model and view should be synchronized, hence the issue now. > Solution: remove server-side thread window synchronization and replace with client-side synchronization. ---------------------- Hacks ---------------------- The module `im_livechat` now uses mail objects that are compatible with Message and Window objects: Modeling for messages: AbstractMessage / \ / \ LivechatMessage Message - AbstractMessage: message compatible with the thread widget. - LivechatMessage: message used by im_livechat. - Message: message used with the mail manager. Modeling for thread windows: AbstractThreadWindow / \ / \ LivechatWindow ThreadWindow - AbstractThreadWindow: behaviour share between all types of thread windows. - LivechatWindow: window used by im_livechat. - ThreadWindow: window used with mail_manager. The reason for these hacks are twofold: 1. Use the thread widget in the frontend and livechat external lib bundles. 2. Do not have a dependency with the mail manager in the frontend and external lib bundles.

By this commit user can upload attachments by drag and drop in chatter composer. This feature can be used from discuss UI, chat windows and form view chatter. Before this commit chatter unlinks the attachment if another attachment uploaded with same name. Criteria for removing duplicate attachment is changed with this commit. Now it will remove the attachment based on name and size of attachment. The reason for this change is, when you upload image with same name from different directory with old condition it was not possible to attach more then one image/file of same name. Related to task #32469 Closes #18914

That was pretty useless, better use the btn-secondary class and add particular rules to `.btn.fa` if necessary.

media queries that target a specific screen size handled by bootstrap have now a more convenient way to be defined: ``` @media (min-width: $screen-sm-min) { ... } -> @include media-breakpoint-up(sm) { ... } ``` ``` @media (max-width: $screen-sm-max) { ... } -> @include media-breakpoint-down(sm) { ... } ``` ``` @media (min-width: $screen-sm-min) and (max-width: $screen-sm-max) { ... } -> @include media-breakpoint-only(sm) { ... } ``` ``` @media (min-width: $screen-sm-min) and (max-width: $screen-md-max) { ... } -> @include media-breakpoint-between(sm, md) { ... } ``` Also, bootstrap has changed the values for its default screen sizes: ------------------ | BS3 | BS4 | ------------------ 0 | XS | XS | -> Portrait Mobile 576 | / | SM | -> Landscape Mobile 768 | SM | MD | -> Portrait Tablet 992 | MD | LG | -> Landscape Tablet / Small Desktop 1200 | LG | XL | -> Desktop ------------------ While it is possible to configure BS variables to behave as BS3, we took the decision to keep the BS4 variables untouched. BS4 system seems indeed better and having the purest bootstrap possible is better for Odoo to be used as a framework.

BS4 do not provide vendor prefixes scss mixins anymore as it is meant to be used with the 'autoprefixer' library. As we only support the last version of every major browsers in Odoo, we took the decision to not use the library as it was also complex to integrate in Odoo. We decided to do the library's work by hand if it ever become necessary.

---------------------- Summary ---------------------- The purpose of this commit is to improve the JS code of the `mail` module. It applies the new coding guidelines and makes some changes on the design of some modules, such as the old ChatManager module. Here is a short summary of the changes that have been made: 1. New coding guidelines - snake_case to camelCase - prefix private attributes and methods with '_' - jsdoc on most methods - one class per module 2. Rename/Merge some classes - 'chat manager' becomes 'mail manager' (internal) and 'mail service' (external) - 'chat window manager' is now included in mail manager - 'thread' widget now named 'thread widget' 3. New model abstraction for mail objects: - modules 'mail.model.*' - modeling: 0..1 0..1 * * ThreadWindow <------> Thread <-------> Message / \ / \ Thread With Cache Document Thread / | \ / | \ Mailbox Channel Support Channel | | DM - Thread: the superclass of threads. - ThreadWindow: the window component of a thread. - Message: mail objects representing messages. - Thread With Cache: threads that can be used with search view (Discuss app compatible). - Document Thread: represents the thread part of a chatter. - Mailbox: represents what was previously called 'static' channel, e.g. 'Inbox'. - Channel: mail objects representing channels, including livechat. - DM: special kind of Channel for 1:1 communication in the backend. - Support Channel: special channel for im_support module. This new modeling approach let us easily add features on all threads, such as the possibility to put any thread in a small window. ---------------------- Known issues ---------------------- [Already Present in Master] 1. When the Discuss app is in the background with 'Inbox' as the selected Thread, when clicking on a document thread preview in the messaging menu of the systray, the rainbow man appears. 2. When a document with the chatter is in the background, when receiving an inbox notification from this document thread, the document thread is automatically marked as read, which removes the notification right away. 3. Sometimes, opening a DM window from the "blank" thread window does not work. 4. Reply-to feature on Inbox is not working: no message is sent in the document thread. 5. On the first login of admin user with demo data, the inbox counter is wrong (it displays 6, instead of 3). Explanation after investigation: > On page load, it fetches the correct number of Inbox messages (3), but the server notifies of 3 needaction messages right away, so it wrongly assumes these are new needaction messages. > Not possible for web client to detect that these messages should not increment the Inbox counter while keeping same API. 6. Notifications for new document thread messages only work when the user sets 'handle with Odoo' for the Notification Management in the preferences. > due to notifications on the longpoll bus for document thread messages that come from needaction notifications. > requires server-side changes to send notification on the longpoll bus to mentionned user. [New] 7. When receiving a message on a unjoined channel, thread window flickers ('open' > 'close' > 'open') Explanation after investigation: > JS logic: a) On auto-join, ask server to join the channel and get channel infos. b) The info tells the channel is not detached, but JS code makes decision to detach it, and tells server the channel is now detached. c) From (a), server notifies on longpoll bus the state of channel, which is not detached. The web client thinks that the window state of the channel has been changed somewhere else, and the channel is now closed. d) From (b), server notifies on longpoll bus the state of channel, which is detached. The web client opens the thread window of this channel. > The flicker didn't occur before refactoring because the web client was only updating the model of channel when it receives the longpoll notification. > Server behaviour on 1st longpoll notification is necessary for cross-tab synchronization for channel window state. > New design implies that model and view should be synchronized, hence the issue now. > Solution: remove server-side thread window synchronization and replace with client-side synchronization. ---------------------- Hacks ---------------------- The module `im_livechat` now uses mail objects that are compatible with Message and Window objects: Modeling for messages: AbstractMessage / \ / \ LivechatMessage Message - AbstractMessage: message compatible with the thread widget. - LivechatMessage: message used by im_livechat. - Message: message used with the mail manager. Modeling for thread windows: AbstractThreadWindow / \ / \ LivechatWindow ThreadWindow - AbstractThreadWindow: behaviour share between all types of thread windows. - LivechatWindow: window used by im_livechat. - ThreadWindow: window used with mail_manager. The reason for these hacks are twofold: 1. Use the thread widget in the frontend and livechat external lib bundles. 2. Do not have a dependency with the mail manager in the frontend and external lib bundles.