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
This commit implements 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 the StatusBarDurationField
(`widget='statusbar_duration'`), to compute and display the time a record has
spent in each stage in the form view statusbar.
To specify on what field the computation has to be done, 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.
Task-3032773
Part-of: odoo/odoo#108554
When specified, restrict the promotion to customers using said pricelists
task-3049956
closesodoo/odoo#107656
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: Lucas Vermulen (luve) <luve@odoo.com>
Co-authored-by: Morgane Demesmaeker (edm) <edm@odoo.com>
To reproduce (16.1 and >):
1. Install PoS and enable Six payment method
2. Create a payment method using Six
(the IP can be set randomly, it does not matter here to have the
terminal connected)
3. Add the Six payment method to the PoS configuration
4. Open the PoS session
-> The "Send balance" button of the navbar is totally missing
For now, the manifest try to load the assets at:
`pos_six/static/src/app/**/*`
But, since 16.1 the file location for the XML and JS is misplaced in
`/static/app` instead of `/static/src/app`,
as such, the template file is missing.
opw-3422166
closesodoo/odoo#128813
X-original-commit: 859390a42cb8b2b10b017dca2ea5734cd8915c49
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Signed-off-by: Loan Sens (lse) <lse@odoo.com>
When user archive a slide from a course and try to access route
'/slides/embed/<int:slide_id>' of that particular slide, user get the error.
steps to reproduce:
1. Go to Website and click on courses menu.
2. Open a course and archive a slide in it.
3. Then go to '/slides/embed/<int:slide_id>' route.
4. Access that particular slide that you have archived in route.
5. The error will occur.
Applying this commit will fix this issue.
sentry-4025579653
closesodoo/odoo#128797
X-original-commit: c097112109fb2de003242bda89e10e656236b774
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this change, if you tried to extend the event configurator to add new fields,
it was not possible because only the two defined fields (event_id and event_ticket_id)
were updated.
After this change, all fields that are returned in the closeInfo.eventConfiguration
will be updated.
This is useful to avoid redefining the _openEventConfigurator function again and
to make this functionality more extensible.
closesodoo/odoo#128792
X-original-commit: 0002d38dd074a537568b4aba4588b285c06356d9
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Splitting the cached revealed a missing cache invaldation.
The cache invalidation added a a query in test_related_fields
The query can be avoid by not updating the xmlid if it is not useful.
closesodoo/odoo#119813
Related: odoo/enterprise#42527
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
The cron hr_presence will write hr_presence_last_compute_date on company
leading to an invalidation of the cache.
This commit makes the invalidation based on a list of field.
This may break some non tested behaviour, will be a good opportunity to
add test if any bugfixes is linked to this change.
Part-of: odoo/odoo#119813
One of the main issue with ormcache is that the invalidation clears
everything, meaning that some value, slow to compute but with a long
lifetime, can be removed from the cache because an easy to invalidate
value is cleared, like after writting or creating a product has an
example.
Most example in the code will try to invalidate the cache of the models
doing something like `env['ir.qweb'].clear_caches()` but it is
finally equivalent to `env.registry.clear_cache()`, and cross worker.
The idea is to have multiple cache, maybe with specific sizes for a
specific purpose.
Having one per model is maybe a bad idea because it will be difficult
to size the LRU correcly, and it is too dynamic. Checking invalidation
may be expensive.
The proposed solution is closed allow a limited number of named caches,
using onse sequence per cache. This is actually close to the
cache_longterm.
We want to discourage using a specific cache for one use case in
the buisness code. Adding a cache shouldn't be something easy, doable
in stable.
Note that we could also change the invalisation mecanism using an
insert only table. We an check the sequence of this table, but also
fetch all invalidation messages.
Another possible improvement, especially if we have more than x cache is
to have a global sequence, checking signaling would mean to check the
main sequence, and only the other ones if the main one changed.
Note that this poc is inspired from the long term cache but not all
use case where applie yet.
Part-of: odoo/odoo#119813
A cache invalidation was triggered when displaying the settings page
because of a write on ir.property
return call_kw(request.env[model], method, args, kwargs)
File "/home/xdo/osrc/master/odoo/odoo/api.py", line 461, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "/home/xdo/osrc/master/odoo/odoo/api.py", line 448, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "/home/xdo/osrc/master/odoo/odoo/models.py", line 6689, in onchange
record._onchange_eval(name, field_onchange[name], result)
File "/home/xdo/osrc/master/odoo/odoo/models.py", line 6403, in _onchange_eval
res = method(self)
File "/home/xdo/osrc/master/enterprise/sale_stock_renting/models/res_config_settings.py", line 17, in _onchange_padding_time
self.env['ir.property']._set_default("preparation_time", "product.template", self.padding_time)
File "/home/xdo/osrc/master/odoo/odoo/addons/base/models/ir_property.py", line 203, in _set_default
prop.write({'value': value})
This commit will avoid this by checking the current value.
Part-of: odoo/odoo#119813
Since this commit [1], when clicking on an image that is not a link and
then clicking on an image that is a link, the first image that is not a
link becomes a link.
This issue occurred because we were triggering
'activate_image_link_tool' in 'toggleLinkTools' before the options for
the selected image were ready. As a result, 'activate_image_link_tool'
was being triggered on the previous image (the one that is not a link),
causing it to become a link.
To fix this, we now only trigger 'activate_image_link_tool' if the URL
input needs to be focused (e.g., when clicking on the "edit link" button
in the image popover).
Steps to reproduce the bug:
- Drag and drop a "Columns" Snippet onto the page.
- Click on the image of the first column.
- Click on the button to create a link in the options of the image.
- Type "/" in the url input.
- Click on the image of the second column.
- Click on the image of the first column.
- Click on the image of the second column.
- Bug: a link is added on the image of the second column.
This commit also modifies the "link_tools" test to avoid this bug
reappears.
[1]: https://github.com/odoo/odoo/commit/11ee7d5520c3a14a381b3f5b973114670f1e2edb
task-3422238
closesodoo/odoo#128806
X-original-commit: fef32aa339177a2ca008ab988cb0ac0a670c110c
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Changing the value of `allow_out_payment` when it was already set to
False would trigger an AccessError.
closesodoo/odoo#128800
X-original-commit: 74f15362beaf967cefe509d5b9b66c5436bb661b
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Currently when unlinking moves, we check whether the dates of these
moves are not before a lock date. If so, we show an error to the user.
However, if the move is not posted, we have no reason to show an error,
since unlinking an unposted move, even before a lock date, is a valid
operation. This change only checks the lock date for posted moves.
opw-3305506
closesodoo/odoo#128701
X-original-commit: 1d18a5e4aaa254eba2b12cf1bae19ac2cc4c3c6f
Related: odoo/enterprise#44199
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
Before this commit, a forward-ported fix regarding the display of the
arrow separator in daterange fields has been incorrectly adapted to fit
conflicting changes, and the separator does not appear in readonly with
both date values set.
This commit fixes that by restoring the proper conditions.
closesodoo/odoo#128509
Signed-off-by: Géry Debongnie <ged@odoo.com>
before this commit, the total amount of the order
is not displayed in pos.order.report tree view.
* point of sale -> Reporting -> Orders
* switch to pivot view
* click on any pivot cells
* in the tree view, no information about the order amount
after this commit, the total will be shown to
the user in tree view.
closesodoo/odoo#126003
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
before this commit, on opening the form of
report.pos.order model the breadcrump is
shown as report.pos.order(1) , ie, model_name id
after this commit, the rec_name (order number) is set
for the model and clean breadrcump will be shown
Part-of: odoo/odoo#126003
During the forward port of the following PR:
https://github.com/odoo/odoo/pull/127730, the event was not passed to the input
event handler, which causes an error when the user tries to enter a new value
for the the other payment methods.
This commit appropriately passes the input event to the handler.
closesodoo/odoo#128801
X-original-commit: 70ea3d8998d873a7649f57af3bbd8aa82daac6ad
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. Edit the route "Dropship Subcontractor on Order":
- Open the Buy rule:
- Propagation of Procurement Group: Leave Empty
3. Create three products P1, P2, P_comp:
- Storable
- With a vendor (V1, V2, V_comp)
- P_comp's routes:
- Dropship Subcontractor on Order
4. Create a BoM:
- Product: P1
- Type: Subcontracting
- Subcontractors: V1
- Components: 1 x P_comp
5. Repeat step 4 with P2 and V2
6. Create and confirm a PO:
- Vendor: V1
- Products: 1 x P1
7. Repeat step 6 with V2 and P2
8. Open the purchase orders list
Error: There is only one PO with V_comp. It contains 2 x P_comp and
the dropship address is P1. This is incorrect. There should be two
PO, one for P1 and another one for P2
When confirming the PO, a MO is created (subcontracted) and then the
system creates and processes a procurement for the component.
Because of the component's routes, it leads to the `_run_buy` method.
It will check whether a PO already exists or has to be created. To do
so, it creates a domain based on few criteria, such as the value of
`dest_address_id`:
https://github.com/odoo/odoo/blob/6d28c9c2e5ea3e9a3b8a872627a411bbfe2f2a59/addons/mrp_subcontracting_dropshipping/models/stock_rule.py#L17-L21
But here is the issue: `partner_id` is not defined.
OPW-3370648
closesodoo/odoo#128791
X-original-commit: 094e45d120c525d8b65bca7c0d10d10dbb6383cd
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Steps to reproduce the bug:
- Create a storable product "P1":
- Unit of measure: KG
- Bill of Materials for 1 "g" of "P1":
- Component: 1 unit of "C1"
- Route: Manufacture
- reordering rule: Min 0, Max 0
- Create a Sales Order with 510 g of "P1" and confirm it.
- A Manufacturing Order for 510 g of "P1" will be created.
- Create a second SO with 510 g of "P1" and confirm it.
Problem:
The quantity in the MO will be updated to 1.02 g of P1 instead of 1020g
"Whenever we update the quantity, the `_run_manufacture` function is
triggered. Consequently, we use the `product_uom_qty` from the
manufacturing order to calculate the remaining quantity. However,
this field is computed, and it converts the quantity into the unit of
measure of the product, rather than that of the manufacturing order.
https://github.com/odoo/odoo/blob/3b801a6d48f1feffd1b87a7d54731ab58e8d63e9/addons/mrp/models/stock_rule.py#L75https://github.com/odoo/odoo/blob/5118d248ccf16fe4d2703c2a64e0267f783a56d1/addons/mrp/models/mrp_production.py#L171-L172
Opw-3410254
closesodoo/odoo#128776
X-original-commit: 04371c0ec777cede50e940f45064f86cb4cb8964
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Issue:
Expenses linked to an SO are counted as 1 hour of timesheet linked
to the SO.
Steps to reproduce:
- Install Sales, Timesheets, Expense
- Create an SO and sell a service that creates a Task > Confirm
- Log some timesheet on the task (3h for ex.)
- Create an expense related to the SO, approve it and generate the
journal entries.
- On the SO, the smart button shows 4h clocked, and when you click
on it, the expense line is showed, which shouldn't be the case.
Cause:
Incorrect domain taking the `order_line` without filtering on the
fact that they may be expenses or not.
Fix:
Specify the domain on the action to exclude expense lines.
Affected versions:
- 14.0 - count is correct, only action is showing more lines
- 15.0 - same as described in the commit msg
- saas-15.2
- 16.0
- saas-16.1
- saas-16.2
- saas-16.3
- master
opw-3302460
closesodoo/odoo#128764
X-original-commit: 7ee275a4a454898989d15f42941f4a1bb7a48db9
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
David Beguin