This allows to define categories as also models, which allow
to register list of threads as relational fields, which in turn
simplify code readability and maintainability of these relational
data.
Part-of: odoo/odoo#136308
These `update()` functions are specific to a discuss record,
so it's best to be defined in the model rather than another
service.
Part-of: odoo/odoo#136308
This commit removes the files ajax.js and rpc.js then adapts all the
places where their exports were used. For most of the changes, it's a
replace of `this._rpc({...})` by a new `useService("rpc|orm")` like
pattern in the widgets.
closesodoo/odoo#136271
Task: 3439226
Related: odoo/enterprise#47775
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Reproduce:
1. Open "Sales" app.
2. Open the fist step about company data
3. Hit "Save"
4. The step should have been marked as complete
onboarding: Since the relational model refactoring,
saving a record that is not changed will not result in
calling the onRecordSaved callback, while saved will be `true`
in `saveButtonClicked`.
web: Be more explicit about this fact in the onRecordSaved doc.
Task-3516270
closesodoo/odoo#136143
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Opening the stock move form view in a picking will display the
technical name of `move_ids_without_package`. This commit change it to
be more accurate.
closesodoo/odoo#136067
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
The field `move_line_nosuggest_ids` was missing on the stock move form
view. Depending on the `show_reserved` setting on the picking type, we
should show either `move_line_ids` or `move_line_nosuggest_ids`.
Displaying the wrong field will trigger the wrong computes
Part-of: odoo/odoo#136067
`removeprefix` string function has been introduce in Python 3.9 but we
still support Python 3.7
This commit replaces it by an hand crafted one
Part-of: odoo/odoo#136067
Commit 4da8c6ebca change the way the
detailled operation of a stock move is openned. This has been done only
for the picking. This commit adapts the
MrpProductionComponentsX2ManyField widget to act also as the stock move
widget used in the stock pickings.
Part-of: odoo/odoo#136067
The 'pick from' display name would give a name to the dummy quant only
in case of existing stock move line. It's an issue in case of delivery
with the use_create_lot setting as we could generate serial number on
the fly and thus showing a quant on virtual move line
Part-of: odoo/odoo#136067
This commit creates the stock move line in readonly to be able to focus
out the move_line_ids one2many widget without having to confirm the
values of all the move line with a <Enter> key
Part-of: odoo/odoo#136067
Prior to this commit, the reprint receipt screen was not displaying the
orderlines. This fix the issue and add steps in the TicketScreen tour
to test it.
This commit also removes the sub-total section of the receipt because there
is already a breakdown of tax details at the bottom.
Finally, this commit fixes the receipt screen when reprinting the receipt
on the gcc localization.
closesodoo/odoo#136036
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
The 'like'/'ilike' operators automatically add the wildcard character
(`%`) at the beginning and at the end of the value. This commit fixes
the incorrect usage.
closesodoo/odoo#136007
Related: odoo/enterprise#47886
Signed-off-by: Raphael Collet <rco@odoo.com>
The `=like`/`like` domain operators are accent-insensitive, but still
case-sensitive. This is not really coherent, since `unaccent` is a best
effort to find records from the client, and it is the same idea behind
being case-insensitive. Also, `=like`/`like` cannot be used from the web
client, and we use them in domain to search from the Python side.
Moreover, adding `unaccent` to `=like` can be very inefficient when
searching for a prefix ('prefix%'). In fact, PostgreSQL can use btree
index to find prefix matches, but because we create dy default btree
index without unaccent (when we put
`index=True/'btree'/'btree_not_null'` on the field), PostgreSQL cannot
use this index.
Part-of: odoo/odoo#136007
Since odoo/odoo#122569, we now try to import the `migrations`
sub-package of each module to find upgrade tests.
However, this badly written regex match the OCA module `base_maintenance`,
which generate a RecursionError.
closesodoo/odoo#136549
X-original-commit: abd9e6686bdb1f84d67bd536d9cecda627cd001a
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>
Steps to reproduce:
1. Install hr_attendance
2. Go to attendances
3. Select any line
4. Change the check-out date to next day
5. Change the check-out time to 00:00:00
6. Export that line, file format xlsx
7. Favorites > import records
8. Upload the exported file > Test
9. Column check_out contains incorrect values.
Error in line 2: unconverted data remains: 2023-06-11
Cause of the issue:
options.get('date_format') is empty
opw-3374883
closesodoo/odoo#136485
X-original-commit: 973af5854de4a9fa3a9f5bd3bca8c7b342ff71e9
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
This commit simplifies the implementation of ReferenceField and makes
it fully reactive.
Currently, the ReferenceField is not automatically rendered when the
relation is updated from the component. The problem does not currently
occur because when a field is updated, a delete is performed on the
invalidField Set, which causes all the Fields to be rendered. This
behaviour is a bug in owl. Performing a delete on a Set that does not
delete any values should not trigger reactivity. When this is fixed, some
tests will no longer pass.
closesodoo/odoo#136433
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce:
- Install `website_crm` module (for test purpose)
- Go to `Contact Us` page on website
- Edit the page
- Change the submit button to create an opportunity instead, then save
- Fill the form and save
- Go back to CRM app and open the opportunity just created
- In the chatter, try to send a message
- Click on the checkbox of the suggested recipient (to enable it)
Issue:
- Email is displayed twice in the suggested recipients before click
(instead of name + email or just email if same as name)
- Email is set as default name in the opened dialog
Cause:
- Displaying email even if same as name
- Not setting the fields with default values (received from
`/mail/thread/data` rpc call)
Solution:
- Don't display email if same as name
- For the suggested recipient label (next checkbox) : set name with
default name value if name parsed from mail is same value as email
- For the default values in the opened dialog: set default values with
defaults received from `/mail/thread/data` rpc call
opw-3470295
closesodoo/odoo#135951
X-original-commit: 02ef0425a1f4ae30d846f6c57489cdebc3b4bbad
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
steps to produce:
- when measure field value set null if value is zero.
- try to open cohort/graph view measure.
- trackback occurs 'value.toFixed is not a function'.
Fix:
This commit, fixes the trackback when the measure value is null or undefined.
It occurs when the measure field value is null in a particular condition.
closesodoo/odoo#135207
Task: 3502869
Related: odoo/enterprise#47572
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
We introduce a new class of objects to wrap SQL code together with its
parameters. It is designed to be easily composable and to discourage
SQL injections. Its API is similar to the methods of module 'logging':
the code is a format string, and the positional parameters are meant to
be merged into it using the string formatting operator.
# default and increment are parameters of the SQL code in first argument
term = SQL("COALESCE(value, %s) + %s", default, increment)
# term can safely be injected into another SQL, besides regular parameters
query = SQL("SELECT %s FROM mytable WHERE id = %s", term, id_)
The SQL wrapper can return the final SQL code string as query.code, and
the corresponding parameters as query.params (list). The cursor method
execute() can now take an SQL object, and execute it just like
cr.execute(query.code, query.params)
It is quite easy to make SQL objects safe against SQL injections: if the
code is a string literal, then the SQL object is guaranteed safe,
provided the SQL objects within its parameters are themselves safe.
Part-of: odoo/odoo#134677
This commit ensures that changes in translated fields on a freshly
duplicated record will apply to all translation even when the user
language is not en_US.
Steps to reproduce:
-go to accounting -> configuration -> taxes in other language than en_US
-open any record in form view
-duplicate the record
-change the name of the record and save
-ensure that the name is the same in all languages
task-3339736
closesodoo/odoo#134481
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit:
in list view when click on any field it was editable and so can not see the form
view of that record.
After this commit:
a view button is added to the list view to see the form view of the
particular record
task-3471910
closesodoo/odoo#133698
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Steps:
- Open project.task form view in Field Service
- Go to Timesheets page
- the 'is sales order item manually edited' field is visible in Field Service
Issue:
- The technical field is displayed to the user
Cause:
- The view modifier is not updated
Fix:
- Using column_invisible instead of invisible.
closesodoo/odoo#132933
Task: 3461563
Related: odoo/enterprise#46186
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
-Create a system parameter called "blacklisted_emails" and holding
all emails that we want to consider separated by a ,
-When an applicant is generated from an email, if the email is present
on the system_parameter, don't create a partner automatically + don't
use the blacklisted email on the field email either
-When the field email is updated on the contact, or on the applicant
and that the new value is not present in the blacklist, synchronize
both records. (as long as we are obliged to use the partner to send
the email, we need to keep it synchronized with applicant)
-Display the used email on this screen
closesodoo/odoo#126065
Task-id: 3358086
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Currently, errors occur when generating the e-invoicing for
ZATCA (Saudi Arabia). This is because currently, users create invoices without
a tax, but in Saudi Arabia, the invoice line must require at least one tax.
The validation error is present at Line [1], but due to recent changes in
Code [1], the validation is not working. As a result, the user can create an
invoice line without tax. see https://github.com/odoo/odoo/pull/130034.
This commit fixes the above issue by filtering invlocice line ids
that have display_type 'product'.
Line [1]-https://github.com/odoo/odoo/blob/d2f0a0f2c9a18a7a6cef8ca3be52324ad2a1dad6/addons/l10n_sa_edi/models/account_edi_format.py#L406
Code [1] odoo@d8d47f9#diff-78f3e1847de8ca0acf28d72a412947a549acdb08142d1dadf7646363d7972cb0R268-R280
sentry-4467808485, 4467794808
closesodoo/odoo#136568
X-original-commit: 6ee82c26483fabd7962ff4f421924c7330f9b70c
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: ANSARI MAHAMADASIF (maan) <maan@odoo.com>
To reproduce
============
- create a purchase order and confirm it
- create a Bill, set its Bill date and Accounting date to different dates
to today
- save it, then choose the created PO in autocomplete field
the Accounting day will be changed to today
Problem
=======
when calling the autocomplete, some values will be updated on the record,
where `move_type` is one of them, and updating this field will trigger the
compute of accounting date.
Solution
========
if the value of `move_type` on the record is the same as the one of the update,
it should not be taken into account which will avoid uneeded recompute.
opw-3381530
closesodoo/odoo#136559
X-original-commit: 6abcac2025522e5e023d51c02f14c49044658b70
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Abdelouahab Laaroussi (abla) <abla@odoo.com>
*: website_event
Without this, the seo saving would not forward the current website in
the context. It's especially bad in this case as it's writing on views
which are not triggering the COW due to the lack of a website_id in the
context.
Step to reproduce:
- Go to /shop (if you didn't do anything, this will be bound to the
`website_sale.products` view which has no website_id set and is called
a generic view)
- Open "Optimize SEO" dialog and type something in the title
- Save
- It saved the change on the mentioned view, without duplicating it
(COW) before writing on it. The title you added is now applied to
every websites and not only the one you edited, which is against the
website holy grail rule: only the website you edit should be changed.
Technically, this is because we refactored that part of the code in Odoo
16: the website is now editable in the backend.
Note that this fix also revealed that a test for events (which has been
introduced with [1]) was relying on the bug: it tested the meta title of
a view that should (and will after this fix) have been COW'ed. This test
will now indirectly protects this bug from re-happening, although we
might want to write a dedicated test in the future as the behavior for
events might need some refactoring.
[1]: https://github.com/odoo/odoo/commit/2072a7739eb9a9ee87c8b3c7b0d43a82a7e2375f
opw-3499285
closesodoo/odoo#136550
X-original-commit: c45c0bf8fff7285a9fff33ff9bf1c24bbfb130e7
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Before this commit:
-On selecting fullscreen/description for image toolbar stays.
-On selecting description for image focus in not set on input field.
After this commit:
-Now toolbar is removed when selection changes.
-Now on selecting description for image, focus is set on input field.
task-3468251
closesodoo/odoo#136466
X-original-commit: 210230f972c4468c3f472509adb25dfc87d4c2b2
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
During a credit time period where the employee works zero hours,
the employee should still be able to take maternity leave.
Before this change this was only possible if you manually set the
duration of this leave for it to be non-zero, which was kind of a hack.
Now that durations are computed correctly automatically, maternity (and
paternity) leaves were added to the list of exceptions of leave types
that can be taken even if their duration is zero.
Part-of: odoo/odoo#119317
The idea of current date_{from,to} computations is as follows:
The user selects the request_date_{from,end} (and optionally
request_hour_{from,to} and these inputs are then processed into a
date_{to,from}, taking into account the type of leave, the work schedule
(resource_calendar) and time zone (since date_{to,from} are saved in UTC
while the request_dates are stored in the user's timezone.
However, in practice this computation is very messy, resulting in
date_{to,from} needing to be specified in all demo data and test cases,
even though it should be derived from the request dates. Various
superfluous or poorly named methods also exist in this flow
(eg _get_start_or_end_from_attendance which really performs a timezone
conversion, the logic of which resource calendar to use is scattered
across the whole model etc).
date_{to,from} are used many times as inputs throughout the code, with
code being present te inverse compute request_date_{from,to} from these
values. However in reality this is not possible to do consistently.
Therefore with this commit, we restore request_date_{from,to} as the
sole possible inputs, with date_{from,to} being derived from them. In
addition, the timezone and resource calendar are consolidated into their
own fields, with a single computation method computing them.
task-3081565
Part-of: odoo/odoo#119317
Removed this test because
1. What it was testing doesn't make sense, namely the behaviour of
resource leave creation when you explicitly set the resource
calendar id of the employee to a different one than the one on the
current running contract, which is an inconsistent state that
generates warning messages when you try to do so.
2. The test wasn't testing that correctly because it was only testing
whether two resource leaves were created, but not whether they were
actually created in the two different calendars, which was not the
case.
Part-of: odoo/odoo#119317
Currently when a global leave is removed or modified in such a way that
the duration of an existing leave increases, the leave is instead split
into multiple leaves with a gap in between such that it no longer
includes the period that was previously covered by the global leave.
However, this splitting is very error-prone and from a user perspective
is not even always the behaviour that is expected, especially because
editing global leaves is a very low-threshold operation during which it
is in no way indicated that existing leaves might be impacted.
Also note that this is very specific edge case, that in normal operation
should almost never occur. It is therefore best to simply use an
approach that has a minimal impact on the codebase complexity and
produces no unexpected results for the end user.
Therefore in this commit, we handle this case in the following way:
- If a global leave is created or extended in duration, we simply
recompute the impacted leave durations (as was the case before).
- If a global leave is shortened in duration or deleted, the durations
of the affected leaves are also recomputed, but:
- In the case that existing allocations can cover this increase in
leave duration, the leave is left 'as is', but the user is
notified that additional allocation time has been taken.
- In the case that existing allocations cannot cover this increase,
the user is again notified, but the leave is additionally reset to
the 'draft' state (to prevent the allocation from going negative,
which is impossible).
With this approach, it now up to the user to handle this specific edge
case, while no information is changed or lost, which was possible to
happen with the previous approach.
Part-of: odoo/odoo#119317
Before this commit, a company access rule existed for hr_leave but it
checked the company of the associated leave type, instead of the
company associated with the specific employee (or company in case of a
company leave) the leave applied to. This is especially problematic as
leave type are often reused across companies.
This was partially worked around by forcing the company domain using
employee_company_id on the specific actions that showed overviews of
leaves.
With this commit, this is rectified.
task-3383478
Part-of: odoo/odoo#119317
On Database having a postgresql server version superior or
equals than 14.0, a feature called memoization is caching
result of the lateral join made in this query.
This cache creates an issue that results that customers
have the same result for their bank journals.
By adding a LIMIT 1 at the end of the lateral join query,
the memoization is not enabled (according to query plan).
Another solution could be to change the condition of this
lateral join (currently ON True) for a condition on the
journal id but it was less efficient.
opw-3422495
closesodoo/odoo#136498
X-original-commit: 0ccdd9344e2192049aa196f419abac7eb59e4f1a
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
If the currency_id and cost_currency_id is different for a product, the cost in the purchase order is wrong. The purchase order should use cost_currency_id instead of currency_id.
Steps to reproduce on runbot:
-Set the currency of main company as Dollars (USD).
-Choose in runbot the company "My Belgian Company" as its currency is Euro.
- Add the currency rate of today between EUR and USD
- Take a product and edit the cost to 100 EUR - as the cost field is linked with the currency of the company
make sure on the tab purchase there is no information - so the vendor pricelist is not present.
- Go inside the purchase module and start a request for a quotation
leave the currency as EUR
- Select the product to purchase
Current Behavior:
The unit price will be (100*currency rate). If you do the same but take the currency as USD the product unit price on the purchase order line will be 100
Expected Behavior:
The unit price should have been 100 Euros. And when dollar is chosen as currency, the exchange should have been applied.
OPW-3460551
closesodoo/odoo#136298
X-original-commit: f9c66ff20f2e7d8d35b9bc775486bb62abd4c367
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Signed-off-by: Hamza Islam (hisl) <hisl@odoo.com>
Before this commit:
-With selection on checklist, on unchecking it toolbar is not updating.
After this commit:
-Now toolbar is updated when list unchecks.
task-3504398
closesodoo/odoo#136541
X-original-commit: 2cf3dd5988914a09bbc2098eccb3c8419995e120
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit:
Indenting list using tab inside a table used to switch to the next cell.
After this commit:
Indenting list using tab inside a table now indents a list instead of switching
to the next cell.
task-3470092
closesodoo/odoo#136538
X-original-commit: 62c16468e2759eb0a0c3eecf3866b543be3bfabb
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Report footer is sometimes misplaced in settings preview.
We change the css to always stick to the bottom of the preview,
no matter the content height.
Task-3145445
closesodoo/odoo#136534
X-original-commit: 9be75bb17063c6b0207aa82144e9f44b6e49dc45
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Report body size was too narrow to render bootstrap .col as column,
the media query consider the report as a mobile view.
We unlock this limitation to let customer add column in the footer.
Task-3145445
X-original-commit: 3631e51e224e843cf6b6cd1da82592be4cb9397f
Part-of: odoo/odoo#136534
Alexandre Kühn