The overridden method was not properly renamed and converted, with this fix we can now filter orders
based on their table.
closesodoo/odoo#93790
X-original-commit: cf8cf179914435b48c1698f8c873bdf2f0a566b6
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
When a field in a form has a conditional visibility, its potential value
is not sent once the form is submitted if the conditional visibility is
not met. Before this commit, that was not the case for file fields.
Steps to reproduce the bug fixed by this commit:
- Drop a form or go to /contactus
- Add a file field
- Put a visibility condition on this field and save
- Fill the form, respect the visibility condition you have introduced,
add a file in the previously added field.
- Before submitting the form, make sure the visibility condition is no
longer met and then submit the form.
Your file is part of the submitted data by mistake. As it was hidden at
the time you submitted the form, it should not have been sent.
opw-2856054
closesodoo/odoo#93783
X-original-commit: 159106bf873b866b9ce93e48a45f7d1d9346aa45
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This works follows [1] which already hid lots of options which were not
supposed to show up on some images. That concerned mainly t-field images
and others. This commit is about media elements (images, icons, ...)
which are editable roots, meaning they carry the branding of the portion
of the view they belong to.
In 14.0, such root media elements were simply not editable. Indeed, the
media tools (which were amongst text tools of summernote) simply did not
show up. With the new editor of 15.0, all media options were converted
as "snippet" options for the website editor. The system being entirely
different, explicit conditions for the options to not appear had to be
made.
Technically, some of those options may work on editable roots. With [2],
the "class" and "style" attributes are savable on such items... unless
they are computed. In the future, we may allow more attributes. The
problem in allowing some options to appear (depending if they work on
a given element) is that it would require:
- knowing which attributes an option modifies (class? style? others?)
- knowing which attributes are computed in the qweb view
We may consider improving all of that in future versions, but in stable,
we decided to simply hide all media options on editable roots.
Theoretically, some non-media options could still appear on non-media
editable root elements and not work... but probably no standard option
matches this case.
[1]: https://github.com/odoo/odoo/commit/e707789d43a5754dc2a28192e5502cc14eaca73f
[2]: https://github.com/odoo/odoo/commit/8579c0cae839c615415120b79d6ec22c71f7affd
opw-2817765
opw-2854285
opw-2864584
closesodoo/odoo#93751
X-original-commit: 9dc76ce4b0a646563a29a431e28cf96218a66991
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
issue: The debug-assets didn't work anymore. The t-cache placed on the
header allowing not to redo this one for each rendering did not depend
on the debug mode.
closesodoo/odoo#93590
X-original-commit: 3061a484168ff21e3ae7e40ce691d299b63484a4
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Signed-off-by: Christophe Matthieu (chm) <chm@odoo.com>
The getAll and getEntries functions have a cache, i.e. the array
they return is lazy evaluated once, and then kept until the next
update of the registry. Before this commit, those functions
returned their own version of those arrays, not a copy. As a
consequence, someone that would modify those arrays would actually
modify the arrays in the cache, and every subsequent calls to those
functions would return those modified arrays, which would not
correspond to the actual state of the registry.
closesodoo/odoo#93767
X-original-commit: c3d0449bb09a012d9ce97bfc6401476cf8a57c26
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Chrome did an update on which LAN devices are not accessible trough websites (but would still be accessible in `localhost`) ending in CORS error when trying to reach the device. More information:
https://developer.chrome.com/blog/private-network-access-update/
Before this commit:
A lot of customers were confused as of why their printers suddently stop working without any changes.
After this commit:
The error message have been improved to also guide people to solve this issue (creating an HTTPS certificate).
Note that it is not possible from the JS code to say if they are concerned by this issue or not as the error given does not specify explicitly if it is a CORS error or something else, see:
https://stackoverflow.com/a/6734427
OPW-2850019
& many more like:
OPW-2856164
OPW-2858658
OPW-2857076
closesodoo/odoo#93764
X-original-commit: e97b14f2bfe3d8b096b42c6bc3cf35537367aff7
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
(i.e. orden de compra, guia de despacho) if they are enabled
closesodoo/odoo#93763
X-original-commit: afde2ab2cd44078b812e3fdd1553a55650fa45c0
Signed-off-by: Josse Colpaert <jco@odoo.com>
Previously, when importing both the default export and named imports
with a trailing comma, we would transpile into an object where the first
keys were the named imports, including any trailing comma, and
concatenating with the default import with a leading comma, this means
that the trailing comma would transpile to two successive commas which
is not valid syntax.
This commit fixes that by putting the default import first, and adding
the named imports after, preserving the trailing comma if any, but
precluding the possibility that we get two commas back to back.
closesodoo/odoo#93693
X-original-commit: 798d2f2c6e8a496f4ce0cd3c4f1609693e692254
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Purpose
=======
It becomes unclear what the button does once the search view doesn't
filter on the related job's applications (aka the filter is removed
for example)
Taskid: 2884356
Part-of: odoo/odoo#93684
After opening the configurator wizard in "edit" mode (through the pencil
icon shown next to the product in edit mode), if you clicked either on
the "Cancel" button or on the "X" to leave/close the wizard,
the product was reset on the SOline.
Cancelling a modification should keep the state before the modification and
not reset the line.
This is a regression from the behavior in saas-12.3.
closesodoo/odoo#93666
X-original-commit: 0f0d3a20910d20221f9b80fc290f743091ecd8b7
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Follow-up of https://github.com/odoo/odoo/pull/93330
Commit above renamed "MediaPreview" to "CallDemoView".
However, it mistakenly did not rename the SCSS rules that
referred to `o_MediaPreview`.
As a result, some styles were no longer applied, like buttons
being an overlay on top of camera stream.
closesodoo/odoo#93724
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit ensures that, when creating a private task, the current user
is always part of the assignees.
This commit also adds tests on the different `project.task` creation scenari
to ensure it gets not broken in the future.
task-2818486
closesodoo/odoo#89041
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Before this commit, it was possible to assign a non-personal stage on a private task,
which is a nonsense as the task does not belong to a project. Only personal stages
should be set to a private task.
After this commit, if a non-personal stage is set on a private task, a UserError is raised.
task-2818486
Part-of: odoo/odoo#89041
Current design, especially related to views in small viewports, has
been revamped in order to increase readability and to be more coherent
with the one in large screens.
Task-2813949
closesodoo/odoo#87915
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Current SCSS is replaced with global Bootstrap classes, in
order to reduce code lines and to increase performance.
Task-2813949
Part-of: odoo/odoo#87915
Current behavior:
If you stay in idle too long on the payment screen while doing a
payment the screen would go back to the floor screen
Steps to reproduce:
- Have PoS installed and setup restaurant
- Go in the PoS restaurant
- Go in any table add some product and go to payment screen
- Click on any payment method
- Wait some time and you should go back to the floor screen
opw-2849939
closesodoo/odoo#93689
X-original-commit: 3c90b940e4ffa9208517974a6238e64e09f03475
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Task 2843455
When an exchange difference is linked to a payment, not an invoice,
it is not displayed in the payment widget even though an exchange
difference move is created and matched with the invoice.
Exchange difference should be displayed when it's linked to the payment as well.
closesodoo/odoo#92069
Signed-off-by: Laurent Smet <las@odoo.com>
For the kanban_activity view (e.g.: in the CRM module), when we have enough
entries to require the scrolling, dropdowns are not displayed at the correct
location.
Furthermore, in kanban views, when dropdowns are opening on the edge of the
parent element (e.g.: in Documents), the dropdowns are partially hidden and not
accessible by the client.
Step to reproduce the issue:
1) Install CRM and Documents module
2) Go to CRM and create multiple leads with at least one activity
3) Go to the Activity view and scroll down and click on an item. The dropdown
is not placed at the correct location -> BUG 1
4) Go to the Documents modules and check the activity (the small clock icon)
of a Document on the right most column. The dropdown is hidden by the
description of the file.
Solution: Firstly, the parent container of the Kanban Activity view did not had
the `overflow: auto` property activated. Consequently, while the children were
somehow taking all the spaces of the screen, Popper (the third party that
handles the dynamic positioning of the dropdowns) was wrongly computing the
positionning.
Secondly, dynamically creating the dropdown via Javascript (through the
JQueryInterface of the Dropdown class in Bootstrap) somehow allows to fix the
issue in Documents. Consequently, it is important to keep them into the
Javascript and not move the arguments into the XML.
opw-2827873
closesodoo/odoo#93661
X-original-commit: 38fa6a70b70dac0d511be7952c496a5178f9c40e
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Signed-off-by: Desausoi Laurent (lade) <lade@odoo.com>
If a list of emails is bigger than 500, the email was sent several
time to some people.
The mail_values content was not reset between each batch, so if 1200
emails are sent, 3 mail.mail records were created for the emails in
the first group.
closesodoo/odoo#93658
X-original-commit: f838a0cc36e51e0f47daeec6522df8e9832aad2c
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, the DateTime range for getting events was six years,
while the Microsoft range limit is five years.
opw-2819858
closesodoo/odoo#93657
X-original-commit: 56f9b7646269d953c3068a12f20436d3afc970b1
Signed-off-by: Arnaud Joset <arj@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
When you are in anglo saxon accounting with posting stock changes at the
end of the session, we get an issue by using the refund feature in
backend.
If you have an order invoiced, and want to refund it, it'll create the
picking of the order immediately, which is not normal as it should only
be done when there is an invoice.
The problem is that the value of the field 'to_invoice' from the
original order is copied to the refund, and so act as the invoice is
made for the return.
To avoid this behavior, we are avoiding to copy it.
OPW-2848356
closesodoo/odoo#93645
X-original-commit: e8ef74397c0b02d051823142c3457413aabfeb21
Signed-off-by: Masereel Pierre <pim@odoo.com>
Steps to reproduce:
- Install puchases, accounting, contact
- Create a new company with a bank account
- Create a new person contact linked to the previous company
- Make a purchase order from that person
- Make a vendor bill using the auto-complete as the previous PO
Issue:
The bank account field is not filled
Cause:
The _prepare_invoice function tries to grab the bank information
from the contact on the PO. But in the case of a person of a company,
this information is stored in the parent company. Resulting in an empty
value
Solution:
Use the field "comercial_partner_id" to get the bank id. As this field
will use the parent company if the current partner is a person.
opw-2849706
closesodoo/odoo#93487
X-original-commit: c5f94e84dd5d6ec108484425d348053961bd13ff
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
This commit aims at unifying the UBL formats for invoices and credit notes.
Starting from the work of LAS, the module account_edi_ubl_cii contains the templates for UBL and CII,
and provides inheritance for UBL: UBL 2.0 < UBL 2.1 < UBL Bis 3.
It contains also the formats E-FFF, EHF3 (fully covered by Bis 3), NLCIUS, XRechnung (in UBL), Factur-x (the only one in CII).
All these formats are also improved to pass the ecosio validator and/or the country specific validator
(for Factur-x: the validator from the FNFE, and Chorus Pro).
Note that the xml files generated contain the pdf of the invoice/credit note encoded in base64.
An xml file alone imported in Odoo will thus automatically retrieve the pdf.
Before generating the xml files, we now also check a series of known constraints and possibly display
a warning on top of the move view if some are not enforced (the xml file is generated anyway but it might not be valid).
Tests were required: a new module was needed with dependency to the tested l10n: l10n_account_edi_ubl_cii_tests.
The prefix "l10n_" prevents runbot from launching the tests everytime.
The following modules are removed:
* account_edi_facturx
* account_edi_ubl
* account_edi_ubl_bis3
* l10n_no_edi
* l10n_nl_edi
* l10n_be_edi
Task: 2628093
See also: odoo/upgrade#3581closesodoo/odoo#93135
Signed-off-by: Laurent Smet <las@odoo.com>
Currently, when creating a new stage, even if there are sales team(s)
available, the `team_count` always displays zero, because it is a
computed field but is not dependent on any other field.
This commit improves the behavior by small hack, which makes the
compute method dependent on `team_id` field so that it can be
triggered while creating a record.
taskID-2819559
closesodoo/odoo#88738
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently, when creating a new user, even if there are multiple
companies to select from, the "Multi Companies" related fields are
not visible in the form view. However once the record is saved, they
simply appear. This happens because the `companies_count` field based
on which the visibility changes, is a computed one but is not dependent
on any other field, and so while creating a new record, the value is
always zero for our compute field.
This commit improves the behavior by making the compute method
dependent on `company_id` field so that it can be triggered while
creating the record (thanks to default value being set for this field),
and thus shows / hides the company related fields properly.
taskID-2819559
Part-of: odoo/odoo#88738
When create a sale order from a opportunity the default value
for the team_id was wrong and thus the team_id was not properly set
Solution
--------
Return the id of the team not a tuple that contains the id of the team
closesodoo/odoo#93631
X-original-commit: 9c172745dcb9aa755079e2b63a7e9e69442b867f
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This reverts commit f4235243700d4a52117ca6750c44afb10142bf42.
This commit introduced an unwanted effect, by using the
`type_control_ids` to allow an account type on a journal.
But it was intended as a constraint, to limit the account types
allowed on the journal and exclude all the others.
In this case, by allowing the type of the account
`data_account_type_direct_costs`, it also excluded all other
account types on the Vendor Bill journal.
closesodoo/odoo#93668
X-original-commit: 60aa39ab988434a80993e503e28a5f4f9a49f815
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Before this commit, the test utils that trigger an event (e.g.
click) didn't check whether the target of the event was visible.
As a consequence, when writing a test, one might trigger an event
on an invisible and undesirable target, and don't understand why
it doesn't work due to the absence of feedback. This commit
improves that situation by throwing an error in those sitations.
Obviously, some tests relying on the former behavior needed to
be slightly adapted.
closesodoo/odoo#93549
Related: odoo/enterprise#28360
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The provided default `mail.template` does not exist anymore, which was leading
to an empty message.
This commit, sets the right `mail.template`.
task-2858277
closesodoo/odoo#93622
X-original-commit: b4cb62fdd9eb692c4000011e3bdbee39788c54d0
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Before this commit, since the removal of the modelManager from the
scope of some components, the call systray menu would never show up
as messaging was never defined.
closesodoo/odoo#93616
X-original-commit: ab13e5a8649d82c985163cd82f0c43e4975afca7
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Follow-up of https://github.com/odoo/odoo/pull/88950
Commit above introduced `MessageSeenIndicatorView`.
Conceptually, `MessageSeenIndicatorView/messageSeenIndicator`
is required. However, the current implementation make it
possible to have a view without the related pure logic record.
This commit simply guards the template to take this implementation
detail into account, as to not make it crash.
Note that future changes in modelling will enforce
`MessageSeenIndicatorView/messageSeenIndicator` being required, so
that we won't need to guard it in template. But this is a fix in
stable version, so it's safer to keep minimal code changes.
closesodoo/odoo#93599
X-original-commit: 495379b20c077ab27b91850673222893e0d14a8e
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Current behavior:
If you made a sales with a partner wich is part of a company.
And then archive that partner and click on the sales smart button
from the company the sales from that partner wouldn't appear in
the list. The problem is the same for the invoices
Steps to reproduce:
- Install sales and contacts
- Create a sale for a partner (e.g. Edwin Hansen from Gemini)
- Archive that partner
- Go in the company view, click on sales button
- The sale from the archived partner do not appear in the
company sales list
opw-2850115
closesodoo/odoo#93587
X-original-commit: 8e46a00356a85b42078637d97ec6d0ef204f370a
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
As we are trying to create custom move lines before unlinking the
reserved ones, we can be unable to reserve the lot we need if already in
another move line.
closesodoo/odoo#93508
X-original-commit: 64cc7ef34341043cf3a9a87e0a073cd9587696b5
Signed-off-by: Masereel Pierre <pim@odoo.com>
Before this commit:
- When project is created from SO, the quantity of SOL is set in allocated hours.
Then, when navigating to the 'invoicing' tab and adding an employee mapping,
the `allocated hours` is reset to 0.
- When manually removing the SOL of a project, the allocated_hours is reset to 0.
After this commit, the above issues have been fixed.
task-2788878
closesodoo/odoo#93580
X-original-commit: dbcdefc20c676248438643a97fa62ca7fd197671
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Mahendrasinh Barad (mba) <mba@odoo.com>
Create an empty database and start 2 http workers, go on the web app
menu and install website (don't install website via -i). Once website is
installed, you are redirected on `/website/configurator` but the route
does not exist and it fails with a 500 internal server error.
The problem is due to an invalid registry manipulation introduced in the
saas-15.3's httpocalypse. When new modules are installed the registry
must be reloaded in all workers. The function that determine if the
registry must be reloaded and reloads it is `check_signaling`.
When the current registry is up-to-date, it is returned as-is by
`check_signaling`. When it is outdated, `check_signaling` creates and
returns a new fresh registry; it does not nor discard nor change
in-place the previous (outdated) registry, it is up to the callee to
discard the previous registry itself.
closesodoo/odoo#93579
X-original-commit: 23bdcc3fd31e6908ee6737cb74787aefa5d057a5
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Julien Castiaux <juc@odoo.com>
Remove leftover translations from some modules that no longer exists.
closesodoo/odoo#93572
X-original-commit: d16d24a360ffe1a703e012746fb95efbe16536ad
Related: odoo/enterprise#28352
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This dialog hadn't been correctly adapted since the move to owl2.
As a consequence, it couldn't even open itself.
closesodoo/odoo#93571
X-original-commit: 71a0142940d46c2e954310477d6b4d7e7d14c587
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Jacky (trj)