In Switzerland, states are really important. Each state has its rules, its
language, its culture, its parliament, etc. It's quite frowned upon to send an
invoice/offer or even to have backend management using German terms when we're
in a very French-speaking state.
So in this PR, we will add states in the missing languages
closesodoo/odoo#128954
Task: 3268058
X-original-commit: f309fd06cd46a767fee742ec9f634b46a2edf70f
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Before this commit, livechats in mobile were shown in the "Chat"
tab in both discuss app and messaging menu. This is alright, but
there's a dedicated tab for "Livechat", which was empty as a result.
The intended showing in mobile is to keep livechat away from "Chat",
and instead populate the "Livechat" filter.
Task-3430253
closesodoo/odoo#128934
X-original-commit: cf4b72582bbb52c7cd4bc17733f4dbbc84f9b321
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
If an inactive currency is given as company currency write values,
it is unarchived, but before the company update.
Therefore, if the unarchiving of the currency enables the multi-currency,
a default pricelist will be created for the company, but with the wrong
currency since it still wasn't updated.
This commit postpones the automatic creation of pricelists after the update
of the company, making sure the currency of the pricelist is the expected one.
opw-3423706
closesodoo/odoo#128958
X-original-commit: f7c90e4e1c5b6a3335e7c9b9e209a786d4238434
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
In the context of an urgent htmlField `commitChanges`, there is no time to wait
the response of `rpc` calls, therefore this commit proposes to use the same
strategy as `_toInline` for `savePendingImages` and not await the result of
the promises before a first `updateValue` if the commit is `urgent`.
This will allow to save most of the changes during a `beforeunload` scenario.
ENTERPRISE PR: https://github.com/odoo/enterprise/pull/42644
task-3372343
closesodoo/odoo#128949
X-original-commit: ba94629cb7fd1381871c37d34104f2511a4d4863
Related: odoo/enterprise#44307
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In 9deb1e6aa902a09c4f invisible duplicate were added for boolean groups.
But the added test could fail on master when installing only base
module: in this case, there is only the group "base.group_allow_export"
that is shown as a selection group because it is the only field of its
category. When we install other module, the field become a boolean group
that is handled by the aboved mentionned commit.
The previous fix and test didn't take this case into account, with
customization this could be a real issue.
With this commit, hidden selection field are also handled and the test
test_reified_groups pass in master when installing only base.
related to #120310closesodoo/odoo#128944
X-original-commit: b22fc41d63bded2435cd330517d407abab5035ee
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Before this commit:
In table selecting a list and on deletion/backspace page crashes.
After this commit:
The selected list is now deleted.
task-3383168
closesodoo/odoo#128943
X-original-commit: c7d3d247269ce27a10da39df5848cc10f9f6627b
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The number of invalidation during the test is quite large and
the crons cal also spam this log sometimes.
Waiting for further cleanup, removing this log to avoid spaming runbot
logs and making them harder to read.
closesodoo/odoo#128921
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Purpose:
--------
This commit makes the the avatars shown in many2one properties in kanban
cards smaller, as they were abnormally big.
Task-342200
closesodoo/odoo#128912
X-original-commit: 9ae4be80c68faafd7a09ea3cbeaf45e9b8eeaa71
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Before this commit, the `keydown` and `keyup` events of the call feature
were in bubble mode, which could prevent them from operating when some
other listeners would prevent the propagation of the event.
Since push-to-talk is supposed to always be usable, the listeners
are now in capture mode.
It was first made apparent with the addition of a `stopPropagation()` in
the `chatWindow` here: https://github.com/odoo/odoo/pull/127638closesodoo/odoo#128897
X-original-commit: 1466a6bc471ed583966e959b47f10bdc64837732
Signed-off-by: Didier Debondt (did) <did@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This commit partly reverts 59afbf6686 and
provides an alternative solution. In this solution, records.web_read()
returns a list of dicts where the key 'id' corresponds to each record.id
in records, which enables to reliably relate each record to its values.
This also fixes the implementation of web_read() on new records where
the fields contain a reference field with some context.
closesodoo/odoo#128878
Signed-off-by: Raphael Collet <rco@odoo.com>
Considering the valid odoo version in the manifest version
The message before of this commit was:
Modules should have a version in format ``x.y`` or ``x.y.z``
It looks like it enforces to removing the odoo version part as invalid
But it is not, in fact, it is already supported
It is important since OCA enforces ``{odoo.version}.x.y.z`` format
It was already discussed here:
- https://github.com/odoo/odoo/pull/118420#issuecomment-1635047100
The message after this commit is:
Modules should have a version in format `x.y`, `x.y.z`, `16.4.x.y` or `16.4.x.y.z`.
Notice the Odoo version "16.4" is the current {odoo.version} for the moment this commit was done
It avoid confusing about the valid formats to use
closesodoo/odoo#128810
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>
The opportunity is taken to make the feature reactive.
Also fix traceback if favorites can't be fetched from external API.
Part of task-3265211
Part-of: odoo/odoo#128799
This commit uniformises the different discuss option
panel by introducing a dedicated component.
Before this change, every single discuss panel would
look different: font size/weight, text in lower/upper
case, margins...
Moreover, in the chat window, the close panel button
was absolute positionned which could overlap with the
content of the panel. Moreover, the cross icon looked
strange with the one of the chat window header.
This commit introduces the `ActionPanel` component in
order to solve those inconsistencies and replaces the
cross icon by an arrow left one.
part of task-3332872
closesodoo/odoo#128742
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
*: point_of_sale, pos_adyen, pos_hr, pos_mercury, pos_restaurant
Adds online payments in Point of Sale using the payment module.
The pos_online_payment module is meant to be used by shops for paying online instead of using a physical terminal and by restaurants for paying an order either from the paying station or in the self-order process (smartphone used to order and pay online).
The module depends only on point_of_sale (and account_payment to support online payments).
The online payments support for self-order will be added in another commit.
The feature can be used by configuring a special pos.payment.method for one or many pos.config.
Operation:
The frontend session user can enter one or several online payment method lines (with or without other payment methods).
When he validates the order, if the online payment amounts are valid, a popup with a QR code is displayed on the frontend screen and on the customer display. This QR code allows the customer to open the payment page to pay online for the order.
The amount to pay for an order on the payment portal is the remaining unpaid amount or a lower amount if several online payments lines are used. Therefore, at any time, the customer will be able to pay the amount of the order that is unpaid, without requiring a staff operation to update the amount to pay.
When an online payment is done for a POS order, the generated account.payment is linked to the POS order through a pos.payment that is created with the online payment method configured for the pos.config, and the POS order paid process is triggered (it is the responsibility of the server to finalize the validation of POS orders that have at least one online payment, and not the responsibility of the POS session web client). If for any reason, there is no longer any online payment method configured for the pos.config of the order, a new one can be created automatically and exceptionnaly used to link the done payment with the POS order. This guarantees that any online payment saved by the payment module will be linked to the POS order.
The session web client is notified of successful online payments through web socket communication, to make the cashier screen automatically and quickly react to payments.
If several online payments are used for a single POS order, they are processed one after each other.
Working principles:
- The POS session web client is not allowed to save online payments on the server. Only the Odoo server, which handles the payment, can save online payments for a POS order.
- The POS session is only responsible for saving the order (especially other payment methods) and the next online payment amount to pay (in case of several online payments) on the server before the online payments are made by the customer, and for displaying the online payment status and the link (QR code) to open the payment page.
That means that modifications that are made after the order is fully paid are not taken into account by the server.
- Before validating an order, the POS session checks with the server if any online payment has been made for that POS order. If the user wasn't aware of one, the validation process is aborted, notifying him.
- The sensitive online payments data is received by the frontend user with RPC to the server when validating an order, cancelling an online payment or receiving a notification through the POS bus (web socket communication).
This data is used to update the cashier data for the specific order.
- No sensitive information is sent through the POS bus (web socket communication).
Indeed, the bus communication is only protected by the name of the channel, and there is no mecanism to prevent several attempts. Therefore, no sensitive information is sent through it, only a notification to invite the local browser to do a safe RPC to the server to check the new state of the order.
- Online payments for a POS order cannot be modified or removed when they succeeded. Checks ensure to never allow an online payment to make the total paid amount greater than the total amount of the POS order.
- If the frontend user clicks on the "Cancel" button of the online payment popup, the order can potentially still be paid online. Indeed, the order will be removed from the server only if it was added only for the online payment flow, and any order that is not paid can be paid on the online payment portal (if the customer has the web link).
This behavior ensures that in a shop, starting an online payment and then cancelling it doesn't prevent the user to close the POS session. And it ensures to don't delete a draft order that is used for other flows, like in a restaurant or when there are trusted POS configs.
Payment portal features:
- The payment portal pages of a POS order are protected with its access_token.
- If the amount of the order has changed when the customer clicks to pay, an error is fired to notify him and give him the choice to continue or abandon the payment.
- An exit_route argument (an URL) can be passed to allow the customer to exit the payment portal at any time (with a button), which could be used for self-order flow.
- A button to go back to the payment page is displayed when an error occurs during a payment transaction, which allows the customer to retry a payment without needing to scan again the QR code.
- If the customer is not logged in in the payment portal (most frequent case), it is considered as the public user partner for the payment flow to don't give him privileged access to sensitive data like payment tokens.
- The accounting process of online payments for POS orders is made in the same way that the pos.payment.method that have split_transactions to True.
- The POS customer of a POS order has no link with the customer making an online payment for that POS order.
- The payment portal is made using the pos.order id and not the pos_reference because the latter is not guaranteed to be unique.
Some tests have been written, especially one that simulates a whole online payment flow starting from nothing, creating an order, requesting an online payment, faking this online payment by doing web requests to the payment portal, then finally closing the POS session to check that there is no accounting issue.
The design of the payment portal is temporary.
closesodoo/odoo#123237
Task-id: 3276404
Related: odoo/enterprise#41776
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Purpose
=======
Make it possible to attract attention to a small section of a text document (e.g. task spec, knowledge article, etc.) via a new "bloc" called "Banner".
Specifications
==============
Add 4 commands in web_editor.
Each command will add a banner of the following types and will come with their associated icons:
- Banner Info: alert-info - info-circle
- Banner Success: alert-success - check-circle
- Banner Warning: alert-warning - exclamation-triangle
- Banner Danger: alert-danger - exclamation
Task-2782426
closesodoo/odoo#120690
Related: odoo/enterprise#41716
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Make it possible to attract attention to a small section of a text document
(e.g. task spec, knowledge article, etc.) via a new "bloc" called "Banner".
Specifications
==============
Add 4 commands in web_editor.
Each command will add a banner of the following types and will come with their
associated icons:
- Banner Info: alert-info - info-circle
- Banner Success: alert-success - check-circle
- Banner Warning: alert-warning - exclamation-triangle
- Banner Danger: alert-danger - exclamation
Task-2782426
Part-of: odoo/odoo#120690
This commit add a new utility method to check if the selection (current cursor
position) starts inside one of the given selectors. This method will be used,
notably, for filtering some commands inside some HTML Elements of the web
editor. Some commands should not be available within certain elements like
table, custom behaviours (knowledge app) or banners (that will be introduced in
the next commit).
Task-2782426
Part-of: odoo/odoo#120690
Before this commit, the o_not_editable class was used as a way to
dynamically set contentEditable on a node. This was little more
than a convulated way to write `node.contentEditable = false`.
Moreover, the o_editable class was not treated the same way and
did not set contentEditable to true.
This commit turns those two classes into markers for contentEditable
values in html. Once those classes are set, the contentEditable
attribute is updated accordingly. It is not updated dynamically
afterwards. For dynamically setting a node as editable or not, use
the contentEditable attribute directly.
Task-2782426
Part-of: odoo/odoo#120690
Prior to this, there was no way to shut an active session you didn't have the
access to anymore or close every active session remotely.
Adding the RevokeAllDevices class, it is now possible to close every open
sessions, including the one you are performing the action on of the account
you are logged into via the Account Security page in the preferences.
This system is based on the principle that every open session uses the password
hash to maintain it. When the hash is computed, salt is added to it to make it
not reversible. Thanks to that salt, it is possible to change the user's
password's hash without changing the password. Therefore, the flow of this
addition is the following :
1. User clicks on the button and uses his passord to confirm identity.
2. User's input is used to check his identity (_check_credentials()).
3. User's input is used to refresh the password hash in the db (_change_password()).
4. User is logged out.
This adds a way to close all sessions remotely and improve user's control over
their account and therefore their security.
task-3191567
closesodoo/odoo#113899
Related: odoo/upgrade#4951
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Steps to reproduce:
- Deliver an SN-tracked product with the Destination Package set (put in pack button also sets this).
- Return that product without setting the Source Package (you can also click "put in pack" which will put the product in yet another pack).
- This already results in two lines with the same SN in the same location, one with +1.00 and one with -1.00 quantity.
- Deliver that product again and put in pack.
- Now there's three lines with the same SN in the same location, two with +1.00 and one with -1.00 quantity.
Bug:
source Package isn't set bydefault when confirming the move_line
we update the stock quantity for that lot_id and Package set to False
the existing quantity has a Package set so it is filtered out and a new
negative quantity is created
Fix:
set the source Package on the return
opw-3179388
closesodoo/odoo#128874
X-original-commit: ca168f7fbcbb8a300a8fa0b46f79a6c116b5aa93
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Steps to reproduce:
1. On website, drop a snippet
2. Type something, than undo it (ctrl + z or click undo button on the
sidebar)
3. On the sidebar, hover over the buttons of "Content Width" and/or
"Height" to get a preview of those actions
4. Perform a redo with ctrl + y.
Explanation:
One can only redo changes when in a state resulting from an undo, that is,
redo is the undoing of an undo. Once new changes are introduced after an
undo operation took place, a redo cannot be performed anymore.
The OdooEditor handles this at the history steps level. If there's a
a history step with state "undefined" (not resulting of undo or redo)
that is more recent than the most recent step with state "undo", a
redo is not possible.
But, before this commit, this was not handled at the current step's
mutations level. The presence of mutations in the current step did not
prevent a redo, and applying a redo on top of those changes could lead to
unexpected results, as the changes resulting from the reversion of undo
step interacted with the mutations performed subsequent to the undo
operation.
The presence of mutations in the current step when about to redo is
possible by previewing changes as described above, as they perform
DOM mutations without committing them into a history step. The same
effect can be achieved by selecting some text and hovering over the
colors of the colorpicker. Theoretically, any asynchronous compound
command (multiple calls to execCommand within historyPauseSteps/
historyUnpauseSteps) will add mutations to the current step without
committing them, while still offering the user the possibility of a redo.
This commit makes sure that mutations in the current step are treated
as an uncommitted draft and are discarded before applying a redo, mirroring
what is done for the undo operation.
task-3339304
closesodoo/odoo#128873
X-original-commit: 6ab6927c0fc4c4a1c838251953a29512dd0d3835
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This commit separates the test that was added together with the "not
move images twice within image wall" fix because it requires additional
fixes for working in 16.0.
task-2990053
closesodoo/odoo#125758
X-original-commit: f4e8ca1eca1193a72a0b1d21cbc4af5093907ca9
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
*: web_editor
During the masonry layout calculation of the images wall snippet, the
image height is used to determine into which column each image is
inserted. Their height is zero until they are actually loaded. Because
of this, the column into which an image is inserted can be wrong.
This becomes more obvious in 16.0 because since [1] the image selection
is lost when moving it within an Image Wall because it is replaced by a
clone when using masonry mode.
This commit makes sure that the images are loaded before taking their
height into account when building the masonry layout.
This involves two changes:
1. By awaiting `wUtils.onceAllImagesLoaded(this.$target)` after the
insertion of each cloned image, we are sure that the reached height of
each column is available before deciding where to insert the next image.
2. Before re-selecting the previously selected image, we need to be
sure that it is loaded. Therefore we keep track of the last masonry
layout operation and await for it. This way, we rely on the await of
the last image as described in point 1.
Additionally, as of 16.0, there is a race condition with
`snippet_option_update`: in some situations, `notify` is called before
`snippet_option_update` is completed, and before the masonry layout is
applied. To make sure it is completed, the whole notify is run within
the mutex through a `snippet_edition_request` event.
To uphold the stable policy, making `mode` async will only be done in
master.
In stable, a new `_modeWithImageWait` is added which is called only
for the situations that causing an issue, and which enables the fix
of the masonry layout.
In 14.0, it is used when computing the layout from `start` and
`addImages`.
In 16.0, it is also used in `notify` when images are removed or moved
around - because masonry clones the images.
In master, it is always applied.
Steps to reproduce:
- Drop an Images Wall.
- Add four images, the first one being taller than the others.
=> The fourth image sometimes appeared below the tall image.
[1]: https://github.com/odoo/odoo/commit/0d43aec24baad6420e0fe150a9c19d33c0b74198
task-2990053
X-original-commit: 9605d9ba7b26885d66e861e0e5c7dff7489031f9
Part-of: odoo/odoo#125758
Since [1] the "Images Add/Remove All" buttons are on top of the
background options in order to appear as the first option for the
"Image Wall" snippet.
This makes the JS related to the handling of the options of that
snippet created twice: once for the buttons above and once for the
options below.
Because of this, events are registered by both instances and they both
get notified on option update. Therefore, when an image is moved, it is
moved twice instead of once.
This commit differentiates both instances, and makes the one that
handles the "Add" and "Remove All" buttons be the only one that works on
the images.
In stable the differentiation is done with conditional statements.
In master the instances should be of distinct classes.
Steps to reproduce:
- Drop an "Images Wall" block.
- Switch the "Mode" option to "Grid" instead of "Masonry".
- Select the wine glass image in the third column.
- Click on "Move to previous".
=> The wine glass image ended up in the first column because it was
moved twice.
This commit also fixes a typo in the `reoder_items` name introduced
by [2].
[1]: https://github.com/odoo/odoo/commit/b6494fcf284edcddaa36b5fcfd407a6d7186fbd7
[2]: https://github.com/odoo/odoo/commit/e8713dc078b5c1799917f238a4c32b4289aceb8a
task-2990053
X-original-commit: f8724b55162b2550734dbe6e0454c406d6e4241c
Part-of: odoo/odoo#125758
Inside the Images Wall snippet, images are dispatched to columns
depending on the height already reached by each column. This computation
relies on a sub-pixel height which leads to a confusing behavior.
This commit rounds the sub-pixel height to a visible pixel height to
avoid the confusion.
Steps to reproduce:
In the default images of the Images Wall snippet, the third image (sign)
is one pixel taller than the other ones.
- Drop an Images Wall snippet.
- Select the "sign" image.
- Move it to the first position.
(Because of another bug involving a race condition with the loading of
images, you might observe a different behavior. Move to first position
again to recompute the layout several times.)
=> The compass image moved to the first column.
task-2990053
X-original-commit: d0c15abd17e151a8861cc950116b11111d694bb3
Part-of: odoo/odoo#125758
When using the previous button in an image wall, the image wraps around
but skips the last position.
When using the next button in an image wall, the image does not wrap
around.
This commit fixes this inconsistency by using the same behavior as the
one in 15.0 since [1]: wrap through all positions in both directions.
Steps to reproduce:
- Drop an "Images Wall" snippet.
- Add 6 images.
- Select an image.
- Click repeatedly on "Move to previous".
=> The image wraps around all positions except the last one.
- Click repeatedly on "Move to next".
=> The image does not move anymore once it reached the last position.
[1]: https://github.com/odoo/odoo/commit/3931f0a67f904daea6c891a3a80aa984760a7682
task-2990053
X-original-commit: 054f480376e8d08d1582cedd6caec6455be828e2
Part-of: odoo/odoo#125758
This PR supports the redesign of website_forum with additional features supporting
searches, tags, moderation, and links.
It includes slightly modified version of the commits in PR #120982 and additional
feature and refactoring tasks.
See details in each commit.
Task-3083657
Task-3316555
closesodoo/odoo#123709
Related: odoo/enterprise#42388
Related: odoo/upgrade#4764
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Elisabeth Dickinson <edi@odoo.com>
Co-authored-by: Florian Charlier <flch@odoo.com>
Co-authored-by: Lopes Marc (loma) <loma@odoo.com>
# forum.post
search_can_view: improve readability
convert_answer_to_comment: remove unused parameter
unlink_comment: extract operations from loop; early return
# forum.post.vote
write: simplification upvote computation
_check_karma_rights: upvote is a flag
# ir_attachment
_can_bypass_rights_on_media_dialog: grammar
# website_forum controller
questions: simplifications
_prepare_open_forum_user: 'my_profile' isn't used since c8c8eb3d
question_edit_answer: avoid failure on unmatched `answer`
Usage of f-strings when multiple string concatenation or type cast
removing ask_hide which seems really dead
Also, various changes to follow PEP8 for imports and indentations.
Task-3271492
Part-of: odoo/odoo#123709
If we don't do it, the dropdown is broken with slightly longer words
in description if we use icons and another field, such as in
`website_forum` for posts.
Task-3316555
Part-of: odoo/odoo#123709
Purpose
=======
1. The post "activity" date shown on a forum's list of posts is not a
great user experience as it is seems to be updated for writes on the
original post and not, e.g., when a reply is added.
2. Remove bumping on social sharing.
As we are not in 2015 anymore, sharing is not a relevant "activity"
for the post. This is illustrated by the fact that `allow_bump`
could not be updated with the client, and the "default" "target_type"
is not found in the codebase anymore. We clean that here.
Specifications
==============
- Drop bump_date and use last_activity_date instead of write date
to log activity
- Update post last_activity_date whenever a reply or a comment is
added to the original post or one of its replies
- Sort posts lists by `last_activity_date desc` by default
- Use luxon.js library to render the bump_date field as a
`relative datetime`(e.g.: 2 days ago, 1 hour ago...)
Task-3349374
Task-3316555
Part-of: odoo/odoo#123709
Co-authored-by: Florian Charlier <flch@odoo.com>
This commit enables user to
* Track, show, and use the forum's
* Most commonly used tags
* Unused tags (for the moderators)
* Search tags
* Get an improved "no results" experience with tags
Task-3349375
Part-of: odoo/odoo#123709
* = website_slides_forum, website_mail, website_profile
In `website_(slides)_forum`:
All forums page:
Course forums are displayed on the same level as regular forums (with
a tag "Course" to differentiate them).
We don't see this page if there is only one forum.
This new design resembles that of Discourse with a table for the list
of questions and a sidebar on the left.
Other pages such as the Tags, FAQ, and Moderation pages have also been
revamped. Some of the functionality comes in the following commits.
Notes: The table rows have been made fully clickable, but by doing so
other clickable or hoverable elements lose their function.
In order to counteract this, a `position-relative` and
`z-index-1` classes are added to them.
The image_url definition wasn't working properly: When a user didn't have
and avatar, a placeholder with their initial is generated. But it did
not take the size option defined in the widget. This has been
corrected by changing it to `request.website.image_url(...)`
In the posts' page, the answer box now comes up from the bottom of the
screen.
In the FAQ pages, the accordion has been replaced by BS accordion
component using `accordion-item` instead of cards. The web editor
however is still using the old system.
In `website_mail`:
A new template for the follow button has been created in order to
redesign it for the forum without disrupting this element in other
modules (ie: website_mail, blog).
Task-3083657
Part of Task-3316555
Part-of: odoo/odoo#123709
Co-authored-by: Florian Charlier <flch@odoo.com>
Since [1], the discuss notification handler is no longer
in the core folder. Due to this change, the livechat was
not processing the bus notifications anymore. This PR fixes
this issue.
[1]: https://github.com/odoo/odoo/pull/128593closesodoo/odoo#128849
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
The aim of this commit is to revert a previous commit that introduced a warning on duplicate invoice.
This revert is done because actually different invoices can share the same reference which is not the case for the bills. The field reference was used as a trigger for the detection of the duplication, which causes issues for many cases for example for subscriptions, where the reference stay the same for all the invoices of the same subscription.
Previous to this commit:
warning for vendor bills and invoices
After this commit:
When uploading duplicate vendor bill -> Warning
When uploading duplicate invoice -> NO Warning
closesodoo/odoo#128848
Task: no_task_id
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Clicking on chatter notification from the messaging menu should
either open chat window or form view, depending on whether the
discuss app is closed or open respectively.
Before this commit, when discuss app was open and user clicks on
messaging menu item related to chatter notification, it was opening
the chatter in discuss app. Although it works, some features seem
missing, such as lack of chatter-specific features, and missing
entry in the app sidebar. The discuss app is designed to work
only on `discuss.channel` threads, therefore chatter threads should
never be shown inside this app.
This commit fixes the issue by ensuring that all opening of chatters
from the discuss app opens the form view.
closesodoo/odoo#128809
X-original-commit: 94c12dd231212e2e52b626a380344623c8627d7c
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Prveiously the "Edit in Website Builder" button was not shown for terms
and conditions if website is installed, it was shown only if the
website_sale module was installed. This commit fixes that.
task-3342876
closesodoo/odoo#127735
X-original-commit: 079704a2a5ed42ed774318fd8520d108f17222bd
Related: odoo/upgrade#4912
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Current behaviour:
After archiving the public pricelist (14.0 to 16.1,
as 16.2 does no longer have a public pricelist),
when creating a new pricelist, it replaces the previous
pricelist with all partners.
1 Second pricelist
2 First pricelist
Expected behaviour:
New pricelists should go after the previous one
1 First pricelist
2 Second pricelist
Steps to reproduce:
1. Go to settings, activate Pricelists
2. Head over to Sales->Products->Pricelists
3. If applicable, archive the public pricelist
4. Create a new pricelist (named 'First')
5. Create another pricelist (named 'Second')
6. Go to Contacts, select any contact
7. In Sales & Purchase see Pricelist
8. Second pricelist is set, should be First
Cause of the issue:
_order is set to "sequence asc, id desc"
Since new pricelists have a sequence of 16 by default,
new pricelists (with a higher id) get placed first.
Fix:
New pricelists without a sequence number get sequenced based on the
highest sequence number in existing pricelists
opw-3282880
closesodoo/odoo#121441
Related: odoo/enterprise#43591
Signed-off-by: Antoine Demany (ande) <ande@odoo.com>
This PR introduces a mixin, `MailTrackingDurationMixin`, that can be added
to a model with a many2one field. It computes the time a record spends in each
value the many2one field takes and stores it in a Json field
(`duration_tracking`).
The primary use is with a new field, the StatusBarDurationField
(`widget='statusbar_duration'`), to compute and display the time a record has
spent in each stage in the form view statusbar. This field inherits from the
StatusBarField.
To specify on what field the computation has to be based, the model that inherits
from this mixin has to specify `_track_duration_field`. (e.g.
`_track_duration_field = 'stage_id'`)
Computation is based on `mail.tracking.value` messages, so tracking has to be
activated for that field.
In the widget, time is shown using a luxon Duration object. "narrow" specifies that time is
expressed with one character and luxon takes care of translations.
Here, we implement the mixin and the field for `crm.lead` and `project.task`.
https://github.com/odoo/enterprise/pull/38275 implements it in `helpdesk.ticket`
Task-3032773
closesodoo/odoo#108554
Related: odoo/enterprise#38275
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit implements the `mail.tracking.duration.mixin` with the
`statusbar_duration` widget for `crm.lead` and `project.task`.
The goal is to compute and display how long a record has spent in each stage in
the statusbar of their form view.
Task-3032773
Part-of: odoo/odoo#108554
This commit implements a new widget in mail, `StatusBarDurationField`. Purpose:
seeing how long a record has spent in each stage in a form view.
It is implemented for records with a `many2one` status field and gets the data
from the `duration_tracking` field of the record. `duration_tracking` is computed
by adding the `mail.tracking.duration.mixin` to a model.
Time is shown using a luxon Duration object. "narrow" specifies that time is
expressed with one character and luxon takes care of translations.
Task-3032773
Part-of: odoo/odoo#108554
Maximilien (malb)