In the ticket screen the user has the option to double click on an
order in order to continue editing it. This functionality is implemented
using custom code for handling the double click. This is cumbersome and
error prone.
In this PR we replace the custom double click logic with the default
`t-on-dblclick` from `owl`.
closesodoo/odoo#135856
Task: 3512282
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
This commit fixes this error:
- The IMP done at [3] added a lot of fields but all of those forgot the
`_t()`/`_lt()` translation.
Note that:
1. A fix to replace `_t` by `_lt` was done at [4] but it was badly done
as it was not targetting the correct version... and only fixed one of
many occurences.
2. In this forward port, using `_t()` seems to be working again, using
`_lt()` is not required anymore. This part of the PR has been removed
here. For tracking purpose, here was the other bug:
- The form registry fields added in [1] and [2] in Odoo 13 had a
`string` attribute translated with `_t()` while now it should be
translated with `_lt()`. It was surely working in Odoo 13 but not
anymore. It's not worth investigating to be sure.
- Not needed since a recent commit which removed `_lt()` (it's a
deprecated alias to `_t()` which now handles the lazy translation
directly too.
[1]: https://github.com/odoo/odoo/pull/32565
[2]: https://github.com/odoo/enterprise/pull/4063
[3]: https://github.com/odoo/odoo/commit/617eba941785aa680edb826e14b0009637d60dee
[4]: https://github.com/odoo/odoo/commit/2be83cae7bcda369ed5bc7806aef845c6c76e687
opw-3471873
closesodoo/odoo#134238
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Issue:
After 213b6885312f3da3bf5bff995861758a1afcde76, some custom filters
on tags can throw a stacktrace.
Steps to reproduce:
- Install Project
- Project > Custom Filter > Tags contains 'Internal'
- Stacktrace
Cause:
When `limit=None`, which is explicitly set when creating custom
filters, the `name_search` crashes when comparing an `int` (the len
(ids)) with the limit which is `None`.
Fix:
Elaborate the condition to handle the case when `limit=None`.
Affected versions:
16.0 up to master
Reference:
opw-3510309
closesodoo/odoo#135982
X-original-commit: 5aefba4399f25e4e3cd3c205e0a6511173dffd11
Signed-off-by: Audric Onockx (auon) <auon@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
The `_computeUnclaimedFreeProductQty` method was not properly computing
reward quantities for order type rules. This commit fixes the
computation to handle order type rules separately, allowing free
product rewards to be granted as expected.
The computation now also takes into account which rules were actually
used when calculating points. It will ignore any rules that were not
used in the points calculation when determining free product rewards.
This ensures the rewards match the rules that contributed to points
for the order.
opw-3492083
closesodoo/odoo#135972
X-original-commit: ff22b2cce65d324dc73295bc85a2469d42e3b82f
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Following new regulations in Denmark, we need to prevent users from
modifying posted entries in sales and purchase journals.
By using a forced hash on the journals we do just that.
task-3497062
closesodoo/odoo#135202
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Before the change
- Tax Names were not intuitive or easily understandable for the users, it was hard to relate which tax was referenced with each name.
- The Name didn't include the spanish translation, regardless the name is encoded now, it should be encoded based on the spanish description.
After the change:
- Tax names(codes) both in English and Spanish are more intuitive and easier to understand for the users.
- Tax names have better matching with the description.
task-3475793
closesodoo/odoo#132837
Signed-off-by: Josse Colpaert <jco@odoo.com>
Choosing a quant to populate a new stock move line set the quantity done
and the reserve quantity to ensure it stay available to this particular
stock move and not empty by another picking
closesodoo/odoo#124409
Task: 3256447
Related: odoo/upgrade#5139
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Only immediate transfers should have the ability to reset the state to
draft. Also rewording it as "Plan" as the goal of this button is to left
the stock move to be done later and impact the forecast
Task: 3256447
Part-of: odoo/odoo#124409
In order to reduce the amount of RPCs in the detailed operation view.
The two wizards to populate the stock move line one2many with lot/serial
number to create are replaced with twos Owl dialogs.
only one RPCs is done to generate the stock move lines values from
either a serial number + a count or a list of lots name
Task : 3256447
Part-of: odoo/odoo#124409
The move without package as computed field bring some issue with the "no
save detailed operation" feature. Creating a stock move and directly add
some move lines without saving do not call
`set_move_ids_without_package`
Task: 3256447
Part-of: odoo/odoo#124409
This commit replaces the opening of the stock moves detailed operation
wizard by the one2Many record preview. This means creating a move in a
picking is still done via a new line but the edition is done via the
`fa-list` button that open the record in the web client. The goal is to
reduce the RPCs call as much as possible. The stock move lines data are
stored in the stock move record until the picking save.
Additionally, this commit change a bit the immediate transfers flows.
The stock move show only initial demand (`product_uom_qty`) but the
column wording is still "Done". In the detailed operation view, the
stock move line `qty_done` is displayed as "Reserved".
At picking validation, the user is expected to enter the same quantity
in `product_uom_qty` and `quantity_done`. If `product_uom_qty` is equals
to 0, the done quantity is used as actual transfer quantity. If
`product_uom_qty` is different than 0 but small than the done quantity,
an error is raised.
Task: 3256447
Part-of: odoo/odoo#124409
The condition for which the Fiscal Position's Note is shown only in Customer Invoices is removed because unnecessary.
A check has been added on the company's country to be 'IT'.
Task link: https://www.odoo.com/web#id=3420752&model=project.task
task-3420752
closesodoo/odoo#135966
X-original-commit: c32720dbd4df60fd9e8e10d3893501e006130d8d
Signed-off-by: John Laterre (jol) <jol@odoo.com>
---- Horizontal spacing issue ----
The horizontal spacing between systray items in the patched website
systray is too small. It was using the regular margin of the default
Odoo systray which is composed of almost only icons for which a small
spacing is what we need.
But the website patched systray contains a lot of text, where we want a
bigger spacing, exactly how we do for the app menus.
---- New class on systray ----
To target the website systray in scss, a new class was added on it.
There is no clean way in JS to add that class, as the website systray
patch is only altering the method in charge of returning the systray
items. The rest is left up to the base NavBar class component, including
rendering.
That NavBar component does not come with a built in way to add a class.
We could have targeted the DOM directly in the patch through
`this.root.el` and added the class in JS directly but that seems like an
owl anti pattern.
---- Vertical align issue ----
Before this commit, the btn in the systray didn't have the same line
height as other elements: both the "Edit" (in main lang) and "Translate"
(in alternate lang) buttons had a (1-2px) vertical alignment issue.
This was because, despite having the same font style and font size, they
had a different line-height making it glitch 1-2px vertically.
It's a bit less visible for the Edit button as there is a pencil icon
between this text and the text next to it.
For the translate button, it's quite visible directly.
For testing purpose, you can simply remove the icons and the left-right
margins of those systray items so the text are glued to each other and
you clearly see the misindentation.
---- Misc ----
For tracking purpose, there is multiple cases to be tested regarding
those buttons:
- Community vs Enterprise (where those are colored)
- Regular mode vs translate mode
closesodoo/odoo#135956
X-original-commit: 066e4a1ddd9faf7ba866c5428c943b5af8115191
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: "stefanorigano (SRI)" <sri@odoo.com>
How to reproduce:
- open CRM > Forecast
- group by Expected Closing > Week
Current behavior:
- some week numbers appear multiple times
Expected behavior:
- each week should only appear once
Technical explanation:
Since [1], week groups are dependent on the locale, but the
`_read_group_fill_temporal` method was not updated to also produce groups
dependent on the locale.
[1]: https://github.com/odoo/odoo/pull/93053
task-3478451
closesodoo/odoo#135952
X-original-commit: 980786e301bdf80a9a39260a95359431c5cb5e86
Signed-off-by: Damien Abeloos (abd) <abd@odoo.com>
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1”
- Create a Transfer:
- Operation type: delivery order
- Product: “P1”
- Validate the delivery
- Create a return of the delivery:
- Confirm and validate the return
- Create a repair order from the delivery
- Set the product “P1”
- Confirm, start and end the repair
Problem: A stock move is created when the repair is completed, but it's
linked to the return picking what is wrong. When a 'repair' order is
created, the 'default_picking_id' is passed into the context to be set
in the 'repair.order'. Consequently, when the repair is completed and
the stock move is created, the context isn't cleared, leading to the
utilization of the 'default_picking_id':
https://github.com/odoo/odoo/blob/5d25900cd88ebc1fd16b0bd6ebba4602a13e9d76/addons/stock/models/stock_move.py#L317
In the button, no context is passed as a parameter:
https://github.com/odoo/odoo/blob/86aa7b78aadee5747c93b4bd27046cfaed1e438d/addons/repair/views/repair_views.xml#L36
opw-3269813
closesodoo/odoo#135939
X-original-commit: 558c647d5c70f7729c663ec3d45fb0cae813db04
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Intent of checking `group_no_one` was always to query the advanced
info / debug mode, however when the semantics of group_no_one got
changed in 31518bc09b this site was
missed, and now always displays "advanced" errors for internal
users. Which was not the intent.
Also since we're printing `display_name` and some of them annoyingly
hook onto context variables to show extended information, reset the
context to the user's default in order to avoid such
extended-formatting `display_name`.
Also fix "debug mode" in `TestIRRuleFeedback`, which has been broken
since time immemorial (likely as long as the group_no_one semantics
changed).
closesodoo/odoo#135940
X-original-commit: 9d3ffa6540c07e97b7160167756edd8e71f2308a
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
This commit gathers the different parts of the content from the many2one
confirmation dialog into a single _t in order to facilitate the foreign
translations of the content
closesodoo/odoo#135495
X-original-commit: e97ec328e8c6ec2b083c854b19cefe5c19db3991
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Julien Carion (juca) <juca@odoo.com>
Commit 167c51b1f9 makes `use_create_lots`
and 'use_exisitng_lots` computed fields in MRP module but did not mark
them as `readonly=False`. Thus, they were readonly by default for any
picking types.
Also, make sure new reception picking type have their `use_create_lots`
set to True and delivery picking type their `use_existing_lots` set to
True.
closesodoo/odoo#135900
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Description of the issue/feature this PR addresses:
when logged in user name is too long then it take whole header to display it
name.
In project module, if milestone name is long then name is overflowing.
Current behavior before PR:
whole header is occupied when username is long.
milestone name is overflowing when name is too long.
Desired behavior after PR is merged:
when username is long it would show with '...' format.
when milestone name is long it would show with '...' format.
Fix:
some property is added in oe_topbar_name class to display the username in short
and '...' format.
add some bootstrap class so that long name should be formatted in '...' .
task-3217427
closesodoo/odoo#135899
X-original-commit: 38ac3f21843842937a89ce8c2e07f7b54039348f
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Ravi Bhingradiya (ravb) <ravb@odoo.com>
On the backorders, the consumed quantities are incorrect.
To reproduce the issue:
1. Create two products:
- C01: consumable
- P01: storable
2. Create a BoM
- Product: P01
- Type: Subcontracting
- Subcontractor: S
- Components: 1 x C01
3. Create and confirm a planned receipt:
- From: S
- 10 x P01
4. Set the done quantity (directly on the tree view) to 1
5. Validate + Backorder
6. On this first backorder, set the qty to 2
7. Validate + Backorder
8. Validate the second backorder
9. Inventory > Reporting > Moves History, filter on C01
Error: There are three SMs, and here are the done quantities: 1, 9
and 7. The second one is incorrect, it should be 2 (see step 6).
Since [1] the done quantity is always editable on the picking's
operations, but the feature is not implemented in subcontracting,
therefore the communication between the MO and the picking does not
work well. For instance, step 4: save the done quantity and open the
MO: nothing changed on it, its producing qty is still zero. Another
example: step 4, instead of setting the done quantity directly on
the picking, open the wizard (the MO), record 3 produced products and
close the wizard. The done quantity of the stock move is 3 but the
user can still edit it. However, if he tries to update the line,
nothing will change on MO side.
On top of these "little" bugs, it may lead to a more important one
as shown in the above use case. Step 5: at some point, we split the
MO to generate a backorder for 9 x P01:
https://github.com/odoo/odoo/blob/c47e4ac7cb5fdd690f40ab2e0f8d022ba565145e/addons/mrp_subcontracting/models/stock_picking.py#L72-L76
And, as shown, the flag `set_consumed_qty` is set to `True`. As
explained in the method description:
https://github.com/odoo/odoo/blob/a2574b45aef1ff6ff3a221b996d0bb0dda2a8c74/addons/mrp/models/mrp_production.py#L1602-L1603
So, because of this flag, the method will create a SML for C01 on
the backorder, with its done quantity set to the reserved one: 9.
However, back to the first block code: `move.move_line_ids` only
contains the SML created at step 4 (i.e., the SML of the inital
SM, with a done quantity equal to 1). As a result, in the for loop,
we only define the producing quantity of the initial MO.
This is a first issue: step 6, suppose the user rather opens the
detailed operations of the line: it displays the new MO, the
producing qty is 0 but the consumed quantity of the component is 9.
This is not perfect, but let's ignore this and continue with the
above steps. The user sets the done quantity to 2 and validates with
backorder. It runs the productions split again, we use the done
quantity as producing one on the MO, but we don't edit the consumed
quantities, hence the error.
For all these reasons, the safer solution is probably to prevent the
feature 'qty done always editable' in case of subcontracting.
[1] cacc677a08066bc23e1c89df36027599d05f2a08
OPW-3441197
closesodoo/odoo#135862
X-original-commit: 049f63fbc1ab09cf75824e5c22508ea091e5c4dd
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Before this commit, updating the color previews in the editor panel was
only done if the user remained in the "Theme" tab.
This means that those steps worked:
- Add a snippet in your page
- Go to the theme "tab"
- Change a theme color: validate the color you chose by closing the
dropdown by clicking inside the theme panel, staying in the theme tab
- Click on the snippet
- Open the background option colorpicker -> theme colors are right
But those apparently same steps did not work:
- Add a snippet in your page
- Go to the theme "tab"
- Change a theme color: validate the color you chose by indirectly
closing the dropdown by directly clicking on the snippet you added
- Open the background option colorpicker -> theme colors are wrong
task-3419142
closesodoo/odoo#135703
X-original-commit: 83c0bd93f0948bed4220ba5e505516f305b1c6ce
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
If leads are created using live chat, users without CRM rights cannot
access the visitors list anymore because the lead/opportunity
information is not available to them.
This commit limits the display of `lead_count` to the
`sales_team.group_sale_salesman` group.
Then, the visitor's form cannot be accessed because the "Lead" smart
button fails to load.
This commit therefore limits the display of the button to that same
`sales_team.group_sale_salesman` group.
In 14.0, the column still appeared without the `lead_count` value
displayed, but clicking on it raised a traceback.
Steps to reproduce:
- Install `website_crm_livechat`
- Login as Mitchell Admin
- Send a message in the live chat
- Go to Discuss
- Answer the livechat message with `/lead New`
- Go to Settings / Users / Marc Demo
- Remove the Sales rights
- Logout
- Login as Marc Demo
- Go to the Website / Reporting / Visitors page
=> The page could not be reached and an access right error message was
generated.
opw-3475301
closesodoo/odoo#135571
X-original-commit: 4f67701f99e4b86cb0a4330a32b455bd6ff4686a
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Robin Lejeune (role) <role@odoo.com>
Reproduction:
1. Install website
2. Change to edit mode and edit a link on the main page, for example,
“contact us” at the bottom
3. When you replace the link with /, the rpc breaks and no suggested
links returned
Fix: this issue is gone with a recent update on master, now the rpc used
by linkTools is the new rpc
Task-3444671
[FIX] web_editor: restore double click focusing on URL when editing link
Reproduction:
1. Install website
2. Change to edit mode and edit a link on the main page, for example,
“contact us” at the bottom
3. The focus is on the url at the link tool
Fix: The desired behavior when clicking on links in editing mode is: one
click, edit the text of the link; double click, focus on the URL in link
tools. After converting to OWL, focusing on URL is handled by props, e.g
. `shouldFocusUrl`. We also need to update the state of this prop in
`toggleLinkTools` as we did before conversion.
Task-3444671
Forward-Port-Of: #132167
Also added fix for using the new rpc function instead of the legacy one,
edited the test accordingly.
Part-of: odoo/odoo#135371
Update (some) query counters according to runbot state.
Also make some tests deterministic when involving company name.
Task-36879 (Mail: Support MultiCompany Aliases)
closesodoo/odoo#135288
Related: odoo/enterprise#47345
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Description of the issue/feature this PR addresses:
- In Romania, generating and communicating XML invoices to the government is a requirement. This format is based on UBL/CII for which we already have a very strong base.
- This task aims at completing the localisation with a first step : make Odoo generate the required Romanian UBL format if activated
- Official documentation: https://mfinante.gov.ro/web/efactura/informatii-tehnice
Current behavior before PR:
- CIUS_RO XML export is not supported yet
Desired behavior after PR is merged:
- CIUS_RO XML export will be supported
closesodoo/odoo#130617
Task-id: 3388222
Signed-off-by: Laurent Smet (las) <las@odoo.com>
refactor TaxCurrencyCode as it is supposed to belong ignored
ubl 2.0 according to the documentation
http://www.datypic.com/sc/ubl20/t-ns19_InvoiceType.html
this also allows future EDI that needs this node so that
they won't need to create their own template
Task-id: 3388222
Part-of: odoo/odoo#130617
The aim of this commit is to:
1) ensure the expected file exist or make the test fail if it doesn't
2) file and file_path: switch variables names
3) allows using that method from other module
Context:
1) When the expected_file_path doesn't point to any existing file
2) There is an ambiguity with those variable names
3) run the method from a test in another module
Before this commit:
1) The test fail with an obscure error `can't convert Boolean`.
2) `expected_file` is a path and `expected_file_path` is the file.
3) The method was always looking in `l10n_account_edi_ubl_cii_tests` to
get its files.
After this commit:
1) The failing test clearly states the file doesn't exist.
2) `expected_file` is the file and `expected_file_path` is the file path.
3) The test method is now looking in the module from which it gets run
to get its test files.
Task-id: 3326977
Part-of: odoo/odoo#130617
Links of the current website forums belonging to the user are now displayed in
the sidebar. A forum is considered to "belongs" to a user if either he has
posted a message on it or he has added one of the post in his favourites.
Technical note: we add the value "my_other_forums" in _prepare_user_values
method to display the other user forums of the website in the side menu on
various pages. That value is only added when the "forum" value is a forum
indicating that the page is currently displaying one of the forum (we use
the test "forum and forum is not True" because forum parameter can take the
value True, None or a recordset). We use a lazy value so that the query to
select the forum is only executed in the page that uses it.
Task-3354382
closesodoo/odoo#130469
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Purpose
=======
The customer reference is a string that can be added to a SO
(in Other info page). It is well visible when downloading or printing
a SO but not in the overview in the Portal.
Specification
=============
Add the Customer Reference in Sales Order and Quotations if it has been filled.
Task-3355199
closesodoo/odoo#124217
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The account_edi framework is no more a dependancy.
- Models account.edi.document and account.edi.format have been removed.
All the functions have been moved to the new account.move.send,
account.move, account.edi.proxy.client.user
- The move now holds the l10n_it_edi_state which admits all values that the SdI sends us as a status update
- The sending is now not handled by the cron but by the Send and Print dialog.
- Vendor bills Tax Integration sending by dedicated button
- The move form will now hold the state of the EDI transaction, its number and the EDI attachment as a Binary field on the move itself.
- A new banner will keep the latest message from the SdI, that's not the account_edi old banner.
- All the user messages have been simplified.
IAP-apps PR: odoo/iap-apps#652
Upgrade PR: odoo/upgrade#4893
Task link: https://www.odoo.com/web#id=3339971&cids=1&model=project.task
Task-3339971
Part-of: odoo/odoo#122194
- Proxy user is no longer a computed store=True field, but a proper one.
The type cannot be deduced just by some field on the company.
A company may be Italian and also use Peppol, so the two Proxy Users
must be different.
- The Proxy user `get_proxy_identification` method needs a proxy_type
argument, otherwise the method won't know if the current override
is to be applied or not. It cannot be handled by a field of the user
itself because it is also used contextually to the user creation.
- new `_get_default_enable_send_by_post` function on the Send and Print
wizard, so that it can be overridden by the features of the move
- Renamed `_compute_send_mail_extra_fields`
to `_compute_fields_from_moves_state`
Part-of: odoo/odoo#122194
This commit removes a legacy polling system that was present to query
the server about status change of pending transactions in the shop. This
has not been necessary since that all payment flows go through the
/payment/status page, which already polls the server for pending
transactions' state change.
task-3125913
closesodoo/odoo#119473
Related: odoo/enterprise#47603
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Instead of monitoring a list of transactions to post-process in the
session, we now track only the last processed transaction, thus allowing
to drop the 10 min delay of the post-processing cron.
task-3125913
Part-of: odoo/odoo#119473
Co-authored-by: mano-odoo <mano@odoo.com>
We explicitly discourage a compute method used for both stored and
non-stored fields, because it may be unexpectedly update the database.
Indeed, we don't expect the computation of a non-stored field to update
the database. Allowing this kind of compute method makes reasoning
about readonly code much more difficult, and would prevent readonly
transactions with such fields.
For instance, consider a compute method for both fields F (non-stored)
and G (stored), and assume that none of those fields are in cache.
Whenever F is accessed, the compute method is invoked, and both fields
are assigned, which potentially generates an SQL update for field G.
This is problematic if we require the current transaction to be
readonly.
Part-of: odoo/odoo#98565
Steps to reproduce the bug:
- Create a storable product “P1” with BoM:
- Add a tracked component
- Add another component (no tracked)
- Create a MO to produce 1 unit of the product "P1":
- Confirm
- Unlock the MO
- Set the "to consume" quantity of the tracked component to 0.
- Try to validate the MO
Problem:
A user error is triggered: “You need to supply Lot/Serial Number for
products:”
Solution:
If the quantity to consume is 0, ignore the serial number verification
for this move.
opw-3471256
closesodoo/odoo#135657
X-original-commit: 5e591cf36cdc6dcbdb8a5ee3753247578a771e9f
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1”
- cost= $100
- Create a repair order:
- select any product in the product to repair
- add “P1” as component
- create the quotation from the repair order
Problem:
The cost is not computed correctly and is set at 0 in the
`sale.order.line`
opw-3502317
closesodoo/odoo#135822
X-original-commit: b95ed3617f465a655c8f918bee8edc673c8f202b
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
A previous commit made to add a new (triangular) tax introduced
a bug where the tag 3b (omzet) was archived, leading to journal items
not being picked up by the modified tax report.
This commit should add the new tag 3bl (omzet) on the items containing
the previous 3b (omzet) tag when upgrading the module.
closesodoo/odoo#135809
X-original-commit: a46bf625715a307182443328ffce155f6890bab0
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Pierre-Rodéric Roose (prro) <prro@odoo.com>
This error occurs when user tries to click on the checkbox to 'Mark as done'.
Steps to produce:
- Install the `website_slides` module.
- Go to Website > Courses > Open a course containing one or more sections
(e.g., 'Taking care of Trees').
- Click on the `Add Content` button located at the bottom in blue.
- Select the video option and upload two videos, one after the other.
- Now, click the 'Mark as done' checkbox for the first video.
- When attempting to click the 'Mark as done' checkbox for the second video,
the error will occur.
Error: AttributeError: 'int' object has no attribute 'id'
To solve this issue we have returned the record for `next_category`from that it
will get the record `id`.
Previously, this code returned an integer value, see here:
https://github.com/odoo/odoo/blob/f34d87ecb7772417f1dd8f3d8836c89ddb903de8/addons/website_slides/models/slide_slide.py#L1321
here we are using that return value from the above line
https://github.com/odoo/odoo/blob/69fca30bb4fb66e6d979ce5ddc1bff4db963ca71/addons/website_slides/controllers/main.py#L1062
Previously it gets the integer and try to get id of that integer value.
sentry-4414398591
closesodoo/odoo#135805
X-original-commit: 9cc11ef9a0f2025a717602fb2087b96eda5e8218
Signed-off-by: Achraf Ben Azzouz (abz) <abz@odoo.com>
Steps to reproduce:
* create an invoice with a line
* change the receivable account
* duplicate the invoice
Result: the receivable account is recomputed to the default one.
Expected: we should keep it.
task-3504443
closesodoo/odoo#135723
X-original-commit: 1043d2b790a625590ca21f8e0d6560ceba3d6a84
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
- Employee smartbutton should not be displayed if contract is not double signed
- Inactive contracts should not be displayed
- Fix some translations
task-3471583
closesodoo/odoo#135689
X-original-commit: 856fbe7e180ababddab9cbd78dc9c43b749b83bd
Related: odoo/enterprise#47485
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
since 17.0 attrs is no more used, replacing the existing
usage with invisible attribute
closesodoo/odoo#134962
Signed-off-by: Jérémy Hennecart (jeh) <jeh@odoo.com>
At the moment, the pos displays the selected order in multiple
screens, such as the `ProductScreen`, the `TicketScreen`, the
`SplitBillScreen`, the `self_order` app, but uses completely
different implementations for each. This means that when
a change needs to be made to the one, it generally needs to be made
to the other as well, which is error-prone.
In this commit we create generic `OrderWidget` and `Orderline` components,
that have not dependencies on POS objects and we refactor the `ProductScreen`,
the `TicketScreen` and the `SplitBillScreen` to use these components.
The `OrderSummary` component was removed and it's contents are now in the
`OrderWidget`.
We also introduce a very simple new component called `CenteredIcon` that
can be used whenever we want to show an icon that fills a whole div. In this
commit we use it for showing the cart icon when the order is empty.
In a future commit, the `pos_self_order` will be refactored in order
to use the same `OrderWidget` and `Orderline` compoenents as the POS.
Task: 3470365
In addition, this commit solves the issue from the task 3491303.
closesodoo/odoo#132248
Related: odoo/enterprise#45972
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
When the Wysiwyg is used by website, multiple editable elements are
possible, and each of them carry the related record's model and id in
the element's dataset.
On the other hand, when the Wysiwyg is used by the html field, there's
only one root editable element, and such information is not present in
the editable's dataset, but in the widget's options object.
Before this commit, when saving the content of an html field, modified
images were converted to attachments without the correct reference to
the record's model and id.
This commit makes sure that such information is passed to the route that
handles attachment creation.
task-3495668
closesodoo/odoo#135806
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
vlst