purchase_stock, point_of_sale
What are the steps to reproduce your issue?
When Odoo.sh runs unit tests on a development branch,
it tests the code in the MRP module for rounding errors.
What is the current behavior that you observe?
I had a customization that introduced a rounding error in the standard MRP module.
When the unit tests ran on the development branch, I got a traceback.
What would be your expected behavior in this case?
The rounding error should be reported as a failed test with a message. No traceback.
opw-3454998
closesodoo/odoo#136052
X-original-commit: c4b5148be0819eeef8ce7e12cdc7f1d45174fe65
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Gaetan Vanden Bergh (gavb) <gavb@odoo.com>
The livechat button was disabled in website preview because
its implementation could not properly handle being in an iframe
inside the backend [1].
With the public livechat code being refactored to use discuss code,
this is no longer a problem, so the livechat button can be present
again. This also makes previewing the website more correct: the
livechat button is actual present on the website, so hiding it was
a lie.
By re-enabling the livechat button, this also allow to remove the
test coverage by a tour, which was sometimes failing on runbot due
to tour being small and doing `im_livechat/init` rpc after the end
of the tour.
[1]: https://github.com/odoo/odoo/commit/e86c1ce94a148745d58ac38e408e1bc947978670
runbot-24631
closesodoo/odoo#135913
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Issue:
Search on website has a big performance issue because the database has
too many product_template.
Analyze :
The website search mechanism has hardcoded sql query. And the generic
query don't have any filtering. Which lead to make a expensive search
(similarity) on the whole product_template even if the products are
not published and then displayed to the user.
Fix :
Filter the is_published field in the generic website method when the
model has a 'is_published' field and the request is not done by a user
(thus for customers or portal users).
Note:
The internal user is still able to search on unpublished product.Thus
have no performance improvement.
Benchmark:
| SQL Query | # Input data | Before PR | After PR |
|:---------:|:------------:|:---------:|:--------:|
|General best_similarity |700000 products (161 published) | 12.65 s | 0.12 s |
|FROM ir_translation|2,796,000 ir_translation | 6.338 s (586k hit) | 0.091 s (185 hit) |
Related task:
task-3473786
Related ticket:
opw-3418457
closesodoo/odoo#136080
X-original-commit: fcb968836a2d0e49516fe3ecb23dde61f4597749
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The aim of this commit is mainly to add optional standard node directly
on UBL 2.0.
This will allow national customization of ubl to be easier to implement.
List of modification:
- Add the following nodes:
- AddressFormatCode
- BuildingNumber
- PlotIdentification
- CitySubdivisionName
- Name under TaxScheme
- DocumentTypeCode
- reduce zatca customization
- add attrs to several place to ease customization of attributes
- add a hook from which customization can override all decimal places to
enforce a maximum
- add a hook to ease the modification of the `legal_monetary_total_vals`
sub dict
- add method to allow customization to provide attributes for
DocumentTypeCode node.
Notes:
Regarding PlotIdentification and CitySubdivisionName, I decided to not
populate some of those field for now because I didn't think of a
reliable way to get their value while zatca benefits from fields created
in l10n_sa_edi.
Task-id: 3326977
Part-of: odoo/odoo#136072
The stupid aim of this commit is to remove one line.
The smarter goal of this commit is to add a "/" for the root node and
improve the code readability.
Context:
I made an initial modification to this function and created an `AccountTools`
class. Then Laurent was bothered and changed some stuff thus the initial
commit isn't required anymore.
As he isn't bothered anymore and has too much peace of mind at the moment, I
have the responsability to entertain him to keep his brain at its full
capacity for the sake of Odoo's future.
Before the commit:
The code is complicated and LAS is in peace.
After the commit:
The code is sexier and Laurent keeps his brain sharped and entertained.
Task-id: 3326977
Part-of: odoo/odoo#136072
The aim of this commit is to make method `_check_required_fields`:
- works with dict
- make the docstring more explicit
Context:
Docstring states that it works with dict and record
Before the commit:
The method was crashing when used with dict if the key wasn't in the dict
After the commit:
The method works with dict without crashing
Task-id: 3326977
Part-of: odoo/odoo#136072
Previous fixodoo/odoo#121602 did not correctly handle the case when not
all of the qty to manufacture is manufactured (the qtys to change to
were miscalculated in this case).
Additionally, it missed fixing a few more use cases when setting the
qtys to match the wizard's lines/qtys:
- if the UoM of a MO's component line is changed => the correct qty was
not correctly converted into the move.product_uom's qty (now it is)
- if a component's move is deleted before the MO is confirmed => the
move (i.e. the missing component) was not correctly added back into
the MO (now it is)
- if there are 2 MO component moves with the same product => both were
set to the same "correct qty" value (now we only set the first move to
that qty, others are set to 0 since we have no way of knowing how to
distribute the qtys otherwise)
Also, since an UserError needed to be added in case of a missing comp
move for a tracked product, existing error logic has been updated to
list all applicable products and the message has been improved to be
more helpful.
Note that the fix for saas-16.4 and earlier is slightly different from
this fix due to the change in how stock move original demand qtys no
longer change like they used to (see: odoo/odoo#130342) and because a
backorder bug was also exposed by this change.
closesodoo/odoo#135796
Task: 3456604
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
This reverts commit 5fd345e.
The duplicate option was removed but it should be available.
closesodoo/odoo#136014
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
To test which browser is currently running, jquery performs some checks
when it starts, by doing invalid queryselectors. Depending on which
selectors crashes, it can determinate if it is running in an old browser
and need to activate some part of the code to support them.
This would not be a big deal, except that it makes the life of some
developers much more difficult: we can no longer easily reload a page
with a "Pause on exception" setting to debug odoo. Doing so works, but
the workflow is polluted by 3 errors initially.
It is so common that I propose to simply remove the checks. This should
be acceptable, since Odoo does not work on old browser versions anyway
We are talking about firefox 5, opera 11 or "Gecko", for a commit that
is at least 11 years old
closesodoo/odoo#136013
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Steps to reproduce:
- Go to `/blog`.
- Enable "Show Sidebar" in the "Customize" menu.
- Edit the page.
- Click on an icon of the "Follow Us" section of the sidebar.
- Click on the "Link" icon of the editor toolbar.
=> An error popup appears.
In further versions, the link parameters can be edited - but they are
lost upon save.
The social media links sections of the blog and blog post pages is
generated and is not supposed to be editable.
This commits makes these social media links sections non editable.
If a user needs to configure such a content specifically, it can be done
inside the "About Us" section of the sidebar above.
E.g.:
- Deactivate the "Follow Us" section from the "Customize" menu.
- You can use copy/paste to duplicate the existing style of the
"About Us" section if you want.
- Click on the "File / Image" icon of the editor toolbar (or type
"/image" to use the Power Box as of 15.0).
- Select a pictogram.
- Click on the "Shape: Circle" icon of the editor toolbar.
- Select the "Font Color" from the editor toolbar.
- Click on the "Link" icon of the editor toolbar to specify an URL.
opw-3450880
closesodoo/odoo#135980
X-original-commit: 27d8633c73106b7278eda7d07c9fce370d29784a
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Since the website page preview is within an iframe, the selector used to
neutralize some events during edition of blog pages were not targetting
the elements anymore.
This commit makes the elements looked up within the iframe.
opw-3450880
Part-of: odoo/odoo#135980
Before this commit:
Negative discounts could be applied to products, which is not allowed
in Indian EDI.
After this commit:
Applied conditions to check for negative discounts and raise an error in case of
such discounts.
task_id: 3293247
closesodoo/odoo#135790
X-original-commit: fb1352bc1937d54183173c57094b5b176525d8d6
Signed-off-by: Josse Colpaert <jco@odoo.com>
Add a selection field `l10n_mx_tax_type` on account.tax. This field is
used in the CFDI attachment. This allows to avoid relying on the name of
the repartition line tags to export and import a CFDI.
task-3388347
closesodoo/odoo#135215
Related: odoo/enterprise#47321
Related: odoo/upgrade#5136
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Adding a company_id field in project.project.stage will allow companies
to have their own individual stages, which was not possible before since
all the stages were shared between all companies.
task-3330285
closesodoo/odoo#122597
Signed-off-by: Vincent Larcin (vila) <vila@odoo.com>
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>
Gaetan Vanden Bergh (gavb)