Before this commit: if you scan a barcode to add a product and then
change its quantity, it will use previos `NumberBuffer` that have
been used before.
The solution is to reset the `NumberBuffer` after scanning a barcode.
opw-3170518
closesodoo/odoo#112765
X-original-commit: 1100b518f54c0b8cf29a312e768c1494635059a6
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
According to the method documentation, `Field.write` should return
the subset of record actually write.
But it is not respected at every return, it is not used at all and it generated extra completixy for nothing.
Then remove every return values.
closesodoo/odoo#111108
Signed-off-by: Raphael Collet <rco@odoo.com>
The `_update` of `_RelationalMulti` return a bool but the
others `_update` methods doesn't return anything.
It is actually not used. Also, the `_update` is always called with
a recordset as `value`, then the first part of the method is useless.
Part-of: odoo/odoo#111108
`convert_to_cache` of the `Selection` field type, check that the
column_type is 'int4'. But nowadays (since
a0e05e2ab9), a `Selection` field can
only be a Varchar type.
Part-of: odoo/odoo#111108
This commit improves the ListUserValueWidget to scoll to the new element
when the user adds a new element.
task-2601533
closesodoo/odoo#81241
Signed-off-by: Vray Benjamin (bvr) <bvr@odoo.com>
Changing numeric values using the keyboard arrows did not work on some
fields. This commit solves this problem by adding the necessary
attributes to the numeric (we-)inputs.
task-2601533
Part-of: odoo/odoo#81241
This commit improves the handling of events on the editor's we-matrix.
The fields that make up the list trigger a preview at each input and the
user can navigate through the matrix with the keyboard.
task-2601533
Part-of: odoo/odoo#81241
This commit improves the handling of events on the editor's lists. The
fields that make up the list can trigger a preview and it is possible to
switch from one field to another using the keyboard. Note that the
social media we-list must render at each blur of one of its inputs, so
this we-list does not allow to switch from one input to another with the
keyboard.
As the we-list events changed, the social media block tests had to be
slightly modified to take these changes into account.
task-2601533
Part-of: odoo/odoo#81241
Before this commit: If the Odoo database is shared amongst multiple
users, and another user wants to sync their Outlook calendar with Odoo
Calendar, Outlook will again pull the existing Odoo Calendar events
during the sync and treat them as new events, causing Outlook to send
email invitations to all event attendees.
Steps to reproduce the issue:
1. Create two users in Odoo
2. Create two outlook accounts
3. Change the email of Odoo's users to the same as the outlook accounts
4. Create some shared events with the second user on the first
outlook calendar and vice versa
5. Sync the first user's calendar with Outlook
6. When the events are fetched to the Odoo, sync the second user
=> emails send to the attendees
The solution is to exclude synced events from the first synchronization.
opw-2929673
closesodoo/odoo#112931
X-original-commit: 86862f2527341247b75df155de16b09d44a7eee6
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
What are the steps to reproduce your issue?
1/ Setup
* Create a survey with single select multi choice question
* Create a 2nd question which is also a single-select multi-choice
question, which appears based on the answer selected for 1st question.
* Create a 3rd question which is a text question which is visible based
on the answer to question 2.
* All 3 questions are mandatory
2/ Take the survey
* Answer 1st question in a way the 2nd question appears
* Answer 2nd question in a way 3rd one appears
* Change the answer the 1st question in a way 2nd question should not
appear.
3/ Submit the survey
What is the current behavior that you observe?
Odoo will not allow to submit the survey as it will require an answer
for the 2nd question, even though it should not appear.
What would be your expected behavior in this case?
to be able to submit the survey.
A test tour is added to enforce this logic.
opw-3087514
Task-2987929
closesodoo/odoo#112856
X-original-commit: edb0187ee1ec2c45b7059a2a009a1a361e8ae2cb
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Florian Charlier <flch@odoo.com>
{sale, exhibitor, sale_exhibitor}
Specification:
- Currently, when a user books an event, it redirects to the checkout page;
however, if the user already has some items in their cart, they will appear
at the checkout; if they need to remove them, they must go to the cart page.
It's better to redirect users to the cart page rather than the checkout page.
- When a user enters the booth registration value, it fills the fields name,
email, phone, and mobile, but when the user enters the address of the
order, the same fields are filled by the user, so it is preferred that the
fields value entered in booth registration appears in the address of the
order as well.
This commit done following changes:
- Redirect the review order instead of the checkout order when booking
the event booth.
- By adding the partner to the order, it can propagate the values of the
fields name, phone, and email.
- When a partner is created in the website event booth, the email address is
stored in the name. This commit passes the name and email instead of the
email address so that the partner can be stored with the name.
- If the contact does not have a name or phone number, it will set the
sponsor's name or phone number as the contact.
- Adaptations to the tour to accommodate the above changes
task-3098295
closesodoo/odoo#112525
X-original-commit: ca2bac512000674d1ee55ed3151bbdace2311234
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Before this PR, the bus service's `SharedWorker` sometimes failed
to initialized with data url. This error only occurred on some devices,
on chrome and in incognito mode.
While the specifications specify that `SharedWorker` constructor should
handle data url properly [1], there is no way to tell whether or not the
user browser supports it.
This commit solves this issue by introducing a fallback on simple `Worker`s
since they seem to handle data url correctly in this case [2].
[1] https://html.spec.whatwg.org/multipage/workers.html#dom-worker
[2] https://chromium.googlesource.com/chromium/src.git/+/9801daec162285a1f2c6695682ace5d508ea9b7f
opw-3146671
closesodoo/odoo#112921
X-original-commit: 99ac9538d6ba49161be37318fca541c7e51603f9
Signed-off-by: Stockbauer Matthieu (tsm) <tsm@odoo.com>
Before this commit, since the commit [1] changing the field registry,
the component used for the `kanban.many2many_avatar_user` widget is not
right one.
This commit fixes the issue by setting the right component for the
widget.
[1] 9f4622492cclosesodoo/odoo#112925
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce:
In Working Times, click on "SWITCH TO 2 WEEKS CALENDAR"
for the default calendar used by the company.
Issue:
A ValidationError appears: 'Attendances can't overlap.'
Cause:
To create a two-week schedule, by default,
we will use attendances provided for the company's default schedule.
When we want to switch from a one-week schedule to a two-week schedule,
we first delete the attendances from the schedule to be modified.
However, if this schedule is the company's default schedule,
it will no longer have the default attendances
that we must use to build the two-week schedule.
So we end up with the two "fictitious" attendances
that are used to delimit the two weeks.
With only these two attendances, the constraint of not having
two overlapping attendances is not respected
(because the two attendances created will be modified
to belong to the same week).
Solution:
Check that the calendar to be modified
is not the default calendar used by the company.
opw-3127337
closesodoo/odoo#112912
X-original-commit: 2f56ffbc2f1d3a2afbf51a859a5a5730af06fd6f
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Before this commit, if there were no selection in
`_handleSelectionInTable` because the document was removed (in case the
document was in a removed iframe), the method would crash.
task-3052658
closesodoo/odoo#112908
X-original-commit: 8e23a4191730d5512c9de81c23f8e4e88e99ddb1
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, `commitChanges` was inlining even when the content
did not change. For instance, this event was called on every change of
the record through the "next record" button of the form view.
As toInline is computationally expensive, this commit execute it only
when necessary (i.e. when the content is dirty).
When there is a save action that is triggered in mass mailing (eg.
through the button, breadcrumb, urgent save), if a previous call to
`commitChanges` is still in progress, the inline field migth not be
saved, thus we need to wait for a pending promise.
task-3052658
X-original-commit: 3d43d462758c3c9b3817a7c19ccd88517f8625e1
Part-of: odoo/odoo#112908
Before this commit, openning a mass mailing tried to load an image
that was not present in the module, where the server took some
seconds to respond, slowing down the openning of the mailings.
task-3052658
X-original-commit: d80ed2814730f0074f2c5acf56ca385f6b9513e6
Part-of: odoo/odoo#112908
Before this commit, some operation (eg. move node, duplicate or remove a
snippet from the snippetMenu) in the snippetMenu sidebar did not
trigger the mass mailing commit changes and therefore if no selection
was made in the document followed by a blur was made, no changes could
be recorded and saved by the owl form component.
task-3052658
X-original-commit: 8bd8db97ee0d7774e5aa0495b9a5cc7d695fca67
Part-of: odoo/odoo#112908
When the debug assets option is not activated, the assets are rendered
with a space being trimmed from a string notation using backtick.
This fix, uses the single quote notation to avoid this issue in
`wysiwyg_iframe`. Without that fix, the structure of the dom is wrong
and causes css rules to not be applied.
task-3100202
X-original-commit: c54fcf21aecccac20b2c1d781132ed67df6c20a7
Part-of: odoo/odoo#112908
Before this commit, the sidebar visibility was toggled with a css
transition, each time a change was made in the html_field.
Additionally, the transition was not working properly when opening
a mailing. Because this transition was made for website and this code
is no longer being used in website and is not usefull for mass mailing
we can remove it.
task-3100202
X-original-commit: 21056444562e530fb811095b4805345709295ca3
Part-of: odoo/odoo#112908
In mass_mailing, when there is an element with a background image, the
method html2canvas is used.
On a Mac M1, rendering that snippet takes ±700ms per element that goes
into html2canvas.
The reason is that html2canvas clone all the document of the node that
is passed to html2canvas. This is the document of the mass mailing
iframe (for instance including the snippet menu).
As a rendering is called at each input change in the editable
(eg. editor blur, adding a snipet, ...), the main thread will be blocked
more than 700ms each time the input change.
The reason it is slow is because html2canvas is cloning the whole
document, in order to properly get the style of the targeted element.
Because the element style is already inlined by the to_inline, this is
not necessary to clone the whole document.
In order to make html2canvas instantaneous without changing the lib
source code, the solution is to render from another iframe that
contain only the element to render.
task-3100165
X-original-commit: 8ea22ea04e4d7108ba6920fed3e1898df28a53d8
Part-of: odoo/odoo#112908
Since we use `historyRevertCurrentStep` in `commitChanges`, the tour
`mass_mailing_editor_tour` break because the dropped snippet was
removed on save. We need to wait for the step created by the drag and
drop stop method (when `o_we_already_dragging` is removed).
task-3052658
X-original-commit: 2d09c9663a0e6b44927f0b74235973a1925d3e22
Part-of: odoo/odoo#112908
This commit fixes two issues:
If the user click on a form tab (e.g. A/B Tests) before `toInline`
finishes, `toInline` would not be able to work properly. The reason
is that a parent element is being removed by owl when changing tab.
Similarly, changing the view from the breadcrumb could save a wrong
version in body_arch as the `toInline` could not fully finish because of
the same reason (a parent element being removed).
To solve that issue, this commit inline the `body_html` from another
iframe appended in the body.
This fix also ensure:
- no stale state for the body_arch
- no dependency of owl rendering lifecycle
task-3052658
X-original-commit: f429e8465adcddac5a24d8e178b39f1d20bfe15c
Part-of: odoo/odoo#112908
This commit's purpose is to allow the creation of timesheet even if the
analytic account of the project has no company_id
closesodoo/odoo#112906
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Current behavior:
When importing an order from the sales app in the PoS app, there was a
text showing the "Old price" of the order line. But the actual price
and the Old price were the same.
Steps to reproduce:
- Install the l10n_fr_pos_cert module
- Install the pos_sale module
- Create a sale order
- Open a PoS session
- Import the sale order in the PoS session
- The order line is showing an "Old price" when it shouldn't.
opw-3130969
closesodoo/odoo#112903
X-original-commit: e34c0fb8a51d15176752a1c5526673cf26deadab
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
This commit fixes an issue where the "No records found" helper text is
wrongly positioned below the sample data's records (i.e. not visible)
instead of over them.
This is basically a revert of 9407383a56
due to the changes in the DOM and styling made in the meantime.
But actually we can go further and ensure we always have the ListView's
table present in the DOM. This change allows to simplify the positioning
of the helper and the implementation of the Purchase's dashboard.
Steps to reproduce:
- create a new database **without demo data**
- install "Planning" and "Sales" apps
- with a mobile-like screen size, open Planning
- switch to Gantt view
- in a cell, click/tap on the magnifier button (which is on hover...)
- the many2x view doesn't contain data
=> action helper "No records found" isn"t visible (scroll to bottom to
find it)
closesodoo/odoo#112878
X-original-commit: 766498a36b322ffe9c647616f56f3ba04cc51d96
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Let us have records with values 1, 0, 77, 3 for a float field 'foo'.
read_group allows to get those values in an array with the aggregate
function array_agg:
read_group([], ["foo:array_agg", ...], []) will return
[{ __count: 4, foo: [1, 0, 77, 3], ... }]
We now support the use of array_agg for integer and float fields in
the mock server.
closesodoo/odoo#112825
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
mockReadGroup should not count the value false for a many2one when
aggregating a many2one field with the aggregate function count_distinct
and should always return a number. We fix that.
Part-of: odoo/odoo#112825
Let us have records with values false, 1, 2, 1, 1 for a many2one 'm2o'.
read_group allows to get those ids in an array with the aggregate function
array_agg:
read_group([], ["m2o:array_agg", ...], []) will return
[{ __count: 5, m2o: [null, 1, 2, 1, 1], ... }]
We now support the use of array_agg for many2ones in the mock server.
Part-of: odoo/odoo#112825
-The stock valuation, input and output account were wrong. Now correct accounts are set
-Removed the 6% VAT. Is not used for years now in the Netherlands. It is now 9%
-Removed the "BTW overige" for sales/purchases within EU and outside. These taxes do not exist. "BTW overige" is only domestic
-Renamed 'EU landen privaat' for better name B2C (that is what it is used for)
-Added valid TAX Identification number on company
-Changed the state to a state within the Netherlands and not in the Dutch Caribbean
closesodoo/odoo#112493
Signed-off-by: John Laterre (jol) <jol@odoo.com>
This commit is a refactoring of the domain selector to simplify it.
The component DomainSelector now uses less sub components.
Consequently, the code is centralized in fewer files and more readable.
closesodoo/odoo#110978
Task: 3149707
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Following up https://github.com/odoo/odoo/pull/112692 that avoided the use
of the 'Number' javascript function in the 'product_discount_field' widget, the
call to that function was left in the code. It is useless and can be removed
since the value of the new field used, the property field 'props.value', is
already a float.
closesodoo/odoo#112891
X-original-commit: fb8b217f8bd2323d33bbeb949f35cd1620557960
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
`handle_error`'s docstring states that it returns a `Response`, but in most case `HttpDispatcher.handle_error` returns an `HTTPException`.
After discussion, the implementation is correct, `handle_error` should be documented to return a WSGI Application (a callable taking an `environ` and a `start_response` callable) instead.
closesodoo/odoo#112889
Forward-port-of: odoo/odoo#112690
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
If you have a lot of attendance spread accross various employees and various dates,
the report takes ages to load (or your browser freezes and you can't access reporting).
And if it loads, the report is unreadable anyway. Use a default filter to always
display user friendly graphs. Since we group by day, a default period of a month seems
like a good compromise.
To reproduce the issue:
- install hr_attendance
- use a script to create some attendances (ex: create 300 employees and 30
attendance for each, spread randomly in the last 3 years)
- click on "Reporting"
opw-3167099
closesodoo/odoo#112879
X-original-commit: 59bf5d4c5e7c95c6f561140f71634d84a12568a0
Signed-off-by: Kevin Baptiste <kba@odoo.com>
To be able to compute the taxes offline, the POS JS code mimicked the
`compute_all` function in `account_tax.py`. At some point, the POS added
an extra field on `account.tax` (see:
https://github.com/odoo/odoo/commit/8fb53c53c3128e8cea7ef20b9ab4946ac2f9b7d9):
`real_amount` which is defined as:
real_amount = tax.amount * sum(tax.repartition_line.factor)
Then, when fetching the data from the server to the client, the
`real_amount` was passed in place of the `amount`.
But then, the `amount` field in the JS is no longer the same as in the
python code and it is very error prone. In addition, it's easy to get
rid of this extra field by using the sum of the factors from the
repartition lines.
Now, we pass the sum(tax.repartition_lines.factor_percent)/100, which is
equivalent to sum(tax.repartition_line.factor) to the client, and use it
in the `compute_all` as done in the python function, and leave
`tax.amount` untouched.
Both `compute_all` functions now operate using the same `tax.amount` and
we get rid of the `real_amount` field.
closesodoo/odoo#112063
Related: odoo/upgrade#4307
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Before this commit, the field's description was stored on the
component and this component was then registered.
Now, an object describing the field is used on registration the same way
as it is done for views since https://github.com/odoo/odoo/commit/b828cfc72c587d0b73fcc5459695705640437671.
This split the component's description (props, template, ...) of
the field's description (displayName, supportedTypes, ...) and makes
it clearer.
closesodoo/odoo#112498
Task: 3171520
Related: odoo/enterprise#37105
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When validating a confirmed picking, if in the meantime the user
added an SML with a kit, the done picking will have some not-done SM
for each kit component.
To reproduce the issue:
1. Inventory > Operation Types, edit Receipts:
- Show Detailed Operations: True
2. Create three products:
- P_kit
- P_compo
- P_other
3. Create a kit BoM
- Product: P_kit
- Components: P_compo
4. Create a planned receipt R
- Operations:
- 1 x P_other
5. Mark R as todo
6. Add two detailed operations:
- 1 x P_other
- 1 x P_kit
7. Validate R
Error: The SM for P_kit has been replaced with its component, which
is correct. However, the done quantity of the new SM is 0, it should
be 1
At some point, because the done quantity of SM_kit is gerater than
the demand, we create an extra move:
https://github.com/odoo/odoo/blob/24f2e3f73498e5eb180a6793de6c25efd414aadb/addons/stock/models/stock_move.py#L1529-L1534
So, the goal is to create a second SM_kit_02 with the expected
demand. Then, we merge this new SM_kit_02 with SM_kit:
https://github.com/odoo/odoo/blob/24f2e3f73498e5eb180a6793de6c25efd414aadb/addons/stock/models/stock_move.py#L1491-L1493https://github.com/odoo/odoo/blob/5f8da70b5b1f313e9b676846e55e84621f55e734/addons/mrp/models/stock_move.py#L239-L242
As shown above, we explode SM_kit_02 which gives SM_compo. However,
we don't explode SM_kit. Thefore, we will not be able to merge
SM_compo with SM_kit. In such situation, we should also explode
`merge_into`.
For the explode method to work with SM_kit, we need to change few
lines: as said at step 4, the receipt is not an immediate one.
However, we still have a case here where the SM has a quantity done
without any demand and only the done quantity matters (as we are
validating the receipt)
OPW-3015933
X-original-commit: 35a5b83b93fceac4073689edd74d680bed09a143
Part-of: odoo/odoo#112814
When manually setting a discount on the first line of a sale order having more than 3 displayed lines, the product_discount_field widget prompts the user if he would like to apply the same discount to all the lines.
This fails to apply when the localization uses a comma as decimal separator instead of a dot or uses a digit grouping symbol. This is because the widget calls the JS function Number() on the string that was entered by the user in the discount field, after it was formatted according to the localization.
Taking the number 1500 as an example, different cases are:
- Number("1500.0") gives 1500
- Number("1500,0") gives 'NaN'
- Number("1,500.0") gives 'NaN'
- Number("1.500,0") gives 'NaN'
This result is then used to apply the discount on the remaining lines of the sale orders. Using 'NaN' will result in a 0% discount.
The use of Number() can be avoided by using the property field 'value' of the product_discount_field widget.
opw-3127690
closesodoo/odoo#112734
Forward-port-of: odoo/odoo#112692
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
By adding an explicit order to the queries within `existing_accounting` the PostgreSQL query cost drops to `cost=0.84..1.78 rows=1 width=4` from `cost=13061.20..18895.19 rows=1 width=24` (on my local dev machine).
closesodoo/odoo#112842
X-original-commit: ab34d6b0273c6766757f0596ca5f62458a9d5ab5
Signed-off-by: John Laterre (jol) <jol@odoo.com>
The date from would not be formatted on leaves spanning multiple days.
closesodoo/odoo#112830
X-original-commit: 7a392e9af999084d9dddf0f82affd6d539f5d907
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Werkzeug 1.0 colorised some outputs on POSIX IFF `click` was
installed.
Since 2.0 (pallets/werkzeug#2012) werkzeug unconditionally colorises
the log on POSIX. This is annoying when using output redirection (let
alone logging to a non-stream), as werkzeug will dump ANSI color codes
to the non-term stdout and thus the logfile.
Werkzeug provides no official knob to control this behaviour, but it
does have a secret flag which is normally used to check if colorama is
available on windows (so the ANSI codes are not output if colorama
won't be interpreting and stripping them on the way out). Since
`werkzeug.serving` is available in pretty much all versions, we can
just (un)set this flag if not logging to a tty, and versions 2+ should
pick it up and disable colorisation.
closesodoo/odoo#112829
X-original-commit: 7c9f883dc508a7a8a45bf7bf7e900da0be9b34be
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
*: base, http_routing, mass_mailing, web, web_editor, website_slides
In some situations `werkzeug.wrappers.Response` are used instead of
`odoo.http.Reponse` that extends it.
This is a problem because since [1] the calls to `set_cookie` expect it
to accept the `cookie_type` parameter, which is not the case in the base
werkzeug implementation.
This commit replaces the `werkzeug.wrappers.Response` by
`odoo.http.Response`.
[1]: https://github.com/odoo/odoo/commit/2cbda6c98ee947cea1d06c09880eee8c758304a8closesodoo/odoo#112827
X-original-commit: 28da08292b7028575e628c5ad846fc05d30498f2
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
pedrambiria