- remove utf-8 encoding header in python scripts
- add missing odoo license and xml headers
- alphabetical order for imports
- rename files according to model names (+ split if needed)
- remove unused variables in tests
closesodoo/odoo#111748
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit, when editing a form view, when editing a html field,
the status indicator buttons (the save and discard buttons) didn't show
up until a click outside the html field was done (change event).
Now, the status indicator buttons shown as soon as the input field is
edited (input event).
This is was already done for the other fields in [1].
[1] : 0b2d82282d7f656a9177158fd6117cc2e7a1b4d4
task-id 3147130
closesodoo/odoo#111663
X-original-commit: f56e3bca2456f04616982a9a0e77b8d4c5a0abff
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Before this commit, the bus worker would not subscribe to any channel
if the `_start` method was called before the socket was closed after
calling `_stop`. This is due to the fact that the close handler is
supposed to clean the last subscription when the socket is closed.
In this case, the handler is never called and the subscription is
considered already doned which is not the case.
closesodoo/odoo#111405
X-original-commit: 9e32c900e922674b4423407089cee58848ecdea1
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
before this commit,
the wording of the visibility options can be quite confusing.
after this commit,
- Visibility has been updated
- Visible to all: I see those training to the public
- Visible to logged users only: I am a B2B business, and I do not want the
public to see what I offer + the pricing I have on those
- Visible to members only: I am a school, I want to invite my students but
external visitors should not be able to enroll
- Move the field above the "enroll policy"
- Enroll Policy has been set to invite when visibility is set as a Course
attendee and hide the enroll policy
task- 2862003
closesodoo/odoo#102085
Related: odoo/upgrade#3946
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
* the referenced commit didn't remove the used config parameter
* it's quite dumb to stop considering the parameters of a db out of nowhere
and force the usage of a specific template when a lot of databases were potentially
using another one.
This commit makes sure the parameter is still used when defined.
It is set to the forced valued in the data by default anyway.
task-2880950
closesodoo/odoo#97565
Related: odoo/upgrade#3965
Related: odoo/enterprise#30168
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This commit reworks the display of the default SO values
in the settings to make it clear to the users what those
settings impact and that they are overridden by the quotation
template when specified.
task-2880950
Part-of: odoo/odoo#97565
Allow the feature activation by company instead of database.
It wasn't logical to specify the days by company but enable/disable
the feature by database.
task-2880950
Part-of: odoo/odoo#97565
When there is a problem in the peer to peer network where we try to
recover a connection, retry with exponential backoff instead of
potentially spamming the server indefinitely.
task-3164011
closesodoo/odoo#111802
X-original-commit: fd97295c9cf8b1b0c800f407bb5f538f78cc2665
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, the image dimensions were not properly converted
when converting HTML for e-mails.
opw-3144322
closesodoo/odoo#111793
X-original-commit: 1d5c8c9adf18aded19d945cd9b0f72eb9b8bbc72
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The custom table selection was not limited to the editable area bounds,
which means we could end up styling a table as selected, which did not
belong to the editor's scope. This sometimes happened when Firefox
triggered a selectionchange event during the instantiation of the editor
and the selection happened to be in a table outside the editor.
opw-3150654
task-3166078
closesodoo/odoo#111779
X-original-commit: d51aab54775ed541d7955cee032aceed143d3a08
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When we change something in the DESIGN tab of mass_mailing, we edit a
stylesheet. This means we need to flush the rules cache so
convert_inline applies the new rules in its conversion.
opw-3114599
closesodoo/odoo#111778
X-original-commit: 4ebf106e65ae4901c03c76606a05d8cd2e0790d7
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The CSS rules cache for convert_inline was stored on the edited
document, which is problematic since OWL destroys the document where we
used to just hide it (eg, when switching tabs in the form view).
X-original-commit: d432ebbddae7192eca7215a8489abb3ad91a45f2
Part-of: odoo/odoo#111778
When converting html for emails, contenteditable attributes should be
removed.
X-original-commit: 9b4cff9f6ab8e1738f3fc486875f9e4ab16cea9d
Part-of: odoo/odoo#111778
The video command is supposed to be forbidden in tag-sanitized fields. A
field gets tag-sanitized if sanitize_tags is true or by default if the
field is to be sanitized (and sanitize_tags is undefined). Before this
commit, the video command was not forbidden if sanitize was true,
regardless of the value of sanitize_tags.
closesodoo/odoo#111777
X-original-commit: 96b4edfd40a3c131a7709986fc3e1599c177f986
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The images command was disabled in html fields if the field's view
didn't define the `allowCommandImages` option. This allows that option
to be undefined so it can be overridden by its default value when such
is the case. Before this commit however, the option was always set to
`false` when undefined (the opposite of the expected default value).
opw-3134660
X-original-commit: bf0f17d2c9f19b88d4db2f4e15423ec0c831167f
Part-of: odoo/odoo#111777
After this commit GST treatment will be only assigned to Indian invoices/bills.
closesodoo/odoo#111738
X-original-commit: 6ede766eab05b621bfee6e6af259c7d2d0bfbd94
Signed-off-by: Josse Colpaert <jco@odoo.com>
Following the DateV SKR04 standard, we should not use the
automatically created codes for these accounts.
So we have to create them by hand to specify the code.
closesodoo/odoo#111801
X-original-commit: 59ac0ef1b67387a8400226bf9f9382ea804dce3f
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
Before this commit, when using express checkout, the shipping address
was requested only if the technical module 'delivery' was installed.
Now, over express checkout, the shipping address will be requested if
the sale order contains products that aren't services.
task-3149536
closesodoo/odoo#111796
X-original-commit: 9c16e83336b042ab77c267607ac43e0ef0db9997
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Current behavior:
When making a refund of an order in the PoS, the cost of good was
computed as if the refund was a classic order.
Steps to reproduce:
- Make sure you are in anglo-saxon accounting
- Create a category that use AVCO and automated valuation
- Create a product with a cost of 10€ that is part of the new category
- Create a PoS order with the product
- Refund the order
- Close the session, and check the accounting entries, the cost of good
sold is 20€ instead of 0€
Note: this fix needs you to set the return picking type in the Operation
type of the PoS
opw-3149324
closesodoo/odoo#111794
X-original-commit: e226bd3651c38eb4cb1983db0143a0916b3ae7db
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Mail.message holds a 'message_type' selection field allowing to categorize
the usage of the message: email (incoming emails), comment (user generated
input), notification (system generated input) and user_notification.
This one indicates the message (or mail) targets some specific recipients
and has notably specific display tweaks, to avoid bloating the chatter.
In this commit we fix category of some emails, setting as notifications
when it has no generic usage on a given document.
Task-2710804 (Mail: Clean MailThread API)
closesodoo/odoo#111781
X-original-commit: 82374eefd536a1090be5a0845956a0d7cf493cb0
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In the list view of Mass Mailing Analysis, there is a button to create a
record that does nothing and a button to delete some that raises an
error
Steps to reproduce:
1. Install Email Marketing
2. Open Email Marketing
3. Go to Reporting and trigger the list view
4. A create button is present but doesn't do anything and deleting a
record raises an error
Solution:
Change the access rights on `mailing.trace.report` to only allow read
Problem:
`mailing.trace.report` is a view so we cannot create/delete them
opw-3141895
opw-3128595
closesodoo/odoo#111757
X-original-commit: 003bbfa54a06f31b2caff26aa994a34103beed59
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
https://github.com/odoo/odoo/commit/fa1b4f14257ca04c85c7541fd94b19dff939626c
caused an issue when a user doesn't have the `hr.group_hr_user` and
has the `hr_contract.group_hr_contract_employee_manager` group.
A user who doesn't have `hr.group_hr_user` can not have access to the
`hr.employee`, but has access to `hr.employee.public`. The
problem is that `hr.employee.public` doesn't have the `contract_id`
field.
opw-3148092
closesodoo/odoo#111752
X-original-commit: fa6fea0ddce67ae9a3a4244b91c2f1ea79cf3d6d
Signed-off-by: Kevin Baptiste <kba@odoo.com>
In 16.0, at 6a42ec7c73
an error was introduced redirecting users to the configuration panel
when clicking the 'sync' button for extenal providers in calendar.
This simply replaces that call with a redirect to an authentication url
received from the back-end.
task-3131128
closesodoo/odoo#111392
X-original-commit: 0574c18acd70c3fe52cdb5cbe563ffa02f5f5ad3
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Thiry Renaud (reth) <reth@odoo.com>
This allows the tour manager to attach an event handler
that listens to the "AutoComplete:OPTION_SELECTED" event from
components that utilizes AutoComplete, and if that so happens,
the tour can proceed to the next step.
This change is proposed because of the following bug report:
> [aju] https://watch.screencastify.com/v/UBGeNfXEJmCvE963VSnk
> planning onboarding tour > creating a resource on the fly by hitting
> Enter should validate the step
closesodoo/odoo#111798
X-original-commit: dbccea9a983b3a92fe9a299e4c8704158c7019ae
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
**Current behavior before PR:**
Even when the "drag-handle" is already hidden (since the field is already readonly),
the items of x2m field can still be resequenced by the user.
**Desired behavior after PR is merged:**
User should not be able to resequence the list items when the list field is already
readonly.
**Solution**
If a shown list is representing a x2many field, it makes sense to prevent
resequencing when the field is "readonly". However, the list is oblivious
of that property unless we force it, therefore we introduce the "readonly"
props to the list renderer.
Note that a heuristic was tried to compute "resequenceability" based on
the "editable" property, but that is rather difficult if not impossible.
Also note that "readonly" defaults to "false" to be compatible with the
current situation where the list is rendered -- list view, field, select/
create dialog -- which by default, the items can be resequenced.
closesodoo/odoo#111797
X-original-commit: 7682a5c87b8e2f59a4c277143d6054adb40edef9
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since https://github.com/odoo/odoo/pull/106015, we override a few project actions in `sale_project` to add a context key
allowing to search SOLs by their partner's name. However, this override is not taking the existing context from project
into account and removes it.
This commit restores that context by adding it in the action overrides.
closesodoo/odoo#111789
X-original-commit: 391152f53fe499aa41d4f4fef35c4462f0c1cce5
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Since https://github.com/odoo/odoo/pull/106015, the action `project.action_view_my_task` contains a domain
to filter on the current user's tasks. The default filter that was previously used
to achieve the same purpose is therefore no longer necessary, but was forgotten because of
another bug that removed it when `project_sale` is installed.
This commit removes this filter.
X-original-commit: b908425f886beeee5959313c3b92b546635ee110
Part-of: odoo/odoo#111789
Reproduction:
1. On Odoo 16, install Sales
2. Go to Sales -> Configuration -> Quotation template
3. Click the example “4 person desk”
4. In the “Lines” and “Optional Products” tabs, the translation button
is not show in the Description field
5. In Odoo 15, it shows the translation button
Reason: 1. In text_field.xml, the translationButton is not in the same
div element. This causes the translation button is hidden when in the
tree view. This is the case of the Optional Products tab
2. For the case of Lines, another reason causing this issue is the use
of widget “section_and_note_text”
Fix: move the translation button to the same div element with the
textarea in text_field.xml; remove the widget “section_and_note_text”
from the Lines tab. Also added a test for the text field translation
button
The adding of div:
https://github.com/odoo-dev/odoo/commit/98e94d45fd6176d7afdcf682c10ce8894f86915a
Rewrite of Text Field js:
https://github.com/odoo-dev/odoo/commit/32bc28aa665c479e31a40afffca2f03f6f2cc805
Rewrite of section_and_note:
https://github.com/odoo-dev/odoo/commit/5a21823f4364d6db407d48178435de041b157b44
An community PR for the translationButton by niyasraphy (same change):
https://github.com/odoo/odoo/pull/111291
opw-3078122
closesodoo/odoo#111763
X-original-commit: 99a23902bd2002099322b5c36fac94c8bd500951
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Co-authored-by: niyasraphy <niyasraphyk@gmail.com>
In the Sales dashboards, click on any of the "Top *" link.
=> in the list view, there are more records than it should be.
Quotations and cancelled records are displayed
Follow up of 0fa2510
closesodoo/odoo#111762
X-original-commit: 575be2a4c2d48d5cdd3babb6b80759cf02ef23c6
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
In the Sales dashboards, the product quantities (cells B43:B52) are
displayed with the automatic pivot format which displays floats with
decimal.
If the product is a chair, it's weird to see the quantity ending with ".0"
Units
Office chair 11.0
Even if some unit of amounts can be expressed with decimal values,
we decided to round the amounts in the dashboard by forcing
the integer format.
X-original-commit: bd029041a82278a8dc7cf1b363e87c70845acd3a
Part-of: odoo/odoo#111762
In the Sales dashboards, all "Orders" columns in every "Top *" tables are
wrong.
They count the number of report records (~ sale order lines) but
some are part of the same order. For those cases, the order is counted twice.
Task 3166898
X-original-commit: f3e80f52e96ed3e2b48157467dcf3aef441e6455
Part-of: odoo/odoo#111762
To reproduce the issue:
1. Install [Inventory], [Purchase] on Apps
2. [Settings]>[Inventory]>[Storage Locations]: enable
3. On [Purchase], Create. 'Deliver to' field is ill-positioned
Desired view: use the full width of the row
Applicable versions: 16.0 - master
opw-314167
closesodoo/odoo#111759
X-original-commit: 46700f12b0b4e64029bccf3abb791fe95400331d
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Lee, Hansun (hale) <hale@odoo.com>
On the `/forum/<forum>/tag` page, since the update from BS4 to B5, the
box to subscribe supposed to be shown when hovering a tag is not shown
anymore.
This is because in BS4, `col-md-3` was bringing the `position:relative`
css property but it's not the case anymore in BS5.
The `.o_forum_tag_follow_box` which is in `position:absolute` is
therefore not working as expected.
It is actually shown, but the user can't notice it as it's shown at the
very bottom of the page below the footer (you can see the scrollbar size
being changed).
closesodoo/odoo#111751
X-original-commit: 9a45860e9df1e24760ae5ba45faee4a67dbfc80d
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce:
- install Stock
- Go to Inventory > Delivery Orders > Configuration
- Activate Show Detailed Operation
- Create a delivery order and set the delivery address
- Create a detailed operation
- Save
- Print the delivery slip
- The delivery slip don't have the delivery address
Bug:
There are 2 flows to create `stock.move` from a delivery order:
1- Create it directly from the operation tab:
* In this case `stock.picking.onchange_partner_id` handles the
`partner_id` field of the `stock.move`
2- Create a detailed operation then the move is created in `create_move`:
* There is nothing handling the assignation of the `partner_id`
field of the `stock.move`
* This creates an issue as `should_print_delivery_address` expects
the `stock.move` to have its `partner_id` set to print the
delivery address on the delivery slip
Fix:
Set the `partner_id` in `create_move`
OPW-3145779
closesodoo/odoo#111740
X-original-commit: 6bea6d99050746bfa8a70bbfc8975090ab47fdbe
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
The text and the image were overlapping in the digest tip about "Tip: Speed up
inventory operations with barcodes". This solves the problem.
Technical note: actually, the layout has been broken in 15.2 because the image
has been updated with another ratio (from that version the CDN is used instead
of an image on the server). To support more client and as it looks ok even on
small device even with the 2 columns (text-image), we have used a table for the
layout.
Task-3097167
closesodoo/odoo#111737
X-original-commit: 7b6c82f2bc0f0d3931d6bd7c571cf4854eb4bd86
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Before this commit, if a link to a page was not correct because of a
case mismatch, it would simply land on a 404 page.
While it's correct, as URL are case sensitive, it leads to a few bad UX
flow at the admin/editor level:
- Create a link in your page (on a text or a button eg), type an URL
which does not exists (to create it after) like /Page
- Click on the link/button you just made, you are redirected to /Page
which display a 404 with the "Create page" option (correct)
- When you click on that button, it will actually create a page with
/page URL, leading to a mismatch between the URL you created and the
page URL.
Your link/button will still lead to a 404 URL as it points to /Page.
Since it's just a fallback when an exact URL match is not found, it
should not break anything and should not have bad impact at any level
(seo/speed etc).
Indeed:
- It's done through a 302 redirect
- `_serve_page()` is already a fallback case, so it will only make
the `website.redirect` and 404 cases a bit slower due to the extra
search query.
The only possible scenario seems to be if the user (mind the uppercase):
- Created a /Page page
- Created a redirect from /page to /another-page
In this case, /page won't land on /another-page but on /Page.
This flow seems unlikely and is not actually wrong either way.
At least, it certainly is less important than ensuring a case
insensitive fallback.
Finally, note that another solution would have been to either:
- Force page URL to lower case.
-> This is not stable friendly, people might be relying on this to
create pages with different casing:
`/Batman-VII-The-Dark-Knight-Whatevers`, while not recommended,
doesn't sounds idiot.
On top of not being stable friendly, we probably want to keep
offering this possibility
- Redirect all URLs to lowercase endpoints.
-> This is obviously not stable and not Odoo's jobs. It should be
something decided by the sysadmin and done at nginx (etc) level.
task-3110294
opw-3104030
closesodoo/odoo#111736
X-original-commit: f05491105f93939490cbeb078cb7653c38685644
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, there was a weird issue with tooltips. If the
element was entered very slowly from the left or top, sometimes,
the tooltip didn't open.
The problem came from the way we closed the tooltip. This was done
by checking the x and y mouse positions within a setInterval, and
if it wasn't inside the element having the tooltip, the tooltip
was closed. When approaching the "?" icon, the mouseenter event was
triggered, we registered the setTimeout to open the tooltip. In the
next ms, the setInterval callback to check whether the mouse is
still hovering the element was executed. We observed that when the
mouseenter event is triggered, the x and y mouse positions aren't
yet inside the element, for 1 or 2 px (like if the mouseenter was
triggered too soon). As in the scenario, we move the mouse very
slowly, the setInterval callback determined that the mouse wasn't
hovering the element and thus cancelled the setTimeout callback that
will open the tooltip.
This commit fixes the issue by changing the way we detect that we
have to close the tooltips. We now listen to "mouseleave" events,
and when triggered on the element with and opened tooltip, we close
it.
Task 3150954
closesodoo/odoo#111718
X-original-commit: 89770d32cbb368f73ab304ea5c1637bd3cc19bcd
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Steps to reproduce:
- Create an analytic plan with the domain as a Bill
- Create an analytic account for the above plan
- Create an analytic distribution model and include condition as account prefix, and product.
Issue:
The analytic distribution model doesn't apply to the bill created via purchase order
Solution:
Make sure we set the analytic_distribution only if present in order
to trigger the compute during invoice creation.
opw-3160041
closesodoo/odoo#111717
X-original-commit: ce5cae1da3f453ce1aad0915189e0e305d7e55e0
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Odoo's Mergebot