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>
Steps to reproduce the bug:
- Enable “batch transfers” in the inventory settings
- Create a new warehouse “WH2”:
- Enable “Resupply From” option
- Enable “3steps”
- Go to the operation type “internal transfers” of WH2:
- Enable “Automatic Batches”
- “Destination Location”
- Create two storable product “P1” and “P2”:
- Route: warehouse # 2: Supply Product from YourCompany
- update the Qty to 10 in wh/stock
- Create a replenishment for “P1” and “p2”:
- Location: WH2/stock
- Preferred route: warehouse # 2: Supply Product from YourCompany
- Procurement Group: select two different procurement
- min qty: 1
Problem:
Two internal pickings are created for “P1” and two others for “P2”,
because two different procurement:
- from “input” to “quality control”
- from “quality control” to “wh/stock2”
But as the pickings have the same location destination, two batches
are supposed to be created to group the pickings.
The `_find_auto_batch` function is triggered when the picking is
confirmed:
https://github.com/odoo/odoo/blob/16.0/addons/stock_picking_batch/models/stock_picking.py#L120
but since the pickings are not confirmed, the function is not called:
opw-3076077
closesodoo/odoo#111716
X-original-commit: 324298967cb63d7de1144c8aee2039119443e60c
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce:
- Install mass_mailing module (for test purpose)
- Create a new mailing and change `Recipients` to `contact`
- Add a new node in the domain (by clicking on +) and set :
Field => `Zip`, Operator => `in`, Value => `123`
- click on + next to value
Issue:
Domain is not updated (same issue with `not in`).
Cause:
When adding a new value to the domain, a div is added with the value
and a cross button (to remove the value from domain).
The button have a `t-on-click` attribute that call a function
(removeTag(tag_index)) and therefore as soon as the div is added,
the function is called.
Solution:
Use `() => func(arg)` syntax instead to be able to call the function
with arguments only when button is clicked.
opw-3099583
closesodoo/odoo#111714
X-original-commit: f9a9f2da88a68040642231db2489e134d1f8096a
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Go to Contacts, click Create, leave the name empty, click on a
stat button (e.g. Meetings). Before this commit, there's a crash.
It happens because the `name` field is present twice in the view,
with different `required` attrs. Only one of them is visible,
depending on the `is_company` field.
Commit [1] introduced a sub part to the required domains to fix an
issue with the way the legacy form view handled required fields
(basically, the field `name` was displayed twice in the notification
indicating that there were invalid fields), thus making those two
domains different.
With wowl views, this patch is no longer necessary, as the required
attrs is evaluated in the model, so once for each field. Thus,
having two different required domain doesn't make sense anymore
(the last one wins).
This commit fixes the issue by removing the domain sub parts added
by [1].
[1] 8143a641a2
Task 3086014
closesodoo/odoo#111711
X-original-commit: a1ed27352f393b8fff8c4f8985e3f503a07e6e37
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
To reproduce
============
- create a payment term with Balance of 3 months and a percent with 50 as value
- create a vendor bill using this payment term
- try to register a payment, the amount is not showing
Problem
=======
the amount field would be invisible if the Group Payment check box is checked,
and in this case it should be checked because it's one deadline.
Solution
========
the problem comes from the fact that the compute method that will check or uncheck
the group payment field, is called twice in same compute process but we only execute it
once because the record is protected and that's how ORM is expected to work to avoid infinite loops.
to solve the issue, `group_payment` was removed from `_get_batches` because it's not necessary.
opw-3103465
closesodoo/odoo#111710
X-original-commit: 5fd0dc7929156b193271679be90f1cbdf4e626b3
Signed-off-by: abla001 <abla@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
When sending the same survey to the same partner, the system detects it and
allows the user to choose between sending a new invitation or resending the
old one so that the user can continue the survey that might already be ongoing.
The detection was not working anymore and this fixes the problem.
Technical note: _compute_existing_partner_ids was intersecting record set
partner_ids (the one currently added) and a record set of partner for which an
invitation has already been sent. The intersection didn't work because
partner_ids relation was not completely set and instead of id, had "origin" id.
Comparing id using a filter solves the problem (using the trick that .ids,
return also the origin ids).
Task-3087702
closesodoo/odoo#111687
X-original-commit: fea798047118f0a482dc2421d92e73f51dd04816
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Dufays Pierre-Yves (pydu) <pydu@odoo.com>
Because of the M2M relation, an account.move.line can be linked to
several sale.order.lines, making the cardinality of sale_line_ids
superior to 1.
Even if it is not possible to obtain this result with standard code,
a custom module could create this situation and posting the invoice
would result in a "ValueError: Expected singleton" exception.
This commit prevents this exception by checking whether the line is
linked to at least one downpayment SO line in the method action_post.
The test also checks that the methods button_draft and button_cancel
behave properly (spoiler alert: they will fail too in 16.0).
closesodoo/odoo#111686
X-original-commit: a2344a4cd9283e3a74caf454ce218eecf5855de0
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Paul Morelle (pmo) <pmo@odoo.com>
model/model_terms translations:
A transifex link if available is displayed after the language in the translation
dialog to help translators to contribute their translations. The tooltip message
for mouse hovering is 'Contribute'
code translations:
Setting -> Translations -> Application Terms -> Transifex Code Translations
In order to reuse the list view and search bar, model transifex.code.translation
is created to store all code translations.
This model is
1. readonly
2. reloaded on demand/by cron(7 days) to avoid increasing the Odoo restart time
3. updated for new installed modules/languages while opening the list view
4. shared to all users without duplicated translations
closesodoo/odoo#111685
X-original-commit: 7b30badb52e2a948c41f4340a01f6118818c6711
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Wang Chong (cwg) <cwg@odoo.com>
tsm-odoo