You can, in a production order, change the quantity done of a stock move
raw and change its initial demand ('To Consume' field) in the same
transaction. This can lead to some issue as changing the quantity done
will update the stock move line and changing the initial demand will
unreserve the stock move thus impacting the stock move lines too.
This commit will split the values to update of a stock in move in case
the two fields have to be updated. First the stock move lines, then the
initial demand.
This commit also remove the default_product_uom_qty in the move_raw_ids
fields. This ensure the onchanges do not create/edit any stock move lines
with some reserved quantity.
opw : 2451298
closesodoo/odoo#70975
X-original-commit: e8c1f6b1a3f58b68181bf4d2599bd37efb83b5c7
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
website_forum.faq_accordion is not rendered by a drag'n'drop
and data-parent is therefore not set on tabpanels by onBuilt.
closesodoo/odoo#70978
X-original-commit: d4e046209914a7be3aed976a1fc3a74020843309
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
accordions in pages created by configurator have not been
added by a drag'n'drop. onBuilt is therefore not called and
attributes (data-parent and id for tabpanel and data-target
for tab) are not set. We set these attributes directly
in the xml to make accordions work also for configurator.
closesodoo/odoo#70974
X-original-commit: 887f6d539ebf4f3a6d95f44f2cdd4152b59d5910
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
As pickings can be moved from a batch into an another one, a batch can suddenly
be emptied or having no more active pickings.In such case, we cancel it.
This way, empty batches won't be displayed by default as there is a default
filter showing only draft or in progress batches.
If we manually remove all pickings from a batch or create a empty batch, we
consider it intentional, and won't cancel it automatically.
Task-2464457
PR #66600
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
batch
We already allowed the stock.picking.to.batch wizard to create batch
with pickings already in other batches. This commit will also allow you
select pickings that are already in other batches on the batch form.
Task-2464457
PR #66600
This commit update owl to the latest release. It only contains a small
fix on the order of lookup for the t-component directive.
Release on github: https://github.com/odoo/owl/releases/tag/v1.2.5closesodoo/odoo#70972
X-original-commit: 67e706b76fefa7eaff12722a4bda6fa4ce497eaf
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When the user removes the readonly from the field date order and tries
to modify it it crashes in some cases, this commit fix this
opw-2523508
closesodoo/odoo#70969
X-original-commit: 3e4a541277828ec9cd0bd97587c6d87dc91ccf08
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>
The account payment file being quite big already,
and the payment methods being modified in another
task (2414749) we'll extract them into their own
file to make it easier to work with them
closesodoo/odoo#70937
Related: odoo/enterprise#18367
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Before this commit, evaluating a domain containing a like/ilike
operator with an evaluation context in which the value was false
crashed.
Moreover, those operators were wrong w.r.t. the case sensitivity:
like was case insensitive, whereas ilike was case sensitive, and
both =like and =ilike were case insensitive.
This commit fixes thoses issues.
The first issue was spotted on our prod, as we tried to add an
invisible attrs in a form view, using the ilike operator (it thus
crashed in create mode).
The second issue was spotted while writting the test cases.
To the best of our knowledge, those operators aren't used in attrs
(for now), explaining why those issues haven't been found before.
closesodoo/odoo#70951
X-original-commit: 44e185dbd6ddeda7cdcd76882fa0bd231e9d3f37
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Creating an account move from a valuation layer is bypassed in
case the product is consumable. Since 7fa9ec2638, the signature
of _account_entry_move() changed. It no longer return an account move
but a list of values to create everything in batch.
Testing the product type should now return `[]` instead of `False` in
order to be added to the existing list.
closesodoo/odoo#70945
X-original-commit: 5d76ce38a8551f430449b997a875ccc3b5a728cb
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
When starting work on a blank website, it was possible to start writing
text in the blank page. However that was never the purpose and things
behaved improperly from there.
This commit addresses that problem by consistently applying
contenteditable=false to the #wrap element when it is empty, and true
when it isn't.
At the same time it fixes the fact that starting with a non-empty page
and making it empty failed to show the empty editor message.
closesodoo/odoo#70933
X-original-commit: c9ab6ae3e1e1859c36a4f6e68a7cae25cf92a7b3
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When changing the number of columns of a snippet, the history was
recorded too many times and at wrong moments, resulting in a mess of
undos to trigger before restoring the original column state.
The issue was due a combination of dead code and the fact that
`_updateColumnCount` triggered `remove_snippet` for each of its columns
while `remove_snippet` in turn triggered a history step at every
execution.
This fixes it by removing the dead code, replacing it where necessary
with a call to the editor's `historyStep` method, and adding an option
to `remove_snippet` so its triggering of a history step can be bypassed.
closesodoo/odoo#70932
X-original-commit: 877e5c807087afed880aeba3eab79def3a7b583c
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Since the link tools were moved from the modal to the sidebar, the url
autocomplete dropdown stretched out of the bounds of the window.
This fixes that problem while restyling the dropdown to look like the
url pickers we already have in the sidebar. In order to achieve that,
we apply to it the "o_website_ui_autocomplete", used by
UrlPickerUserValueWidget (to which we don't have access in the toolbar).
closesodoo/odoo#70931
X-original-commit: 704583aad98287adac9e13772cfb8ca0933b0a32
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When selecting the contents of a promo code then typing a letter, that
letter was inserted before the promo code instead of in it. It was also
impossible to get back inside the promo code after that.
Given the nature of that snippet it seems reasonable to make the promo
code itself unremovable. This way we can benefit from the editor's
ability to keep the cursor in an empty unremovable inline.
Note: This fix requires a change in the editor:
https://github.com/odoo-dev/odoo-editor/commit/1c98f141458de297a4b819f3fb21f532986e9872.
Do not merge without it.
closesodoo/odoo#70930
X-original-commit: ffe0277613f73e046c4e343cfb0197c937063717
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Following the recent reorganisation of the documentation in 12.0+,
the majority of the documents have been moved and their old links are no longer valid.
Some redirection rules will soon be deployed, but those rules might be dropped in some years
and we want the links to still work, which is why we still replace the links to the new ones.
FW-Port of odoo/odoo#70675 (13.0)
closesodoo/odoo#70920
X-original-commit: bc9c1eef538ba6095e74c19d5d9ed9e01625ec7c
Related: odoo/enterprise#18361
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
When building a domain `(=|!=)` with
a Binary field stored in attachment and
the right part of the domain is not null,
the full binary content is logged, giving
the logs a huge size.
Now, the content of the binary is cropped to
20 chars as it is useless to log more.
opw-2527629
closesodoo/odoo#70740
X-original-commit: 0ed46ae94b20b30c10025b2a458e1ecf92c2712d
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Before 03025520b rounding applied was eg. for these numbers and UP and
DOWN rounding methods to multiple of 10:
```
Numbers | -8 | -2 | 2 | 8 | 12
DOWN | -2 | -8 | -2 | -8 | -2
UP | 8 | 2 | 8 | 2 | 8
```
which is correct for positive numbers but UP and DOWN are inversed for
negatives numbers.
After 03025520b this became:
```
Numbers | -8 | -2 | 2 | 8 | 12
DOWN | 8 | 2 | 8 | -8 | -2
UP | -2 | -8 | -2 | 2 | 8
```
which is correct for all cases except for positive numbers that are
before HALF of the precision (eg. number 2) for which UP and DOWN are
inversed.
This is happening because 03025520b uses the sign of the rounded value
=> this does not work for 0 so number 2 is broken (and if fixed number
-2 would be broken).
With this commit, the adjustement of sign is done based on original
number, so we get the equivalent of python equivalent methods:
```
Numbers | -8 | -2 | 2 | 8 | 12
DOWN | 8 | 2 | -2 | -8 | -2
UP | -2 | -8 | 8 | 2 | 8
```
opw-2451841
closesodoo/odoo#70923
X-original-commit: 23dd2ea535bea0a57dcac773a81e202135cd2ed6
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The "Starting job X" and "Job X done" logs are very useful to monitor
cron executions over time, or to detect a cron job that has been running
for a long time.
Those logs were dropped by mistake in #62124 - this patch restores them.
closesodoo/odoo#70921
X-original-commit: 0db99a9fb00465266485c7f6c8d16760250152df
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Steps to reproduce the bug:
- Go to Project app
- See the overview of any project
- Select at the top right another company with a different currency. But keep the company assigned to the current project selected
Problem:
The new currency is changed in the project overview, but the values are not converted to this currency.
opw-2479364
closesodoo/odoo#70902
X-original-commit: 7f9cacd40d185bb7c943bd2adb7de1ef8a39c367
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>
Before this commit, status codes were partially handled and users may not had a proper feedback on the status of their payment.
Task #2517498closesodoo/odoo#69948
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Currently, the default invoicing policy is based in `delivered`
quantity since commit: https://github.com/odoo/odoo/commit/3ad4abe171e8e7e86ed0e7b7f000e734d8a2ad92
but due to that onboarding flow is often broken/very complex.
hopefully the statement 'in countries with anglosaxon accounting, that's mandatory' is exagerated.
So in this commit, Default invoice policy is set (back) to
'Ordered quantity'
closesodoo/odoo#69825
Taskid: 2443371
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit, some requests could be sent to the actual IAP
servers during testing. These calls weren't always mocked as many
of these requests are sent in background while performing usual
tasks such as creating a bill.
Now, any call to the function iap_jsonrpc during testing will result
in an AccessError.
closesodoo/odoo#70925
X-original-commit: f31f1972ff0e35deb3005ce160930b70ddc8e531
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
This reverts commit d89562e8fe473692296cb209651beb2ce7a715e4.
Since this commit, the taxes mapped by fiscal position wasn't managed by the _fix_tax_included_price_company method anymore.
Otherwise, some customizations exist on this method that are no longer called.
The 2527940 issue is also due to a remaining bug: the total_excluded price should be divided by the quantity but:
- what if the quantity & price_unit are both signed?
- what if the number of digits for price_unit and the currency are different? Should we skip the rounding of taxes?
Since this commit is not perfect and has a lot of dependencies in others modules, we decided to revert it.
Original PR: https://github.com/odoo/odoo/pull/68997
Revert PR: https://github.com/odoo/odoo/pull/70858closesodoo/odoo#70914
Issue: 2527940
X-original-commit: def7d7bb0231fef38e044803b245c9b990a90216
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Before this commit, when the user edits the description of a task with
use_pad=True and then change the project of this task to one with
use_pads=False. The description written in the pad server is not copied
in the description field of the task.
This commit copies the content of the pad for this case when the use_pad
changes to become False and description_pad is set.
Step to reproduce:
-----------------
1. Go to Settings of the Project App and enable the Collaborative Pads
2. Go to the Project App, in the Projects dashboard (kanban view of projects)
3. Create two Projects (one called "Project A" and the other called "Project B")
4. Edit the Project B to activate the pad, that is, check the Use
collaborative pads checkbox.
5. Go to the view list of tasks in the "Project B"
6. Click on "Create" button to create a task in the task form view.
7. Write a description for this task.
8. Change the project of this task by the "Project A". With this change,
the collaborative pad is disabled for this task since the Project A has
not the pad, and then the description field is empty rather than have
the content that we have just written.
task-2515150
closes#70401closesodoo/odoo#70917
X-original-commit: 32a8f598d6a958f2a08b204524007cc075697fda
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Before this commit, in Project App, when the "Collaborative Pads" is
enabled in the Settings of this app, if the user create a task without
project or in a project that has not the pad enabled and he writes a
description for his new task and select (another) project in which the
pads is enabled then the description field in the form view changed to
have the collaborative pad and the problem is the description is not
copied in the pad and seems erase/delete for the user.
This commit checks if the pad_content_field is not empty after
generating the pad url for the new task/record, if it is the case then
we copy the content in the pad and the user can continue his edition
before saving the task/record.
Step to reproduce:
-----------------
1. Go to Settings of the Project App and enable the Collaborative Pads
2. Go to the Project App, in the Projects dashboard (kanban view of projects)
3. Create two Projects (one called "Project A" and the other called "Project B")
4. Edit the Project B to activate the pad, that is, check the Use
collaborative pads checkbox.
5. Go to the view list of tasks in the "Project A"
6. Click on "Create" button to create a task in the task form view.
7. Write a description for this task.
8. Change the project of this task by the Project B. With this change,
the collaborative pad is actived for this task since the Project B has
the pad, and then the description in the pad is empty rather than have
the content that we have just written.
task-2515150
closes#70401
X-original-commit: d2b55c775d705128fa65c859c5f47bdaf4b705fe
- fix missing access rights when handling feedback data
- redirect customers to the payment confirmation page when notification
data are not acknowledged by PayPal, rather than displaying an
internal server error
task-2494916
closesodoo/odoo#70885
X-original-commit: 948c22243c88dd905f1a7838f6fba75f44f06b2a
Related: odoo/enterprise#18349
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
In Ogone's backend, it is possible to remove `CARD.CARDNUMBER` from
Flexcheckout's feedback data (Configuration -> Technical information ->
Transaction feedback -> Alias gateway and Tokenization -> Dynamic
parameters). Since this is the configuration that was suggested to Odoo
customers migrating from a previous version, we must be able to process
feedback data when the card number is missing.
This commit creates an anonymous card number ('XXXX...') if one is not
provided by Ogone.
task-2494916
closesodoo/odoo#70896
X-original-commit: 272c4259624d88e2d061c6418109d4e0c2dbfb2d
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
Issue
- Install "Contacts" & 'base_address_extended' modules
- Go to contacts and create a contact with value:
- street name : Chaussee de Namur
- House : 40
- Save and edit again
- Set country to 'Netherlands' then save.
Address not splited well (wrong values for street name and house).
The issue is not present in UI but is in tests.
(Issue in UI from odoo 14.0+)
Cause
There is 2 '_split_street_with_params'
(inverse function that set street fields):
- partner_autocomplete_address_extended (removed in 14.0)
- base_address_extended
The 'spliting' logic is not the same in both function.
In UI, looks like it does not call '_split_street_with_params'
from 'base_address_extended' since no super(Partner, self)...
However in testing, it does call it from module
'base_address_extended' and therefore trigger the issue.
Solution
Adapt _split_street_with_params function
(in 'base_address_extended' module):
If previous field (from 'street_format') to parse
in 'street_raw' is 'street_name', then:
- set `tmp` to: splitted (max 1 split) street_raw
with current field seperator
- set `append_previous, sep, tmp[0]` to:
splitted tmp[0] (first part of splited street_raw) with `rpartition(' ')`
- add 'append_previous' to 'street_name' value
- join 'tmp' values and set it to street
(should equal to what left from `rpartition(' ')` split
+ seconf part of first normal split)
- continue normal parsing flow
opw-2476096
closesodoo/odoo#70886
X-original-commit: 74116c982a5ddef65a05ef90017ac4ce63bdf58f
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
When partner is not selected, Odoo sends name_search request
`[..., ('partner_id', 'child_of', [False])]`. It's not obvious what does such
domain mean ( see #70584 ). This commit clarifies what do we expect to get:
we want all records without restrictions on `partner_id` value.
This also fixes performance issue because domain leaf `('partner_id',
'child_of', [False])` is converted to where-clause `<table>.partner_id in <all
or almost all ids>`
---
opw-2524010
closesodoo/odoo#70873
X-original-commit: 39e0f1fb0f60f309be7f65562911b1236167dce7
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
When clicking on "CRM -> Reporting-> Leads (Leads Analysis)" list and form
views are not correctly set, leading to opportunity views. In this commit we
* have changed the list view from ``crm_case_tree_view_oppor`` to
``crm_case_tree_view_leads`` to ensure we use the right view;
* we are now able to open form view from the list view like all other views;
When clicking on "Teams -> Reporting (on a team vignette) -> Leads" list
view used is the opportunity one. We fix it by correctly setting action
views for ``action_report_crm_lead_salesteam`` reporting action.
Task-id : 2497936
closesodoo/odoo#69575
Related: odoo/enterprise#18338
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The FieldChar and the "Emoji" fields support a "onchange_on_keydown" attribute
that allow triggering the onchange event when the user types into the field.
(Instead of having to wait for a blur event).
This is especially useful, for example, in the social module to refresh the
post preview when the user is typing his message.
The current strategy to avoid spamming this onchange event was to throttle the
method to trigger it at most once every second.
However, triggering it every second could still be problematic in terms of
performances and could cause loading issues (e.g: if you have a large GIF in
your post preview)
To try to mitigate this issue, we changed the strategy from throttle to
debounce and changed the delay to two seconds.
Meaning the onchange will be triggered 2 seconds after the user is done typing,
which still gives a nice "live update" effect without triggering the onchange
too much.
Task-2500821
closesodoo/odoo#69023
Related: odoo/enterprise#17573
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently, when you click the stat button "x Courses" on a contact, you land
on the dashboard of the courses that this user follows. But this information
in not much useful here. You'd like to see information like progress of this
member for each courses, or when the member was last active on a specific
course.
With this commit, when you click the 'x Courses' stat button from a contact,
you will see the list view of model 'slide.channel.partner', having the
default filter for the contact from which you clicked the button. This will
show the additional and relevant information you need, and by removing the
filter, you'll be able to see info about all the attendees and their progress
on courses they follow (Note that here if the partner is a company, you
won't get default filter set but the records will be filtered by domain,
because we need to show courses of current contact and it's children, and
so we have to set domain in action, instead of adding default filter in
action context).
The same way, on the Attendees View of a course (when seeing attendees from the
course dashboard), we add 'Last Action' field, and instead of fixed domain, we
use filter to view attendees of a particular course, removing which can allow
us to view information about all the attendees from all courses.
We also introduce new 'Attendees' menu under 'eLearning > Reporting' that will
show information about all the attendees from all courses, with a default group
of channels
Task Id-2409447
closesodoo/odoo#64152
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The module `@web/js/libs/pdfjs` was imported in the legacy file by PR #70375.
So the file has to be added in external_lib bundle.
closesodoo/odoo#70755
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Move the meeting stat button and kanban pill from CRM to Calendar, purpose is to
allow its usage even if CRM is not installed as this makes more sense since this
field is usually related to Calendar.
Increase query number limit in company leave test, in order to take into account
the newly introduced query in Calendar.
UPG-PR: https://github.com/odoo/upgrade/pull/2423
Task-2514473
closesodoo/odoo#69846
Related: odoo/upgrade#2423
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit,
We were checking for multiple `active_ids` before checking for `active_model` in context,
which was blocking point if user want to use this model with `active_ids` with
different `active_model`.
With this commit,
we are checking condition of multiple `active_ids` if `active_model` is `stock.picking`.
so other users can use this model with `active_ids` without changing any flow.
closesodoo/odoo#70772
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Before this commit, the wrong many2one value could have been
selected in the tour, making it fail later on with the following
error:
```
AssertionError: The test code "odoo.startTour('sale_timesheet_tour')" failed
Tour sale_timesheet_tour failed at step Click on this stat button to see
the SO linked to the SOL of the task. (trigger: button[name="action_view_so"])
```
closesodoo/odoo#70789
X-original-commit: 4210d7663600027d39ccb88b0bcd6e1422f2d452
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Beforehand, when display the journal entries from a bank statement,
some fields (Due Date, Next Activity, Payment status) that are not very
relevant were displayed.
Now, we use the bank & cash view to display the bank statement in a more relevant manner.
closesodoo/odoo#70811
Task: 2459562
Signed-off-by: William André (wan) <wan@odoo.com>
When exporting the tax report's monthly xml with enterprise, the file wasn't accepted by the government in case 0% taxes were used.
Grid 033 is optional, and can be used for custom tax rates. If specified, it MUST always go with grid 403 (giving the tax rate) and 042 (giving the tax amount). In Odoo, we made the choice to use it for 0% taxes, so 403 and 42 will always be present, and always 0.
In community, grids number were missing on the lines' labels, and the codes (used to retrieve the value of each grid when generating the XML) were not correct.
closesodoo/odoo#70792
X-original-commit: add187862f627c4340ef7ca49d8a75e149cb12f5
Related: odoo/enterprise#18305
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
When using the boxed layout, if the business document has a table, its
first row (after the table head) will have a bottom border and the last
cell in the row has a white background.
To reproduce the error:
(Need timesheet_grid. Use demo data)
1. In Settings > General Settings, Change Document Template:
- Select the second template
2. In Timesheets, select list view
3. Select several lines
4. Print > Timesheet Entries
Error: In PDF, the first timesheet line has a bottom line and its last
cell has a white background (instead of grey).
The bottom line should only be applied on row in table header. The
background color should also be applied on first row in table body.
OPW-2478311
closesodoo/odoo#70771
X-original-commit: 88a10bdd8f1d46a8b52be59fe3284cbe284a74f2
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Create a draft payment with payment type and 0 amount.
Save.
The payment type will be overwritten
opw-2495461
closesodoo/odoo#70626
X-original-commit: 86a2819697d5d9d1c32ba902d8a1089acf6110f2
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
William Henrotin