Install auth_oauth and via the /web/login, click the "Log in using
Odoo.com" button. You are redirected on odoo.com which ask you for your
odoo.com login and password. When the login form on odoo.com is
submited, you are redirected back on your local database.
The problem is that, in case a new account was created on-the-fly, then
the login fails with a cryptic error. The actual error is that
`request.env.user._is_internal` fails because `user` is an empty
recordset where it should had been the just-authenticated user.
The problem is an inconsistent transaction state between the cursor of
the request, the cursor used with `auth_oauth` (which created a new
user) and the cursor used with `authenticate` (which authenticated the
new user). Yes, there are 3 cursors. The newly created user just isn't
present in the transaction of the request's cursor.
Here is the lifetime of the 3 cursors:
* request.env.cr, it begins when the http request enters Odoo, it is
commited when a http response exits Odoo.
* /auth_oauth/signin, it begins roughly at the beginning of the
controller, it is commited once after the user is created (so before
the authenticate transaction begins but AFTER the request transaction
begun), it is commited again when the controller exits.
* authenticate, begins when authenticate is called, is commited when it
returns.
Because the request transaction started before, it cannot access user
created by /auth_oauth/signin.
Because the route is `auth='none'`, if system administrators append the
`auth_oauth` module via `--load` (cli) or `server_wide_modules` (odoorc)
then the controller can be accessed without database. This is the reason
for the explicit registry/cursor/environment inside this controller, we
needed to make sure we are connected to a database, we cannot rely on
request.
The new approach used in this work is to benefit from `ensure_db()`, the
function that is used by various web `auth='none'` controllers such as
/web and /web/login. It makes sure that the database we want to connect
to is already present on the request, otherwise it repeats the request
but this time connecting it to the database. Using this approach we can
have a `auth='none'` controller whose request.env is guaranteed to be
connected on the right database. We can avoid to create explicit new
registry/cursor/environment within the controller and just use request's
ones.
Because the /auth_oauth/signin controller now simply use the request
transaction, the above point:
> Because the request transaction started before, it cannot access user
> created by /auth_oauth/signin.
just doesn't stand anymore as the user is created within the same
transaction. The extra `cr.commit()` must still be present for
`authenticate` to see the newly created user.
opw-3421701
closesodoo/odoo#138051
X-original-commit: e165568f9795af213c8467a7f17948ed781b0799
Signed-off-by: Olivier Dony (odo) <odo@odoo.com>
Co-authored-by: Julien Castiaux <juc@odoo.com>
This commit removes the organizer's name in the mail template when booking
an appointment scheduled based on resources.
Task-3458881
closesodoo/odoo#138043
X-original-commit: ca08d996c2ca0f6de6eeddc44609b96f844d8d25
Related: odoo/enterprise#48625
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
This traceback arises when the user changes the 'end_date' without the employee
value, while creating a new 'Work Entry'.
To reproduce this issue:
1) Install 'hr_work_entry_contract'
2) Open 'payroll' and create a new 'Work Entry'
3) Select 'Work Entry Type' as 'Unpaid' and change the 'To' date
Error:- 'KeyError: False'
On the '_get_duration_batch' method, when the user is not given employee value,
there will be no 'contract_id' as it is getting value from 'employee_id'.
It leads to the above traceback as 'result[work_entry.id]' is getting value
through 'employee.id'.
See:- https://github.com/odoo/odoo/blob/a277faa2ffab7559fcbad95fcc1e8fd6a26d756b/addons/hr_work_entry_contract/models/hr_work_entry.py#L110-L112
Will resolve this issue by calculating duration without employee
sentry-4514970596
closesodoo/odoo#138033
X-original-commit: cc3898ad109e9dfdb220a7245936693197ed79b1
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
This SIRET is valid according to `stdnum` but does not correspond to any
existing company.
closesodoo/odoo#138008
X-original-commit: 283e12353008812787711a664c3bc700b6f8982d
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
Issue:
Reading on the field `tasks_ids` of the `sale.order` model in some
context can be slow, leading to really slow creation and duplication
of tasks on a medium sized database.
Analysis:
After creation of a task, when the ORM flushes the model, it
recomputes all the inverse dependencies that needs to be recomputed.
Currently `task_ids` doesn't implement a `search` routine on the
field, so `task_ids` needs to be recomputed for *all* sales orders,
since we don't know which sales order needs computation. So for
*all* sales orders, we trigger the compute `_compute_tasks_ids`,
which is badly implemented using the general performance anti-pattern
```py
for record in records:
field = self.env['model'].search(domain)
```
which makes 1 query per record that we are computing.
Solution:
Correct the implementation of `_compute_tasks_ids`, which now uses a
`_read_group` instead so we do 1 query for the whole recordset.
And implement the `search` on the non-stored `tasks_ids` field,
which speeds up the context of re-computations. This allows the ORM
to know for which sales order the field `task_ids` needs re-computation.
Results:
In the context a mid-size database (less than 10k records for the
concerned models)
Task creation/duplication:
| | Before | After |
|-------------|--------|-------|
| Time | 1 min | 1 sec |
| Query count | 40k | 300 |
Reference:
opw-3445565
closesodoo/odoo#138007
X-original-commit: 81ae499ce975a96c12b6e379581ba40167d025db
Related: odoo/enterprise#48610
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
This commit removes the module sortable from jQueryUI and adds instead a
sortable service to use the sortable code already used by the backend.
The service can be called using `this.call("sortable", ...)` and the
sortable listeners are added when the `enable` function is called.
This function (`enable()`) returns an object that contains the `cleanup`
function (`cleanup()`).
```javascript
// start / setup
const sortable = this.call(
"sortable",
"create",
{
ref: { el: document.querySelector(".list") },
elements: ".items",
handle: ".drag-icon",
},
);
// on attach callback / on mounted
const sortableInstance = sortable.enable();
// on destroy / on willUnmount
sortableInstance.cleanup();
```
Also, it adds some new property to the useSortable:
* clone: the placeholder is a clone of the drag element
* placeholderClasses: classes added to the placeholder element
* applyChangeOnDrop: on drop the change is applied to the DOM
* followingElementClasses: classes added to the element following mouse
task-3439226
closesodoo/odoo#137527
Related: odoo/enterprise#48371
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
This commit removes Owl hooks from the sortable hook builder file and
introduces a new parameter attribute (`setupHooks`) to specify which
functions must be used to set up, update and tear down the draggable
hook.
This has been done to allow using the hook function in environments
where Owl is not available.
Part-of: odoo/odoo#137527
This commit removes Owl hooks from the draggable hook builder file and
introduces a new parameter attribute (`setupHooks`) to specify which
functions must be used to set up, update and tear down the draggable
hook.
This has been done to allow the draggable hook builder function to be
used in environments where Owl is not available.
Part-of: odoo/odoo#137527
This commit aims to simplify the evaluation context used to
evaluate expressions used in views (invisible, required, readonly,
domain and context attributes). For now, the evaluation context is
typically the current record (there's a key for each field in the
view). In addition to that, there're static keys (that may conflict
with field names): uid, allowed_company_ids, current_company_id,
active_id, active_ids and active_model.
The motivation of this commit is at some point to get rid of the
3 active_* keys, because they are misleading and basically useless.
The notion of active_* exists, but it is something else: when you
are in a form view (let's say the form of a partner) and you open
its opportunities (by clicking on the stat button), the list view
of opportunies shows up and in the context, there're 3 keys
active_*, referring to the record from which we came. One can
easily access those information with context.get("active_*"), in
python or in view archs.
However, almost all `active_id` found in archs were actually used
to refer to the id of the current record. Indeed, for now, in the
evaluation context of a record, the value of the `active_id` key is
always the id of the record. So this commit adapts them to
directly use `id` instead. There was no use of active_ids, and
a single use of active_model which was removed (active_model is
the res_model of the view, so it isn't really necessary).
This commit doesn't drop the support of those keys, it deprecates
them. They will be removed for v18. A warning will be displayed if
they are used.
closesodoo/odoo#136665
Related: odoo/enterprise#47917
Signed-off-by: Raphael Collet <rco@odoo.com>
Previously, when users selected the month or quarter filter and saved
it, the filter would only return data from the current year. This issue
has been fixed in this commit.
Merge the month and quarter data filters into a single month/quarter
filter. This will allow users to select a year which behave as year filter.
If a user only selects a month or quarter, the filter will work accordingly.
The year filter will be removed, as the month/quarter filter can now
be used to filter data by year.
In addition, a checkbox will be added to the relation filter that will
allow users to automatically select the current user. This checkbox
will only be displayed if the model is res.users.
closesodoo/odoo#126935
Task: 3370627
Related: odoo/enterprise#43426
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Lucas Lefèvre <lul@odoo.com>
Before this PR, it was not possible to edit a message that has an empty body.
Task-3387170
closesodoo/odoo#137996
Signed-off-by: Didier Debondt (did) <did@odoo.com>
Set `include_base_amount` to True for the IEPS taxes.
task-3100679
closesodoo/odoo#137940
X-original-commit: ceacccdc34f80ed5969b1d49bbcdf9adbd2ce76c
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
To avoid having to many IEPS taxes, set the sales one as inactive.
task-3100679
X-original-commit: d134258f18c8569f1684e7681cfc905d974444f5
Part-of: odoo/odoo#137940
The aim of this commit is to allow having several taxes with the same
name if those taxes are from different countries.
Context:
With the new taxonomy, it was much more likely for 2 taxes to have the
same name and that was the case for several taxes.
Before this commit:
It was impossible to instantiate some foreign tax because of the unicity
on tax name constrains.
After this commit:
- Foreign tax with same name than national tax can be created again
- UX is improved by appending the country code to the tax name for
display purpose.
closesodoo/odoo#137921
Task-id: None
X-original-commit: 502ec287590b95fdae581cc048ca25eb6699e16d
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
The traceback arises when the user removes the 'product' from 'stock.move'
and try to add the product in 'mrp.production'.
To reproduce this issue:
1) Install 'MRP'
2) Create a new record for 'Manufacturing Order'
3) First add a line in 'Components'
4) Remove the 'product_id' from component
5) Now try to add 'Product' in mrp
Error:-"AssertionError: precision_rounding must be positive, got 0.0"
on the '_compute_state' method when the state is in 'draft' and
the user added a line in 'move_raw_ids'.
In this case, precision_rounding is getting value from
'product_uom.rounding' or 'product_id.uom_id.rounding' through 'move_raw_ids'.
See:- https://github.com/odoo/odoo/blob/10e0ac377cc235d81819eaa2a4ec2b6a60fffd70/addons/mrp/models/mrp_production.py#L478-#L479
When the user removed 'product_id' from 'move_raw_ids', 'precision_rounding'
will be '0.00'. Which leads to the above traceback.
Applying this commit will resolve the issue by giving a default value of '0.01',
when the 'precision_rounding' value is '0.00'.
sentry-4220927307
closesodoo/odoo#137904
X-original-commit: 5c238bbb18c682ff2d25f740aad604feb7bb5bbc
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Signed-off-by: Altaf Shaik (alsh) <alsh@odoo.com>
Before this PR, archived partner where displayed in the recipient list, but they
will never get notified.
This PR exclude archived partner from the recipient list.
task-3535433
closesodoo/odoo#137759
X-original-commit: a2474635c31d47e480f7a871aa869667f0a90dc5
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Didier Debondt (did) <did@odoo.com>
The word “immatriculation” doesn't exist in English.
This commit replaces its occurrences with “registration”.
closesodoo/odoo#137755
X-original-commit: 740979ef152f5cc89682004f9453a03e565bf6ec
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
**Steps to reproduce:**
- Create a fiscal position that maps to a different tax.
- Use that fiscal position as alternative fiscal position for the "Eat in / Take
away" setting.
- Create a "Take Away" order from the self-ordering app (kiosk or mobile).
- ISSUE: Send the order to the database (by "Pay at Cashier" or "Pay").
- Check the order and it doesn't have correct fiscal position resulting to
wrong amounts in the lines.
**FIX:** When creating the order, we make sure the correct fiscal position is
set. Also, we precompute `is_take_away` variable which is used in many places of
processing the order.
closesodoo/odoo#137669
Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>
This commit fix the reference to an incorrect state of the pos order. It
should be "cancel" not "cancelled".
closesodoo/odoo#137620
X-original-commit: 0182fe024f01f2ef320ae4a290cd1a823f5353c0
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Loukas Wets (lowe) <lowe@odoo.com>
1. Rename checkbox "Peppol BIS Billing 3.0" to "BIS Billing 3.0" to avoid confusion
with the incoming one we will add with the full support of Peppol.
2. There was a buggy interaction between mail checkbox and BIS Billing checkbox in the Send & Print:
If the Peppol BIS Billing was checked, then uncheck/check the Email box, the Peppol BIS Billing
unchecks automatically. They should be independent.
Task-id:3525932
closesodoo/odoo#137382
Related: odoo/enterprise#48318
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
1. Add the "Download" option back into the Send & Print in list view
2. If the "Download" option is ticked, the Send & Print is run synchronously.
3. "Download" returns a zip containing all documents that are generated (or previously generated)
4. Remove completely "Download Electronic Invoice"
5. When downloading a single invoice that has multiple attachments (pdf, xml, ...)
we now download a zip with all files instead of only the pdf.
Task-id: 3525932
Part-of: odoo/odoo#137382
Before this PR the showFavorite status was not properly updated after clicking
on "back".
This cause the categories to use the favorite route when scrolling instead of
the category route.
Task-3504566
closesodoo/odoo#136932
Signed-off-by: Didier Debondt (did) <did@odoo.com>
- Applies a domain filter to limit payment methods to those of the
running company in multi-company settings.
- Some wording adjustments for better clarity.
- UI tweak: Directly open the expense detail view when only one expense
is linked to an expense report, bypassing list view for better usability
Task-3500674
closesodoo/odoo#136503
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit:
-Banner on drag and drop only drops content.
-Content inside banner were draggable.
After this commit:
-Now we can drop banner as well.
-Prevented content inside banner to be draggable.
task-3512199
closesodoo/odoo#136003
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit when we confirm SO then create project button appears
In this commit we have made that if product is based on timesheets or
based on milestones then only create project button will appear when we confirm SO
task-3468706
closesodoo/odoo#133410
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Purpose
-------
Currently, views with a contextual filter/domain are not well managed: e.g.
Today Activities
=> domain=[('my_activity_date_deadline', '=', context_today().strftime('%Y-%m-%d'))]
My pipeline
=> domain=[('user_id', '=', uid)]
Currently, 'context_today().strftime('%Y-%m-%d')' or 'uid' would be replaced by
their values when the view is inserted into a spreadsheet.
If the view is inserted on the 1st June 2023, the date "01/06/2023" is
hard-coded in the spreadsheet.
Specification
-------------
Preserve the domain dynamic parts when inserted into a spreadsheet.
Implementation note: I force the readable format at export just to be sure it
exported that way, no matter the domain origin.
closesodoo/odoo#131874
Task: 3414027
Related: odoo/enterprise#45748
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Currently, when a customer is located outside of Saudi and a 0% tax is set in the invoice lines, we do not include any TaxExemptionReason or TaxExemptionReasonCode in the UBL file, even though it is required by ZATCA through rule BT-121. This commit aims to fix that. Now, as long as the Supplier (Company) is located in Saudi, we include both TaxExemptionReasonCode and TaxExemptionReason if the tax amount is set to 0%
closesodoo/odoo#137944
X-original-commit: 6711ad24f82a16fbe23a6fb6fed7bd93f682e816
Signed-off-by: Josse Colpaert <jco@odoo.com>
Before this commit:
In mass mailing, Selecting image and click on replace media you get picture
middle of the screen.
After this commit:
Now, clicking on replace would open media dialog and replace picture.
task-3506590
closesodoo/odoo#137920
X-original-commit: 7e0b8af005e818c9283b332fb140aeaeaf028275
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Purpose is notably to regroup some tests into a single file (notably tours
in their matching unit tests file), rename some tests / tours, ... and
globally try to lessen test file split.
Reorganize tests, perform some renaming. Tests stay as they are to ease
comparison through versions. We notably extract formatting related tests
into their own class, allowing to keep their setup only for those tests.
Task-3535845 (TestMail: Reorder tests tours / files)
Prepares Task-3527752 (Mail: The Pre-Major Freeze FixImpLint)
closesodoo/odoo#137895
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Reorganize tests, perform some renaming. Tests stay as they are to ease
comparison through versions. We notably extract formatting related tests
into their own class, allowing to keep their setup only for those tests.
Task-3535845 (TestMail: Reorder tests tours / files)
Prepares Task-3527752 (Mail: The Pre-Major Freeze FixImpLint)
Part-of: odoo/odoo#137895
Purpose is notably to regroup some tests into a single file (notably tours
in their matching unit tests file), rename some tests / tours, ... and
globally try to lessen test file split.
Task-3535845 (TestMail: Reorder tests tours / files)
Prepares Task-3527752 (Mail: The Pre-Major Freeze FixImpLint)
Part-of: odoo/odoo#137895
Behavior before this commit:
When you try to apply for a job on focusout of the mail field, you get
an error raised in website stating that this._rpc is not a function.
Explanation:
The task 3446696 (PR: 131308) has been merged in master
at almost the same time as the task 3439226 (PR: 136271)
that was removing the legacy rpc call (this._rpc({...})).
Behavior after this commit:
The rpc call is working again and so no error is raised.
Fix:
This commit fix it by using the current
rpc call.
closesodoo/odoo#137822
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
When an event is created by user A and user B is invited, user A automatically
accepts the event. If both users are using google sync and user B accepts the
invitation from the google interface, the status of the events are set to
needAction for user A. This occurs because the odoo values will always write
the time related fields, even when those did not change. This causes the
status to be changed to needAction because we assume the time of the event has
changed and user A needs to verify it. This commit fixes this by only setting
time values when they were really changed and by switching the logic that
triggers the reset of the status. As most times a default alarm is generated
by google, we should not treat it as condition for updating the time and,
therefore, potentially updating the status of the attendee.
task-3464054
closesodoo/odoo#137471
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Signed-off-by: Leonardo Pavan Rocha <lpr@odoo.com>
Issue:
------
When we modify an employee's calendar, employee's timesheets
are not updated according to public holidays of the new calendar.
Solution:
---------
When we notice that we are modifying the `resource_calendar_id` field,
we delete all the future timesheets which are based on the public holidays
and then recreate them with the new calendar.
opw-3501170
closesodoo/odoo#137910
X-original-commit: c2754727eee8373fe99011658ae0b33dc692d25d
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
This commit introduces two new components, MultiRecordSelector and
RecordSelector, which are used to select multiple records and a single
record respectively.
The MultiRecordSelector component is used to display the selected
records with a tag-like style. It also allows to add new records by
typing/selecting a valut in the input field.
The RecordSelector component is used to display the selected record and
allows to select a new record by typing/selecting a value in the input
field.
These components are created from the DomainSelectorAutocomplete and
DomainSelectorSingleAutocomplete components, which are now an extension
of the MultiRecordSelector and RecordSelector components respectively.
This commit also add tests for these two components.
Part of task-id 3433922
closesodoo/odoo#137650
Related: odoo/enterprise#48423
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit adds support for domain and context in DomainSelectorAutocomplete.
This is a step towards the simplification of the Record component.
We would like to remove the case where the Record component is used with
fake resModel/resId only to display a Many2ManyTags or a Many2One.
Instead, we could simply use the DomainSelectorAutocomplete or
DomainSelectorSingleAutocomplete to achieve the same result.
Part of task-id 3433922
Part-of: odoo/odoo#137650
Prior to this commit, the pseudo-element in the employee resume tab was
not aligned on every media-query, making it invisible on large devices.
This commits ensure the visibility of the element no matter what device
you are using.
Task-3474635
Part of task-3326263
closesodoo/odoo#137928
X-original-commit: 036e6cdf1deb383c24967618f04070f97dd872e7
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Signed-off-by: Chrysanthe Gomrée (chgo) <chgo@odoo.com>
Currently, an error occurs when the user follows the below steps and tries to
run cron "Maintenance: generate preventive maintenance requests"
Steps:
- Open maintenance > Configuration > Maintenence Teams
- Create new team e.g. "ABC"
- Go to Equipments and create new equipemnt
- Set 1 "Preventive Maintenance Frequency" from maintenance page
- Select "ABC" in Maintenance Team >> save it
- Delete Maintenence Team "ABC"
This commit solves the above issue by restricting the deletion
of maintenance teams who are related to equipment.
sentry-4467657509
closesodoo/odoo#137943
X-original-commit: 9e4aa20c05999ccd9952480b8fea22b9fb651d74
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Signed-off-by: ANSARI MAHAMADASIF (maan) <maan@odoo.com>
*: auth_totp_portal, event, portal_rating, web, web_tour, website_blog,
website_event, website_event_booth, website_event_sale,
website_event_track, website_event_track_quiz, website_payment,
website_sale, website_sale_comparison, website_slides,
website_twitter
This commit allows to have responsive font sizes on all the Odoo
frontend. It is based on the Bootstrap mixin `font-size` which
calculates the font size based on the viewport width.
task-1958098
closesodoo/odoo#129469
Related: odoo/design-themes#673
Related: odoo/enterprise#44578
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
As `download`, the `downloadFile` util is able to perform an `XMLHttpRequest`
(`GET`) if it is provided with only an url. Change the return value of
`downloadFile` in that case to a `Promise`, to match the behavior of `download`.
Previously, the `XMLHttpRequest` was returned to allow the caller to modify the
headers of the request, but that feature was not used.
Extract the configuration of the `XMLHttpRequest` for `download` to a separate
function so it can be used for both `download` and `downloadFile`. It will set
the `responseType, onload, onerror` properties.
Tracking:
- usage of `downloadFile` in Knowledge introduced in [1].
[1]: https://github.com/odoo/enterprise/pull/47056
task-3517796
closesodoo/odoo#137893
X-original-commit: 787f207f9882807598273c34296d0c1d8081f1b5
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Damien Abeloos (abd) <abd@odoo.com>
