After https://github.com/odoo/odoo/pull/118738, we start generating a single
cron trigger per recurrence, however it fails to create the cron trigger for
daily recurrences. The main issue happens when the cron is run after the first
trigger of the recurrence. Imagine we have an alarm of 5 minutes before the
event, the call for_setup_alarm from _send_reminder will try to get the next
event in the recurrency to notify. However, the SQL query uses
`WHERE start > now` and if the cron trigger runs before the event is started
(most cases) this query will return the event that we're notifying. This commit
fixes this by checking event by event which is the next alarm tha should be
triggered and passing that date in the context of the `_setup_alarms` call.
How to reproduce?
Install calendar
- Create a recurring event with daily recurrence repeating for 3 days. Invite
Demo, set an email alarm for 5 min before the event and create the event
- A cron trigger will be created for 5 min before the event
- Change your computer's time so that it is 5min before the event
- The cron trigger will be called and it should create a new cron trigger for
the other day, however no cron trigger is created
Issue: SQL query in _setup_alarms in calendar.recurrence is getting the first
event with start > now, however it returns the event that was already notified
Solution: process event by event and check if its last alarm was already set.
If it was, we'll generate an alarm for the next event. If not, we'll use the
same event for the _setup_alarms call
For SMS alarms, we would not even create triggers for recurring events, so this
commit also fixes that.
task-3663455
closesodoo/odoo#151623
X-original-commit: 2da5bf6e9184db23836ea458a1fc53e27be49a1e
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Signed-off-by: Leonardo Pavan Rocha <lpr@odoo.com>
Before this commit, when the company of the employees updated is not
in the allowed_company_ids of the current user (could happen in the
execution of a cron), an error is triggered saying we are not allowed
to create a timesheet for an employee inactive. The reason is because the
employee is not fetched in the check made in the timesheet creation because
of the company of that employee is not in the companies contained in the
environment.
This commit makes sure the companies in the environment are the ones
set on the employees created/updated, to be sure those employees are fetched
in the check made in timesheet creation.
closesodoo/odoo#151656
X-original-commit: ed6b02b6323691f79aa4ff466541eeb9768de1c9
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Currently, if the Send & Print fails in a web-service that happens *after* the PDF generation
(such as UBL) we don't link the PDF and fallback on Proforma if possible.
After this task, if we are in this situation we will link the invoice and not generate the proforma.
Behavior is left unchanged for web-services that fail *before* PDF generation.
closesodoo/odoo#151624
Task-id: 3690897
X-original-commit: b4f051dbdebd71688e13defc993404e9ec8d839a
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
The `sum` function needs to be given a compatible for the `start`
argument.
Instead of using that function for a simple sum of two elements (not
`int`), lets just sum them explicitly instead.
Traceback:
```
TypeError: unsupported operand type(s) for +: 'int' and 'account.analytic.plan'
```
closesodoo/odoo#151738
Signed-off-by: Raphael Collet <rco@odoo.com>
Purpose
=======
This reverts commit https://github.com/odoo-dev/odoo/commit/27a1ccc829d290c8589a535f10b31caaacd6400f which fixed the container height when course name was too long. It added a 'visibility: hidden' style which caused an issue on the course left bar where the progress bar and completed tag are located next to each other.
Instead of adjusting the size of the container we prefer to limit the size of the course name to fit a single line. To do that we use the text-truncate class.
Task-3607404
closesodoo/odoo#151736
Forward-port-of: odoo/odoo#150162
Forward-port-of: odoo/odoo#143136
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Instead of adjusting the size of the container we prefer
to limit the size of the course name to fit a single line
To do that we use the text-truncate class.
Task-3607404
X-original-commit: b94e900b38feac490969d1bb4cb4c0da1a5455a9
Part-of: odoo/odoo#151736
This reverts commit 27a1ccc8 which fixed the container height
when course name was too long. It added a 'visibility: hidden'
style which caused an issue on the course left bar where the
progress bar and completed tag are located next to each other.
Task-3607404
X-original-commit: cac68b35777210c3f96a5bd187b479589716145d
Part-of: odoo/odoo#151736
The `test_complete_chatbot_flow_ui` ensures it is possible to add
reactions to the chat bot messages once the thread is saved on the
server.
This test was sometimes failing because the condition that is used to
wait for the thread to be persisted is incorrect: it checks that a
message with the user response exists but the chat bot question also
contains the response text.
This PR fixes the issue by using the `contains` helper instead: it
will wait until the expected state is reached.
fixes runbot-55291
closesodoo/odoo#151720
Signed-off-by: Didier Debondt (did) <did@odoo.com>
*: test_website
Commit [1] modified the custom page search model so it is adding the
current website in the search domain.
But it was not considering the case of models not having a website_id
field.
The only case was the appoitment.type model.
Steps to reproduce:
- Install website_appointment (enterprise)
- Click on Website > Site > Appointments
- Crash
[1]: https://github.com/odoo/odoo/commit/db670f64f4c2190f1655f9077ea62885049a3c84closesodoo/odoo#151686
X-original-commit: 247a5e157f14ce2cd8fbbe8d191abcb3c2e4ec0d
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Add two missing indexes on pos.order and one on pos.payment. These
speed up queries executed when calling create_from_ui from the
pos interface.
opw-3619270
closesodoo/odoo#151441
X-original-commit: 6f1b5bd530dbb211bb0dbc41b523233dfb57d002
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Aurélien van Delft (avd) <avd@odoo.com>
A fix introduced in
https://github.com/odoo/odoo/pull/146836/commits/5fd63c81b092d07c4c92381a0391dad52d9b76aa
resulted to unpredictable server-syncing behavior when deleting an order from
the ticket screen. The value of sync notification message can be different
between the runs of the `pos_restaurant_sync` tour test. To make the behaviour
predictable, we make sure to await the syncing when sending order for
preparation.
Runbot Error: 56341
closesodoo/odoo#151424
X-original-commit: ce1d631fda4cfb3c60598ed06b4e0b695ab1f8bc
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Steps to reproduce:
- open any task from project in form view
- add timesheet to that task
- switch to mobile view
- under the timesheet section in notebook
Issue:
- there is no space between avatar and employee name
Solution:
- add space between avatar and employee to make user friendly view
closesodoo/odoo#151091
Task: 3633405
X-original-commit: 41d4a93100b809d404e8145e3cf14d1dc3b7c208
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit, when there was an error while compiling scss,
information was added in the compiled css bundle s.t. the client
is aware there was an issue and can indicate it to the end user.
In particular, a dialog was shown with a static message, and
with what should have been the python stack trace. However, the
stack trace was missing.
In addition, a banner should have been displayed in the bottom left
corner the screen, telling that a former version of the bundle was
used as the new one is in error. This banner wasn't displayed
either.
Finaly, forwarporting odoo/odoo#149230 automatically closed the
dialog, as we close all dialogs when executing an action (in this
case the first action when the webclient starts). As a consequence,
the dialog was no longer displayed either.
To sum things up, before this commit, 1) there's no longer a dialog,
even if there were, 2) the dialog doesn't contain the stack trace,
and 3) there's no banner.
To fix 1), we simply display a notification instead. Opening a
dialog for this simply doesn't fit with odoo/odoo#149230, and a
sticky, danger, notification is totally fine for this.
A notification being smaller than a dialog, it says to open the
console to see the stack trace instead of inlining it.
2) has been inadvertendly introduced by [1]: quotes in the error
were doubly escaped (\\"), meaning that they weren't escaped at
all, so the js couldn't properly read the value
And the source of error for 3) was that the last line of the css
bundle (the sourcemap comment line) wasn't valid. It started with
`//*`. As a consequence, the remaining of the file wasn't processed,
and that's exactly where the assets bundle error handling code
inserted the error information.
[1] 64bbef5bc1closesodoo/odoo#149543
Related: odoo/enterprise#55257
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Have a form view in a dialog with an action button (e.g. a stat
button). Click on it. Before this commit, the action was executed
in the background, but the dialog remained open, which could
confuse the user and was definitely weird UX-wise.
With this commit, we automatically close all dialogs when we
execute an action which will update the main action container.
Note that this was working in previous versions thanks to legacy
compatibility code [1], but this code has no impact on the new
(wowl) dialogs, so as of 16.0, it has very limited impact.
Here's a specific scenario to reproduce the issue:
- go to the project task gantt view
- click on a pill
- in the task for view (in dialog), click on the external button of
the project many2one
- in the project form view (in dialog), click on a stat button (e.g.
"At risk")
-> before this commit, the 2 dialogs remained open.
opw 3644904
[1] https://github.com/odoo/odoo/blob/15.0/addons/web/static/src/legacy/action_adapters.js#L42
X-original-commit: 03fa39738c4f81ae30caaaa032c099797ecba9e7
Part-of: odoo/odoo#149543
Co-authored-by: Aaron Bohy (aab) <aab@odoo.com>
**Current behavior:**
Trying to post journal entries for an expense report sheet
contianing an expense that has:
A) an associated analytic distribution with
both a Project and Department, and
B) a customer to be re-invoiced (requires the expense
to be for a product which permits this operation),
attempting to post the journal entries for the approved expense
sheet will raise a ValueError.
---
**Expected behavior:**
The entries get posted to their respective accounting journals.
---
Steps to reproduce:
0. Install the Project, Accounting, Sales, Expense apps
and enable analytic accounting in the db settings
1. Create a new expense with:
A) an analytic distribution which has
both available fields filled out, and
B) a category that permits a customer to be re-invoiced
(then enter a customer)
2. Create the report, submit it to the manager, approve it,
then attempt to post the journal entries
3. This should cause the traceback, if the process was blocked
try again after deleting any tax rules in the expense
---
Cause of the issue:
The analytic_distribution field in the hr.expense module is
stored as a dictionary. During the process of recording the
journal entries, the keys are converted from a string to
integers. However, when multiple keys are in the dict, the
conversion is set up improperly and fails.
---
Fix:
Modify the conversion sequence so that multiple dict keys are
accounted for.
---
opw-3663082
closesodoo/odoo#147985
Signed-off-by: John Laterre (jol) <jol@odoo.com>
There are a lot of places in the codebase where insuficcient access to a
company blocks a normal flow and raises AccessError. While this should
normally never happen with the protections from company domain check,
the new multi company branch/parent relationships suffers the most of
this behavior; because a children company sometimes requires an
information from their parent's field (e.g. currency_id)
The correct behavior to do here is to let the children get the required
data just for processing the flow in the compute (behind the scenes).
Even though the children should normally have no access to read/write it
on screen, the backend process should be able to run smoothly without
blocking any flow.
Granting a few temporary sudo() is necessary to ensure the flow runs as
expected on some places.
closesodoo/odoo#151562
Task-id: 3551305
Related: odoo/enterprise#55345
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Yosua Nicolaus (yoni) <yoni@odoo.com>
Branch company should be able to access both their parent and children's
journal and make transactions in it. However at the same time, a child
branch should not be able to see how much balance is in the parent's
journal because of privacy reasons.
This commit aims to implement this balance visibility behavior by
checking on the company and its relation to the journal's company
Additionally, this commit also adds an improvement where whenever there
are journals from other company (parent/child) in their dashboard, the
journal's company name will be displayed to avoid any confusion.
Task-id: 3551305
Part-of: odoo/odoo#151562
When a user only has access to a branch of a company, they should be able
to access their parent's products, taxes, accounts, and journals
The current behavior however prevents that because of how the domain was
set on those field's view domain by checking the company_id in the view
This commit aims to fix that by removing the company domain limitation.
The fields have already considered the parent company by default via
check_company in python so no further changes are needed.
Additionally, for bank/cash journals, a company should be able to access
both their parent's and their children's journal and make transaction
in it.
Task-id: 3551305
Part-of: odoo/odoo#151562
Steps to reproduce:
-------------------
On the Time Off dashboard, click on a public holiday.
Issue:
------
The duration is 1 Day instead of zero day.
Cause:
------
To ignore the current holiday, the domain for finding holidays adds the condition:
```py
('holiday_id', '!=', self.id)
```
Unfortunately, if we have a `NewId`, in postgresql,
`NULL != NULL` condition always returns NULL.
As a result, public holidays (which do not have a `holiday_id`)
will not be taken into account.
Note:
This does not happen when you save because the id exists.
Solution:
---------
Accept `holiday_id` equal to `False` in the domain.
opw-3635949
closesodoo/odoo#151534
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
This commit adds the missing neutralisation necessary for the `payment_xendit`
module introduced in [1]
The purpose of the standard neutralisation framework is to allow us to
create database copies that will not interract with external systems in
ways that could impact the production database (or if it is not possible
to prevent the interractions, make sure that they are benign or wont
result in actual changes), or impact the customers of the operator of
the production database.
This is mainly useful to allow safe support investigation on database
duplicates.
[1] odoo#141661
closesodoo/odoo#151511
Signed-off-by: Alexandre Moens (mao) <mao@odoo.com>
to reproduce
============
As admin:
- in my Belgian company: create an accrual plan (use default values)
- create an allocation for laurie poiret, use the created accrual + add 2 days of allocation
- as lauriepoiret go to time off
- create a time off for today or in the past
- try to open time off type drop-down -> error
Problem
=======
The problem is that the accrual plan is not readable by the employee, but used in compute method.
Solution
========
use sudo to read the accrual plan
opw-3687866
closesodoo/odoo#150993
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Prior to this commit, fiscal positions auto-detecion was completely override for Argentinian countries.
With this improvements the afip responsibility field can be combined as a filter to choose the proper fiscal position.
Example of a new use case could be:
* Name: Gross Income Perceptions Buenos Aires
* Detect Automatically = True
* Afip Resp. Type = Responsable Inscripto
* Country = Argentina
* Federal states = Buenos Aires
So, this fiscal position will be automatically choosen only for responsables inscriptos of Buenos Aires.
Previous use cases still work.
closesodoo/odoo#150652
X-original-commit: 4c5987eb1ac7687eb0c6467d99fb3052e4843a07
Signed-off-by: Josse Colpaert <jco@odoo.com>
When we update an inline translated element (like `<span>`) for the base
language `en_US` we should update the modifiers attributes for all
languages.
For example when updating from (16.0)
https://github.com/odoo/odoo/blob/7ecd9413/odoo/addons/base/views/ir_ui_view_views.xml#L127-L129https://github.com/odoo/odoo/blob/7ecd9413/odoo/addons/base/i18n/fr.po#L7233-L7235
to (17.0)
https://github.com/odoo/odoo/blob/b1461d28/odoo/addons/base/views/ir_ui_view_views.xml#L126-L128https://github.com/odoo/odoo/blob/b1461d28/odoo/addons/base/i18n/fr.po#L12087-L12089
The base term, `en_US`, is updated since the text matches but the
attributes of the translated terms, `fr_FR` for example, are not
updated. Later when the PO file is loaded in non-overwrite mode the
translated terms for `fr_FR` is not updated. This causes all sort of
issues during an upgrade for inline-translated terms -- like `<span>`.
More so since the recent change that converts domain-based attributes
into inline Python expressions.
In this patch we propagate modifiers attributes from inline-translated
items in the new base term into all translated terms when the base term
is updated. In that way we ensure the attributes are correct in all
languages even if later the loading of their corresponding PO file
doesn't update the term.
For a detailed example, let's see what happens when loading the view
above during an upgrade 16->17, right at the first load of the XML file
at https://github.com/odoo/odoo/blob/b1461d28/odoo/fields.py#L1864
```
(Pdb) p old_term
'<span attrs="{\'invisible\': [(\'reset_mode\', \'!=\', \'soft\')]}">This view has no previous version.</span>\n <span attrs="{\'invisible\': [(\'reset_mode\', \'!=\', \'hard\')]}">This view is not coming from a file.</span>\n <span attrs="{\'invisible\': [(\'reset_mode\', \'!=\', \'other_view\')]}">You need two views to compare.</span>'
(Pdb) p closest_term
'<span invisible="reset_mode != \'soft\'">This view has no previous version.</span>\n <span invisible="reset_mode != \'hard\'">This view is not coming from a file.</span>\n <span invisible="reset_mode != \'other_view\'">You need two views to compare.</span>'
(Pdb) p translation_dictionary[old_term]
defaultdict(<class 'dict'>, {'fr_FR': '<span attrs="{\'invisible\': [(\'reset_mode\', \'!=\', \'soft\')]}">Cette vue n\'a pas de version antérieure.</span>\n <span attrs="{\'invisible\': [(\'reset_mode\', \'!=\', \'hard\')]}">Cette vue ne provient pas d\'un fichier.</span>\n <span attrs="{\'invisible\': [(\'reset_mode\', \'!=\', \'other_view\')]}">Vous avez besoin de deux vues pour comparer.</span>'})
```
As we can see the new term will get an updated value for its `invisible`
attribute, while also removing `attrs`. The translated terms will be
still keep the old modifier though.
Now later when the fr_FR.po file is loaded we reach this point
https://github.com/odoo/odoo/blob/b1461d28/odoo/tools/translate.py#L1442
```
(Pdb) p term_en
'<span invisible="reset_mode != \'soft\'">This view has no previous version.</span>\n <span invisible="reset_mode != \'hard\'">This view is not coming from a file.</span>\n <span invisible="reset_mode != \'other_view\'">You need two views to compare.</span>'
(Pdb) p translation_dictionary[term_en]
defaultdict(<function DeepDefaultDict at 0x7fc9640cdfc0>, {'fr_FR': '<span attrs="{\'invisible\': [(\'reset_mode\', \'!=\', \'soft\')]}">Cette vue n\'a pas de version antérieure.</span>\n <span attrs="{\'invisible\': [(\'reset_mode\', \'!=\', \'hard\')]}">Cette vue ne provient pas d\'un fichier.</span>\n <span attrs="{\'invisible\': [(\'reset_mode\', \'!=\', \'other_view\')]}">Vous avez besoin de deux vues pour comparer.</span>'})
```
Thus the translated values are NOT updated, keeping the _wrong_
modifiers. This is later fixed during the upgrade in a clumsy way.
C.f. the warnings like this one in runbot:
```
Incomplete conversion for view(id=77, lang=fr_FR) at
<span attrs="{'invisible': [('reset_mode', '!=', 'soft')]}">Cette vue n'a pas de version antérieure.</span>
```
Note that such warnings are gone in current PR CI.
The root issue here is that when the fr_FR translation is loaded the
terms are not updated due to a combination of factors:
1. The text content of the term didn't change
2. There is no override flag set for translations
Option 2 is not a valid option during upgrades because we want to keep
custom translations. We could instead of the current patch tweak how
option 1 works and perhaps make the closest term more restricted. This
would lead to the update of the whole translation though while the
actual issue here is _just_ the modifiers. Moreover if the translations
are out of sync the translated terms will still keep the wrong values
that could still be essential for the correct functioning of the record
they belong too (view archs -- for example).
Finally this is a more extreme case (16.0):
https://github.com/odoo/enterprise/blob/1e63b4a8/sale_subscription/views/sale_order_views.xml#L142
In this case during the upgrade we fix the modifier value (refer to
runbot warning above -- it's the same script that fixes it) and set
```
invisible="(subscription_management == 'upsell') or (recurrence_id == False)"
```
for translations, which is wrong. The correct value is (17.0):
```
invisible="not plan_id or subscription_state == '7_upsell'"
```
https://github.com/odoo/enterprise/blob/530ba3ad/sale_subscription/views/sale_order_views.xml#L136closesodoo/odoo#150152
Signed-off-by: Raphael Collet <rco@odoo.com>
`get_text_content` will transform contiguous space chars into single
spaces, plus translate special HTML elements
```
>>> " ".join(html.fromstring(f"a\n b & c").text_content().split())
'a b & c'
```
In order the correctly verify if a term is text-only we need to use the
HTML parser. Note that to be resilient against bad XML, but valid HTML,
we cannot use the default XML parser.
Part-of: odoo/odoo#150152
**Current behavior:**
Creating an additional company then creating an attendance
kiosk link for it will not display this company's logo.
---
**Expected behavior:**
The kiosk page displays the logo for whichever company is
actively selected when the link is generated
---
**Steps to reproduce:**
1. Create a second company, set the logo to anything besides
the default/fallback image
2. In the HR Attendance application settings, generate a kiosk
link then paste & go in an incognito window
3. Observe the logo image displayed above the bar code is the
default/fallback image
---
**Cause of the issue:**
The route being used to get the company's logo does not work
for companies which are not the first/default one generated
with the database. An accessibility check fails due to some
information about the user's access rights not being available
with the request.
---
**Fix:**
Use an alternative route which can properly access the logo
image file of the company that is active when the kiosk link is
generated.
---
opw-3672577
closesodoo/odoo#150628
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Currently the "Invoices to validate" link is broken in case the module
account_3way_match (from enterprise) is installed.
The same link / context is used for "Invoices to validate"
and "Bills to validate". (The text inside the link is just changed
depending on the journal type.)
The module account_3way_match changes the context of that link to
change the behaviour for the "Bills to validate" (bill specific filter).
This breaks the link for "Invoices to validate".
This commit makes invoices and bills have dedicated / separate links.
Thus after this commit account_3way_match only changes the behaviour of the "Bills to
validate" link.
task-3680398
closesodoo/odoo#149352
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Step to reproduce:
- Open a pos session
- Turn off the connection between the server and your POS instance
- Create an order offline
- Turn back on the connection between the server and your POS instance
- Close the POS session
Issue:
The order created offline is not synced to the server
Cause:
The sync of the order has been implemented for the button to go back to
the backend without closing but not for the closing session button.
Solution:
Make the synch mechanism common to both buttons.
closesodoo/odoo#151016
X-original-commit: 4d57ce4c740d6a3350318b4dbcd49c9f2f0f104c
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Before this commit:
- On table when we hit tab it displays toolbar as it sets selection between
startPosition and endPosition.
- On hitting tab it selects the text in the next cell completely, which
should not happen.
After this commit:
- Now toolbar is not displayed on hitting tab.
- selectionis made to collapse at the end the lastNode of the cell.
task-3475079
closesodoo/odoo#151653
X-original-commit: 9361133a24146528846cd2d69119c3e9045eafba
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Before this commit
==================
It was not allowed to cancel the invoice, an error message
was displayed, response as False was returned as it was always moving inside
else condition
After this commit
=================
After changes the error message has been removed and response
as True is returned, and allowed to cancel the invoice
task-3258582
closesodoo/odoo#151652
X-original-commit: 5a8826ec970dd87b203fdbc2214ac8381393ae2b
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Surabhi Varma (suva) <suva@odoo.com>
Without this patch, running this command on an environment where the tour will fail, will create massive and useless logs:
odoo --stop-after-init -i auth_totp --test-enable --test-tags /auth_totp
This is because this method is a callback that can come in a different thread, creating a race condition.
There's no problem on checking wether the directory exists before creating the file, and then safeguarding from the problem.
@moduon MT-1075
closesodoo/odoo#151579
X-original-commit: 7aca8ae8728c66700c3afdca350e99ea78a63d88
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This commit was written for Odoo 16.4 and then backported.
In Odoo 16, only point 2. described just below is not working.
The 16.4 commit was thus retarget to Odoo 16 as it was also fixing the
second point.
------------------
Before this commit:
The website selected in the website selector of the search view in the
website.page list/kanban view was always set to the first one found in
the DB and was never:
1. the one you visited in the website preview
2. or the one matching the URL of your backend.
But 1. was working fine before commit [1] from the frameworkjs which
introduced a way to "reset" the screen between apps/menu switch.
Despite 1. working before commit [1], it was not ideally coded and
worked "by chance", see below for a few facts and explication.
------------------
Fact 1:
When you have multiple websites and you are on a website, the website
served is the result of 2 possibilities:
1. All websites have a specific domain, then you can only see a given
website on its own domain. Attempting to select another website in
the website switcher will redirect you to that other website domain.
2. You have one or more websites without any domain, then you can see
those ones from any domain by using the website switcher. It will
force the website in session, and despite being on a domain which
should serve a given website (the one which has its domain set that
domain if there is one), it will serve you the one you selected in
the website switcher.
Fact 2:
- It is the `website_preview` which is setting the currentWebsite
property of the `website_service`.
- But the `website_service` can be used on its own, without any
`website_preview` being involved in the process.
- When the website preview is unmounted, the currentWebsite from the
website service is reset to null.
- The website page list component is reading the currentWebsite from the
website service.
- When switching from the website preview to another menu like the
website pages list, the page list component (PageControllerMixin) is
actually initialized/created before the website preview is unmounted.
In the end, the following happen:
1. Go to website preview -> it sets the website service current
website
2. Go to website page list
3. The website page list component reads the current website from the
website service which is set
4. The website preview is unmounted, emptying the current website from
the website service
5. The website page list is shown to the user
6. Any call from the page list component to the current website will
now be "wrong" / not return the same as during its `onWillStart`,
as website preview was unmounted just after that, emptying the
website set in the website service. Luckily, there is none.
Fact 3:
Commit [1] changed the order of the steps listed above, now 4 occurs
before 3, so when the page list component reads the website from the
website service, the unmount of the website preview already kicked in,
emptying that website service website.
This is the source of the bug fixed here: the current website could
never be found anymore.
-----------------
This commit is simply finding the current website_id by asking it to the
server.
It will fix point 1. listed at the very beginning of the commit message,
but will also make point 2. work.
Another solution would have been to find a workaround to the frameworkjs
change (like investigating the `noEmptyTransition` option) to restore
what we had before, but it would have been as "fragile" as before and
wouldn't have fixed other flows as the current fix does.
----------------
Steps to reproduce 1:
- Without any domain set, go to your DB in the website preview of your
website in the backend
- Switch to the website 2 in the navbar website switcher
- You are now viewing website 2 in the website preview
- Click on "Pages" in the "Site" menu to go to the page list view
- The website selected in the search view is the first one, not the
website 2. Also, the page shown are from the website 1, not the
website 2.
- This was working before commit [1] and this commit is fixing that.
But this commit is also fixing/improving flows which never worked:
- Before commit [1] (or in Odoo 16 to be simpler), do the same 4 first
steps as above.
- You will see that the listed pages are the ones from website 2 and
that the selected website is the second one, correct.
- Now just reload the page, it will show website 1, despite the website
2 being forced (if you did reload the page on the preview, it would
still show website 2).
- This is because the website_preview was never involved after the
reload since you reached the list view / website service without going
through the website preview.
- The same can be seen if you go to the Pages list view directly through
CTRL+K, in which case you won't go through the preview.
--------------------
Note that the chance is taken to reorder the wutils export, it was
becoming a real mess and it was not possible to easily read through the
method names to find/guess something.
------------------
[1]: https://github.com/odoo/odoo/commit/9f6ed9f6d1ef7ec1870980498480cae0ffc729d8
Related to task-3676124
opw-3658648
closesodoo/odoo#151269
X-original-commit: 0128beed551395b30f957a5edc1a23a6f3d0ba31
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
In iot, when we send a request to
the route '/hw_posbox_homepage/password' we pass a variable which is unused.
And which therefore causes a warning in the iot logs.
This commit removes the query parameter.
closesodoo/odoo#151604
X-original-commit: f713d48f6393e58cf9c4b5fe08e1407ea2be8513
Signed-off-by: Yaroslav Soroko (yaso) <yaso@odoo.com>
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
`getLoggedInAsText` is a function, due to missing brackets
the function content was dumped instead of evaluation of function.
opw-3701333
closesodoo/odoo#151600
X-original-commit: 4ce21a4207a9dd7047a6b5ec9c447f9e48ca199c
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
The `see records` action that drill downs to the specific AccountMoveLines
that match the formula domain would break if we left some optional
formula arguments empty (specifically concerns the offset and companyId
arguments). This revision ensures that we use their default value when the
arguments are not provided.
closesodoo/odoo#151423
Task: 3621110
X-original-commit: 23bbb0cdebc9028fcc93e006e755c43000428fcb
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Steps to reproduce the problem:
- Add a "Countdown" snippet on the website.
- Save.
- Enter in edit mode again.
-> Problem: the `destroy()` of the `CountdownWidget` public widget comes
from a `widgets_start_request` that is triggered when the
`WysiwygAdapterComponent` has been mounted and patched (see
[useEffect documentation]). The problem is that, as the widgets are only
destroyed at this moment, it is possible that a widget could replace an
element that has been modified during the instantiation of the
`WysiwygAdapterComponent`. For example:
- At the `onWillStart()` hook of the `WysiwygAdapterComponent`, the
`o_editable` is added on some elements.
- A widget could then replace one of these elements.
- The widget is destroyed after the rendering of the
`WysiwygAdapterComponent`.
-> The `o_editable` class is not on the element anymore.
The goal of this commit is to, as before [1], destroy the existing
widgets before instantiating the `wysiwyg`.
This commit also adds a test to ensure that the order of the calls to
the widgets and wysiwyg lifecycle methods is coherent.
Related to runbot-28700
[1]: https://github.com/odoo/odoo/commit/a3e34512bf229d5d55f9e9d9eb0a9f7211a5a826
[useEffect documentation]: https://github.com/odoo/owl/blob/master/doc/reference/hooks.md#useeffectclosesodoo/odoo#151411
X-original-commit: 723c0dfeb7d39ca2522e65cf021664aacfc7099c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Fix 1:
Before this commit, the smart button on the employee would
display `x/y` Time Off, indicating remaining leaves over max leaves.
However, while `y` was correctly taking into account current
allocations only, `x` didn't, resulting in incoherent values.
Reproduce the issue:
- For an employee, create an expired allocation and validate it of x days;
- Create an additional allocation which is still valid today of y days
and validate it as well;
- Go on the employee form view;
- Time Off smart button display (x+y)/y instead of y/y
Fix 2:
Before this commit, there was no way to track error inducing leaves
that were created through a bug or that were already created in the
database prior to the changes brought in version 17.0.
This commit adds a new property in the leave data indicating the id
and the start date of the leave that is causing the discrepancies
in the database and displays a warning on the dashboard if
there are some error inducing leaves.
closesodoo/odoo#151288
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Since the refactoring of base_automation, the 'website-publishing'
option of server actions was broken; it did get included in the view
but outside of a group node and without labels. The result was a
floating checkbox which would trigger a label-less char field upon
selection - not the clearest of UIs.
This commit properly insert these fields into a group node. Note that
since server actions can normally only be reached by going through
technical menus, the fact that this section of view is now in a
group_no_one-only section should not change anything functionally.
closesodoo/odoo#151498
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Prior to this commit, when adding a product to an order, navigating
back to the floor screen, and subsequently reopening the table,
clicking on "Order" would send the order to the preparation display
again. The issue stemmed from the fact that "this" was being added to
"ordersToUpdateSet" in posStore, whereas "order" should be added to
that set.
opw-3687977
closesodoo/odoo#150973
X-original-commit: 633179542d8cd7e32c51f4d6bd9c25decb2e56ae
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Before this commit, the date was being considered in UTC instead of the time zone of the current user. This is problematic in LATAM, where the time zone is negative.
closesodoo/odoo#150956
X-original-commit: 95acd53827ed128b301800dbabd5a8d9d7cbd12c
Signed-off-by: John Laterre (jol) <jol@odoo.com>
When creating a picking on mobile, the moves are displayed as kanban
boxes. But before this commit, only the mvoe's `quantity` is displayed,
that means when in draft, the quantity is usually at 0 and it's the
demand (`product_uom_qty`) who is relevant.
To fix that, display both fields.
Also, we display the UoM aswell if the UoM is enabled.
closesodoo/odoo#144282
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
The `stock.move` form view used for the detailed operation is also used
when using Odoo on a mobile device and is not usable in such case (for
example, the `product_id` is readonly.)
To fix this issue, the view is modified this way:
- The `product_id` is readonly only if the move has a id or already a
move line (that way, the field is editable when creating a new move
but is still readonly otherwise);
- The `move_line_ids` is readonly until the move's product is set;
- The demand qty. and the UoM are editable if the move is draft.
Also, some similar mofifications are done to the `stock.move.line` form
view too.
OPW-3577844
Part-of: odoo/odoo#144282
Before this commit, it was not possible to create a new picking on
mobile if this picking has multiple moves.
How to reproduce:
- Open Odoo on mobile (or on desktop but simulate mobile device with
devtools);
- Inventory > Operations > Transfers;
- Create a new transfer (a receipt for example);
- In its operations (moves), add a new product, then add a second
product.
- Try to save or validate the picking -> A warning prevent to do it,
saying you're trying to write on the field `product_qty` instead of
the field `product_uom_qty`.
What's happening:
For a unknown reason, the fields from the `stock.move` list view are
saved once a second move is created, even if we're using the kanban view
in the mobile version.
To avoid this issue, we force the `force_save` to be false for the field
`product_qty` in the kanban view. That's way, it prevents the issue.
OPW-3577844
X-original-commit: 818e7fcfd88fa9fe2927e327f4510b108a47c370
Part-of: odoo/odoo#144282
The tax with xmlid vat_0_import was missing its repartition
lines which caused validation errors.
This PR adds empty repartition lines to fix this problem.
closesodoo/odoo#151525
X-original-commit: 6ff955e1d7891d4848dc967b66d9d10310adf930
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
When flagging a post, moderators should see the flagged moderation queue
counter appear/increment.
We renamed the span in 21531bd9 and forgot to update this reference.
Task-3349373
closesodoo/odoo#151512
X-original-commit: 720d7b53e7d1a0944415a6c668f4eb3ba527dac8
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Florian Charlier (flch) <flch@odoo.com>
Claire Bretton (clbr)