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>
This commit improves the helper string for 'My Pipleline' a bit in case
the logged in user has not joined any sales team yet. Also, if user is
having enough rights to access 'Configuration >Sales Team' menu, the
helper string will now contain a link to this menu as well.
task-2846401
closesodoo/odoo#91304
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit added timesheet demo data based on 'milestones' and 'manual'
invoicing policy.
task-2816490
closesodoo/odoo#88852
Related: odoo/enterprise#26259
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
As it has no action and no children, this menu is an old ghost,
taking place in the code & database(s) for nothing.
closesodoo/odoo#93481
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
In some cases, an unexpected line "Undefined" is displayed on the graph
of the Forecasted Report
To reproduce the issue:
1. Create a storable product P
2. Process a receipt R01 with 1 x P
3. Process a delivery D01 with 1 x P
4. Create and confirm a planned receipt R02:
- Scheduled date: In 7 days
- Operations: 1 x P
5. On the form of P, open the On Hand page
6. Back to the form of P, open Forecasted page
Error: An unexpected line "Undefined" is displayed on the graph and is
always equal to zero
Suppose the user does the same as above without the step 5: there won't
be any unexpected line on the graph. Here are the explanations: after
step 3, a quant for P exists and its quantity is zero. So, suppose the
user doesn't open the "On Hand page" and directly opens the Forecasted
Report. Considering its definition:
https://github.com/odoo/odoo/blob/a9dc406b52a3702f6901f686503e8d841f81724e/addons/stock/report/report_stock_quantity.py#L41
Four things happen (we only consider the state `forecast`):
- The SM of R01 is propagated from `today minus 3 months` to `yesterday`
- Same for SM of D01
- The quant is propagated from `today minus 3 months` to `today plus 3
months`
- The SM of R02 is propagated from `in 7 days` to `today plus 3 months`
-> Thanks to the quant, there are some data between `yesterday` and `in
7 days`
Let's now consider the step 5. Opening the page leads to:
https://github.com/odoo/odoo/blob/b22a23435a0cc42b7084ded21dbd4ef3a4a2113e/addons/stock/models/stock_quant.py#L621-L630
where, in `_quant_tasks`, we unlink the zero quants:
https://github.com/odoo/odoo/blob/b22a23435a0cc42b7084ded21dbd4ef3a4a2113e/addons/stock/models/stock_quant.py#L562-L565
Therefore, in the `report.stock.quantity`, we are creating a hole
between `yesterday` and `in 7 days`. When performing the RPC
`read_group` to get the graph data, a key-context is defined
(`fill_temporal`). Thanks to this, the hole is filled by the server but
the generated data do not mean anything:
https://github.com/odoo/odoo/blob/80ec56bd246869567c3bbc746be1ebce52970a63/odoo/models.py#L2005-L2007
i.e., the value of `empty_item` is:
```py
{'id': False, 'date_count': 0, 'product_qty': False, 'product_id':
False}
```
Later on, on JS-side, when processing the `read_group` result:
https://github.com/odoo/odoo/blob/ee84815f2b57ed7ba096d3390aa8c6509e3f7845/addons/web/static/src/js/views/graph/graph_model.js#L235-L241
We are grouping by date and by product. As explained above, some data
have an undefined `product_id` so, in such case, `labels` will contain a
date and an `undefined` value. This explains why we have two lines on
the graph:
- one for the product P
- one for the data generated by the server to fill the hole in the dates
range
OPW-2800818
closesodoo/odoo#93248
X-original-commit: 0530fffe2343463500273b9b03470847276e64bc
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
The methods to generate the attributes are called all the time in order
to reset the attribute dictionary. The profiler is modified so as not to
display directives in the log that do not exist on the tag.
Issue: attributes could be generated by directives and not be used (for
example on <t>). These attributes could end up unwittingly on the next
node.
closesodoo/odoo#93216
Issue: opw-2859447
X-original-commit: 38724f106c0747aef475991c894e9ee93c1db967
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Signed-off-by: Christophe Matthieu (chm) <chm@odoo.com>
SPECIFICATION
Various change for the partner view:
- Moved the activity widget to the bottom right of the kanban
- Moved the informations badge to the bottom right next to the
activity widget and made them clickable
- Change the address options order and add a small help below
- Change the 'Remove' button function from delete to remove from
the company and add a delete button to the right end.
- Correct some typo
- Add an 'Archived' ribbon to the kanban card
- Change various small things
LINKS
Task-2821356
closesodoo/odoo#89249
Related: odoo/enterprise#26442
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When the html is grouping some records together, there is no exactly one document per record.
In that case, the wkhtmltopdf outlines must not be checked.
closesodoo/odoo#93516
X-original-commit: c1faefce79bae6ff6014e7af7f675e98f5091a07
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Laurent Smet <las@odoo.com>
When generating a PDF report with an action having 'attachment_use' set and when the pdf of at least one record has been already generated but not all, an error is raised for no reason.
X-original-commit: 7ad19283ea5c89a6629c8433b468d1dac3fdad4d
Part-of: odoo/odoo#93516
Each user should be able to reset his own google calendar token.
An admin user (from `base.group_system`) should be able to reset any tokens.
Task-2673934
closesodoo/odoo#83397
Signed-off-by: Arnaud Joset <arj@odoo.com>
We instead use the standard owl.utils.escape.
This allows having less custom implementations of escaping and rely on existing
tools.
Task-2622893
closesodoo/odoo#81293
Related: odoo/enterprise#22850
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Victor Feyens