Remove unused parameters, trying to keep a simple API. Those are not used,
probably coming from old usage of rating module. Subtype, composition mode
and email layout XMl ID are never set. Until further requirements better
fallback on default values.
We also also clean a context key usage while passing by, as it is not used
in standard codebase anymore.
Task-2710804 (Mail: Clean MailThread Posting API)
closesodoo/odoo#106024
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit:
When task project is changed in through the view the kanban_state remain the same
until the record is saved.
After this commit:
When changing project, kanban_state is changed to 'normal' direclty.
task-2849291
closesodoo/odoo#91174
Related: odoo/upgrade#3523
Related: odoo/enterprise#27287
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
After this commit:
- When duplicating project or task, assignment notifications and emails on stages are not sent
task-2849291
Part-of: odoo/odoo#91174
Before this commit:
- Task followers are not copied when creating subtasks
After this commit:
- Created subtasks have the same followers as their parent task with the same subtype_ids
task-2849291
Part-of: odoo/odoo#91174
Purpose is to try to have code easier to read and to update by having a
common way of sorting / writing code. Reorder some fields definitions and
dictionaries, update docstrings, ... in mail applications or when invoking
mail thread API.
Additional stuff worth noting here
* add some tagged in tests helping debugging / choosing tests to execute;
* in a test about mail generation with server action: correctly check
body_html field, not body which comes from the mail.message inheritance
(currently filled due to a side effect but actual field to check is the
html one);
* add same check on input for ``_render_template_qweb`` as done on other
rendering methods (even if rendering on [False] should be supported);
* move code translation update from specific tests into main test class
(code update due to new translations, followup of odoo/odoo@f8c2b02abe);
Some test linting done here
* reorder mail_render tests, remove some duplicated tests;
* reorder mail_template tests, remove some duplicated tests;
Task-2710804 (Mail: Clean MailThread Posting API)
closesodoo/odoo#106025
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
- logged in as user with admin or officer permissions;
- create time off request with config for sick time off request;
- try to delete partially approved time off request from calendar view by pressing delete button.
(The button is in the window that opens when you select a time off)
Issue:
Partially approved time off request are not deleted when using delete button in calendar view.
(It can only be deleted via the list view)
Cause:
The function which deletes the element is not called.
opw-3061570
closesodoo/odoo#106023
X-original-commit: b9d01d30474303747f65376b0abf4cde3d2400e7
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
In grouped kanban, when having groups but no record to display, the
group creation button (ie. "+ Stage" in Project) and its related column
are muted instead of being the regular colors (like for the groups'
titles).
This commit fixes it by applying a fix similar to the group's title one
(cf. odoo/odoo@cbefc9cd51)
for the quick create column element.
Steps to reproduce:
- Open Project
- Create a new project and open it in kanban view
- create a few stages
=> the quick create column is "muted"
- dismiss the quick create column (ESC or click outside it)
=> the "+ Stage" button is muted
closesodoo/odoo#106022
X-original-commit: e95e2a23bc168815a27a9c64e4ff9394de468ada
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
When manualy create a productivity log on the workorder form, you are
always asked to choose a time_id(productivity). But by default, the
field is hidden. Make this field shown by default for better use
exprience.
closesodoo/odoo#106007
X-original-commit: 84cde486c700420c8898847342f158393c02649c
Related: odoo/enterprise#34098
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Yuchen Huang (yhu) <yhu@odoo.com>
Adapt tests for other moudules to use
ENT PR odoo/enterprise#33399
X-original-commit: 88cad50cac8130e1ff66a21ab63d53b41488a74a
Part-of: odoo/odoo#106007
PURPOSE
Cleanup alias definitions and usage to have as few invalid or dummy
data as possible. Cleanup empty list helpers override.
SPECIFCIATIONS
hr_expense: cleanup alias management
* globally avoid crashes if the alias data has been removed;
* recreate Xml ID record if it has been removed as it is considered as
being a master data;
* avoid issues when trying to configure the expense alias in settings if
alias has been manually removed. Setting a name now creates the alias
and an XmlID if it has been removed;
* rename a generic 'use_mail_gateway' field into 'expense_use_mail_gateway'
in order to avoid conflicts with future changes in generic settings linked
to email gateway and configuration
* fix empty list helper: it is now translated and correctly encode parameters
given to 'mailto';
hr_recruitment, maintenance: remove unused aliases
Those modules hold default aliases to respectively create applicants or
maintenance request. Issue with those generic aliases are
* they are not bound to any context (container document). For example jobs
is not linked to any job record. Applicants will not have any job_id set;
* they are not displayed anywhere. Applicant kanban view displays a helper
when having no content, with an email address to start populating the
view. This emails is however based on job in context, aka alias record
created through the alias mixin on the job.
* maintenance does not even try to use aliases in any view or code and just
defines a dummy alias;
* as default data they can be wrong: taking ``jobs`` and ``helpdesk`` is
not necessarily a good idea. Indeed it depends on mail server configuration
(e.g. not always owning all possible emails of a domain when using its own
address like gmail). This may also conflicts with existing email addresses
or already-defined aliases without being really configurable;
* they are not configurable. They are not displayed in any configuration flow
(setting or container document). Only going into technical menus to find all
aliases allows to find them;
mail: improve mail alias views to ease usage
mail, various: cleanup empty list help message overrides
Purpose is to cleanup code: stop using help parameter name (use help_message as
help is a keyword), try to call super(), ...
LINKS
Task-2710804 (Mail: Clean MailThread Posting API)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
closesodoo/odoo#105992
Related: odoo/upgrade#4046
Related: odoo/enterprise#34089
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose is to cleanup code: stop using help parameter name (use help_message as
help is a keyword), try to call super(), ...
Task-2710804 (Mail: Clean MailThread Posting API)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#105992
Purpose is to improve understanding and modification of alias records in
backend by improving form view.
In this commit we add missing fields in tree view, notably about alias owner.
Add buttons allowing to open the updated thread or the alias owner directly
from tree view to ease daily management of aliases. Cleanup filters.
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#105992
Those modules hold default aliases to respectively create applicants or
maintenance request. Issue with those generic aliases are
* they are not bound to any context (container document). For example jobs
is not linked to any job record. Applicants will not have any job_id set;
* they are not displayed anywhere. Applicant kanban view displays a helper
when having no content, with an email address to start populating the
view. This emails is however based on job in context, aka alias record
created through the alias mixin on the job.
* maintenance does not even try to use aliases in any view or code and just
defines a dummy alias;
* as default data they can be wrong: taking ``jobs`` and ``helpdesk`` is
not necessarily a good idea. Indeed it depends on mail server configuration
(e.g. not always owning all possible emails of a domain when using its own
address like gmail). This may also conflicts with existing email addresses
or already-defined aliases without being really configurable;
* they are not configurable. They are not displayed in any configuration flow
(setting or container document). Only going into technical menus to find all
aliases allows to find them;
Conclusion: cleanup and remove.
Task-2710804 (Mail: Clean MailThread Posting API)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#105992
Purpose of this commit is to cleanup alias usage in hr_expense. Indeed it
is currently used as a master data without being cleanly supported.
In this commit we
* globally avoid crashes if the alias data has been removed;
* recreate Xml ID record if it has been removed as it is considered as
being a master data;
* avoid issues when trying to configure the expense alias in settings if
alias has been manually removed. Setting a name now creates the alias
and an XmlID if it has been removed;
* rename a generic 'use_mail_gateway' field into 'expense_use_mail_gateway'
in order to avoid conflicts with future changes in generic settings linked
to email gateway and configuration
* fix empty list helper: it is now translated and correctly encode parameters
given to 'mailto';
Task-2710804 (Mail: Clean MailThread Posting API)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#105992
The account 81 to 89 were misclassified, this PR fix the issue
closesodoo/odoo#105999
X-original-commit: 14783ca3260bd3146da6421dc91c28c03257d5ef
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Maximilien La Barre (malb) <malb@odoo.com>
the context passed to the method _get_product_purchase_description for the seller_id is wrong. system is expecting to get product.supplierinfo record set in this context key and from this function res.partner record set is passed, which results in the below error:
Record does not exist or has been deleted.
(Record: product.supplierinfo(70,), User: 2)
closesodoo/odoo#105998
X-original-commit: 6e7f778e1d0dbe4795fa9446bfd3542ecec9815c
Signed-off-by: Tiffany Chang <tic@odoo.com>
Steps to reproduce the bug:
- Create a storable product ”P1” with 2 BoM:
- BoM 1:
Type: manufacture
Component: C1
- BoM 2:
Type: manufacture
Component: C2
- Create a MO:
- Add the product “P1”
- The BoM 1 is automatically set and the component “C1” is added
- Save the MO
- Edit The MO:
- set the BoM 2 instead of BoM 1
Problem:
The component C2 is added, but the component “C1” linked to BoM 1 is
not deleted
To delete the existing lines, we check if the product has changed,
but we do not check if the BoM has changed:
https://github.com/odoo/odoo/blob/16.0/addons/mrp/models/mrp_production.py#L694
Solution:
clear “move_raws” if BoM change.
No need to check if the product has changed to clear component,because
if the product changes, the bom changes too
opw-3069283
closesodoo/odoo#105983
X-original-commit: 916449eb382715f341b05666cfec336e30c5db36
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
New class `fields.Json` is introduced in v16. The feature lacks some converting
methods for export/import. This commit fills the gap.
Example: field `line_ids/analytic_distribution` in `account.move` (Invoices)
opw-3056669
closesodoo/odoo#105973
X-original-commit: abbe2e002c0125ecb83a1ab3ee80acf3f43e3cb6
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
On creating views manually via UI, the web client sends following parameters
arch_base: "<data></data>"
arch_db: false
(in previous v15 release is was only `arch_base` [1])
This triggers `_check_xml` method, which raise error because of empty value for
`arch_db`.
Fix it by removing empty `arch_db` attribute in `create` method.
[1]: https://github.com/odoo/odoo/commit/e5735d0a467afcfc66a2b17275b27d4cf80789bf
opw-3038722
opw-3032865
closesodoo/odoo#105971
X-original-commit: 77f10460a6fd8d5de0853b3fb95c753e08060a5a
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
Before this commit:
When we try to copy paste link into another link then url of the old link does
not change and only lable change.
After this commit:
Now when we try to copy paste link into another link then the url of the link
changes with the label.
Task-2768541
closesodoo/odoo#105966
X-original-commit: ea1e410f4174d235609181bdba692a98e7381396
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
traceback is raised in settings page and on clicking activate stripe button after deleting the paypal payment provider from the database
closesodoo/odoo#105692
X-original-commit: 4d34606baf314c78d608904720778ff2ac6bf5b4
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Bug
===
If we hover the property label, we should see the bottom border of the
property value (like for standard fields).
The bug still exist for the tags and many2many, because it's based on
the AutoComplete component, and the same bug exist for standard
many2many tags.
Task-3039733
closesodoo/odoo#105969
X-original-commit: 3ced33f434e84361448062b4795108df6186ffed
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
activate warnings from purchase settings and open any purchase order and click the create alternatives button from alternatives page. in the next wizard, Warning Messages field is visible always, upon checking the view, it seems the visibility condition given is wrong and thus it get visible always.
closesodoo/odoo#105977
X-original-commit: 40ec1fe8fbaf97faccda7dcd87e308277275bae4
Signed-off-by: Tiffany Chang <tic@odoo.com>
Steps to reproduce:
- Install `sale_timesheet`
- In Sale, create a so with a 'service' product with invoicing policy
set on `Based on Timesheets` for customer A
- Confirm the SO
- Create a new project and check Billable and Timesheets
- Edit the Project and set customer to A
- Go in the `Invoicing` tab
- Enter the SO line you created before.
- Create employee mappings on the SO line you created before
- Click on the Save manually button
- Click on the Invoice button
- Chose Down payment (percentage)
- Set the percentage to 10%
- Click on `Create Invoice`
Issue:
A traceback is displayed when trying to create a downpayment on a project.
Cause:
Currently we filter the sol that are to invoice (`invoice_status` set to 'to_invoice')
prior to provide them to the wizard `sale.advance.payment.inv`.
As the result is an empty recordset, no sol ids are passed to the wizard.
Thus when trying to create a downpayment, no related sol is provided and
the error is thrown.
Fix:
As the `sale.advance.payment.inv` handles the fact that there are items to invoice
when choosing `regular invoice` there is no risk passing so line with an
`invoice_status` set to 'no' which will be used in this use case.
Closesodoo/odoo#104720closesodoo/odoo#105987
X-original-commit: 8ec5aed363c8e714c109b2eb0fc7da966b6d31a3
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
remove checkJS: It made the ts server check for error, bypassing some
eslint rules (such as globals).
add ts files in the include: ts files need to be included in the project
as there are some .d.ts files defining types.
closesodoo/odoo#105984
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Exporting a Binary field with a value of type dict from a record raises
an error
Steps to reproduce:
1. Install Accounting
2. Open Accounting and go to Vendors > Bills
3. Open any posted bill and register the payment
4. Go back to the list view and export the bill in payment
5. Add field Invoice Payments Widget to the exported fields and export
6. An error is thrown
Solution:
Make the field attribute `exportable` work (pass it in the field
description)
Make fields `invoice_outstanding_credits_debits_widget` and
`invoice_payments_widget` non-exportable as they contain computed
aggregated data for the client's benefit and it doesn't make sense to
export them
Problem:
xlsxwriter's `write` doesn't support type dict
opw-3054184
closesodoo/odoo#105972
X-original-commit: c925ecb2a22750524020f0d111888fd76eedb0cb
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
In rating/controllers/main.py, the method action_submit_rating accepts
only post request. This creates a problem when you're trying to use the
web editor on the template as well as when you just paste the url in
your browser, for those are get request. The current behavior is a crash
with 'method not allowed'. This commit's purpose is to change the method
so it also accept get request. The use case of editing the feedback
rating page is arguable but it schould not crash.
The behavior after this commit is that the web editor is enable for the
page, and relaoding the page does not crash anymore.
task-3047893
closesodoo/odoo#105985
X-original-commit: 1b61faad8281d8b8d2fa1bf526f2ae2c4c8ba07b
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Steps to reproduce:
- go to e-commerce app;
- select a product;
- try to return to the shop with the browser's back arrow.
(if the URL contains `\@\`, is not necessary to click on a "action", otherwise we must)
Issue:
It is not possible to go back.
Cause:
Modifying the hash modifies the history of the browser.
Solution:
Change hash without changing browser history.
`window.location.replace` documentation: https://developer.mozilla.org/en-US/docs/Web/API/Location/replace
opw-3061027
closesodoo/odoo#105976
X-original-commit: b3f501db38e14b28cc6b63ffe91562e556a97c16
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
closesodoo/odoo#105963
Checkjs: provide better erros in the IDEs
Disablesizelimit: experience to see if it works better with this
Target: import the default lib.d.ts for type checking
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
This commit adds and fixes type annotations to give more accurate
autocompletion for javascript.
closesodoo/odoo#105670
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
*: im_livechat, website_livechat, website_slides
In c989ff3, the odoo module system has been changed so that it now
errors out when modules are defined but have missing dependencies and
cannot run. Unfortunately, tours are defined in a single bundle,
`assets_tests`, and this bundle is used everywhere tours need to run,
but some of these tours depend on modules that only exist in the backend
and others on modules that only exist in the frontend. We don't want to
break up the `assets_tests` bundle as this creates a poor developer
experience, and so the solution that was chosen at the time is that when
the `assets_tests` bundle is defined, we ignore all module dependency
errors.
This causes a problem however, which is that if a module dependency is
missing in production code, the page will be broken by the module error
(which is expected) but if the `assets_tests` are present, which is the
case when running tours and tests, then it won't, meaning the tours will
happily pass despite the application being broken, which is
unacceptable.
This commit fixes this issue by replacing the assets_test bundle by a
new bundle (`__assets_tests_call__`) within which all module dependency
errors are ignored, which lets dependency errors that are hapenning in
other bundles (ie in production code) happen even during the tests.
Because of this, this commit also fixes the dependency errors that
already existed but were previously silent:
- for im_livechat and website_livechat, the code was refactored to use
the standard mechanism that we use elsewhere to add data directly in the
page: we store the data in __session_info__, and the module that exposes
that data is always present, instead of having a module that's defined
conditionally, which causes issues when non-conditional modules depend
on it.
- in web, the `report_assets_common` bundle was used alongside
`assets_common` but without `assets_frontend` or `assets_backend`.
Reports do not need any js and it appears that it already had what it
needed as far as css is concerned except for one fontawesome override.
Code was changed so that the js from the bundle is not included and it
reports no longer use `assets_common`, the js part of the bundle is no
longer used.
- in website_slides, the `slide_embed_assets` bundle is used alongside
`assets_common` without using `assets_frontend` or `assets_backend`
which is required for `assets_common` to function, the approach here was
to simply take the files from `assets_common` and remove the files that
were causing issues. This bundle should be trimmed at some point, as it
contains way too many things that it does not need.
The file colors.js was also moved to core, as it isn't graph specific
and was causing dependency issues with a field that was importing it.
Fields shouldn't depend on files in specific views' directory.
closesodoo/odoo#104794
Related: odoo/enterprise#33909
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When the price and the event are the same, nothing allows
ordering tickets in event_sale. Therefore, add a sequence
number and handle widget to the tickets (in data as well).
Also do it for ticket templates. Also, order the tickets
(on events and templates) by name before id.
Since event type tickets are not linked to any event, the
order does not include the event_id. However, event event
tickets are, and if they appear in the same list / reporting
someday, it makes sense to order them by event_id first.
In event_sale, we make sure the price is also in the order.
As the price is in the copied fields on the event when
using an event template, we add the price on the event
type tickets ordering to align with the event event tickets.
Add default value to sequence and sequence number to data
for event.type model. They were sequenced but demo data had
none, hence not really ordered.
We also add the id in the event.event _order value, otherwise
when ordering on the event (for instance ordering on event_id
for event.event.tickets), the order is random for events
having the same date_begin. We prevent this from happening.
Also make description optional hide on event types.
Task-2997391
closesodoo/odoo#101384
Signed-off-by: David Beguin (dbe) <dbe@odoo.com>
It is not possible to consume a component tracked by serial that comes
back from a scrap location
To reproduce the issue:
1. In Settings, enable "Multi Routes"
2. Create two storable products P_compo, P_finished
- P_compo is tracked by serial number
3. Update the on-hand qty of P_compo:
- 1 x P_compo with serial SN
4. Process a manufacturing order MO:
- Product: P_finished
- Compo: 1 x P_compo with SN
5. Unbuild P_finished
- It brings SN back to stock
5. Scrap one P_compo with SN
6. Unscrap it (thanks to an internal transfer)
7. Repeat step 4
Error: a user error is raised: "The serial number SN used for component
P_compo has already been consumed"
When checking the SN uniqueness of a component, we don't consider the
case where a product came back from a srap location
OPW-3055252
closesodoo/odoo#105926
X-original-commit: 476dbb6f2138294200ba7bfef96553e5d89b1a0e
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Remove the Dynamic Placeholder from the legacy Odoo field.
Introduce in 308f639e295fce07e4f34d6c76b35aab259e21ad
And migrate to be OWL compatible in #101768
Therefore the old code targeting legacy odoo field is unnecessary
and need to be cleaned.
task-3071417
closesodoo/odoo#105920
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, once a user was disconnected from internet (eg.
network failure, laptop screen closed), the code disconnected the user
from the peer to peer network and upon reconnection to the internet
network, the code did not try to reconnect to the peer to peer network.
This created a network partion in the peer to peer network each time
a user disconnected and reconnected to the internet network.
When there is a partition in the peer to peer network, the last subnet
to write to the record erased the changes of another subnet without
notification.
This commit prevent the code to disconnect from the peer to peer network
when there is any disconnection signal triggered.
closesodoo/odoo#105900
X-original-commit: 8bce8cd53d1c6da89fce8c2f8b64615168d45a0d
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
- Use of jsconfig instead of tsconfig
- jsconfig deployed with tooling, no need for CLI
- ecmascript bumped to version es2022 (static properties)
- prettierrc merged inside the eslintrc
- add a few globals
- cleanup package.json scripts
- add script to lint/format only the diff (opposed to staged files)
- bump up node packages versions
- use eslint as cli instead of prettier-eslint, as eslint does provide
parsable output for runbot.
- add the typescrit types of libs as dependencies + main.d.ts to
improve autompletion.
This upgrade makes it easier to deploy and use the js tooling, as it is
expected more and more people will use it if a lint check is added to
the runbot.
About the runbot:
The commit gets the code ready to enable the lint on the runbot.
It will lint the code with the same rules and same ignore file.
The only difference is the runbot will check only the diff and not the
entire commited file.
The goal will be to progressively (and aggressively) whitelist modules
to converge to a nice formatted codebase.
closesodoo/odoo#105165
Related: odoo/enterprise#34048
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Previous commit 0501bbd62e made it so
the `product_uom_id` for the `line_ids` of a purchase.requsition (i.e. a
blanket order) were no longer being saved when the UoM setting is not
active. This would cause an error to occur when the "New Quotation"
button is pushed because the missing uom is expected by purchase
_onchange_requisition_id.
Steps to reproduce:
- Have UoM setting NOT active
- Create a blanket order for any product/vendor
- Confirm the blanket order
- Click on "New Quotation"
Expected Behavior:
New RFQ created
Actual Behavior:
Stacktrace
We also properly restrict the product_uom_id in the form view of the
line_ids to when the uom setting is active.
closesodoo/odoo#104900
X-original-commit: e90200a7b927ecccb8d4d6f31e3ddecba24d0b6d
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Previous fix
https://github.com/odoo/odoo/commit/72dff43a4da277b002966f5fd4045b7f9a3855ad
re-exposed uoms in the view even if the setting is not active, but we
prefer to avoid this if possible. In order to do this we ensure that the
uom is set even if it is not visible in the view. Most of these are
already handled by compute methods, but except for `repair.fee` so we
only add in a guarantee for that model.
Note that the write case is included in cases when:
- the uoms were previously activated and set => deactivated again
- demo data has different uoms set and uoms setting is not active
X-original-commit: 7e64ebb3d8d3f3d3749304a325eb073777b129dc
Part-of: odoo/odoo#104900
scrap_qty was recently turned into a compute but was missing
readonly=False so scraps created from scratch were stuck on a scrap_qty
of 1.
X-original-commit: e2a2a6e2526446b6f8d041135a4e5653fa96bb47
Part-of: odoo/odoo#104900
Steps to reproduce:
- Switch to `?debug=assets`
- Change the user language to Arabic and back to English
-> The page is still displayed in rtl mode
Cause of the issue:
The css is retrieved like this
```py
>>> self.env['ir.attachment'].sudo().search([('url', '=like', '/web/assets/%/web.assets_common.css')])
ir.attachment(212, 189)
>>> self.env['ir.attachment'].sudo().search([('url', '=like', '/web/assets/%/web.assets_common.css')]).mapped('url')
['/web/assets/212-5d47380/rtl/web.assets_common.css', '/web/assets/189-5d47380/web.assets_common.css']
```
Only the second one should be matched.
Solution:
Check for the absence of an extra parameter in the url
opw-2892012
closesodoo/odoo#105127
X-original-commit: 539427fa2a099b29adf099c2b48d4f1d2fd4ebd2
Signed-off-by: Julien Castiaux <juc@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Purpose of the commit is to do the generic improvements for project app.
So in this commit did the following changes:
- add the 'creation date', 'last stage update', 'SOL', 'my deadline' fields in
project task list view.
- add the 'my deadline', 'next activity' fields in project list view.
- crop the label of the stage after x characters in task portal form view.
- remove the 'collaborators' stat button from project update right-side panel.
- renamed sold->sales, services->sales order items, effective->delivered,
remove the totals, include non-service SOLs, increase the size of the SOL
column
task-2928100
closesodoo/odoo#97870
Related: odoo/enterprise#30268
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
The tour is failing undeterministically, seemingly because a step is
done too soon after the previous one without giving the time for the
website to reload everything as expected.
By reordering the steps a bit, this issue can be avoided and fix the
test issue.
closesodoo/odoo#105891
X-original-commit: ff91efcda8cb80da4c376e74714f4c0dedad63c1
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Thibault Delavallée