Also speed up the basic setup of fields that are always duplicated
top-level (on the model's registry class). This saves time and memory,
as we also discard field.args and field._base_fields on toplevel fields
(those values are no longer useful after setup).
This replaces the setup of the attribute 'currency_field', which depends
on the presence of other fields on the model, and may therefore vary
from one registry to another. This is necessary to make monetary fields
shareable across registries.
The attributes field.depends and field.depends_context are problematic
for sharing fields across registries, because they depend on the model's
registry class, which may vary from one registry to another. In order
to make computed fields shareable, we have to move those values away
from fields.
For the same reason, field.recursive should not be inferred, because its
value may depend on the registry, although it is generally not the case.
Moreover, the flag recursive=True is set on a field when field triggers
are determined (on the registry). A compute method may be called before
the flag is set (if no update has been done yet), and that can lead to
incorrect computations.
This happened in test TestUsers2.test_reified_groups in module 'base'.
The user groups view was apparently determined without the flag being
set, and the view depends on the recursive field 'trans_implied_ids',
which was not correctly computed.
We thus force developers to be explicit about recursive computed fields.
The code now logs a warning when the flag is not set up properly.
The basic setup of fields is now made in Field.__set_name__(), which
automatically makes this information shared across registries, because
it is done when importing Odoo modules.
Fields are no longer retrieved with inspect.getmembers(), which is
time-consuming. Instead, the classes defining models automatically
collect their own fields (via Field.__set_name__()), and the field
retrieval is done by using those collections. Also, a field no longer
needs to introspect its model class to find its field definitions.
A class that defines a model automatically determines its '_name',
'_inherit' and '_module' upon creation, and the fields determine their
'name', 'model_name' and '_module' via Field.__set_name__().
Loading a registry with 290 modules from scratch is now 25% faster.
Purpose of the task is to do a generic UX improvement in project
Specification:
--------------
1) Stages(project.task.type)
* List view:
- move the 'folded in kanban' field to the right of the project_ids one
- remove the description field from the list view
- make the list view editable in batch
* Form view
- rename 'stage name' into 'name'
- move the sequence field below the 'rating email template' one
- change the copy of the tooltips to: "At each stage, employees can
block tasks or mark them as ready for the next step. You can customize
here the labels for each state."
- the tags should be colored according to the project's color
- reduce the space in between the icons and the name of the states
- add some space in between the legend_done field and the description
- when creating a new mail template, set 'project.task' as model_id
of the template
* move the 'Stages' menu into below the 'Projects' one
* add the project_ids field to the kanban view
* search: rename 'Tasks Stages' into 'Name'
2) Tags(project.tags):
- configuration > tags menu: change the helper to: "Tags are perfect
for categorizing your tasks."
- add an optional list view -> only the color field should be optional
and displayed by default
- new tags should be created at the top of the list
- Also removed some of the unused(deprecated) css which are not applied
anywhere in the project.
closesodoo/odoo#69636
Taskid: 2508642
Related: odoo/enterprise#17865
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Currently ``name`` field that holds the action type is recomputed each time
duplicated leads are updated. However duplicated leads are often updated
notably each time customer action (create / link / do nothing) and chosen
customer are updated.
As ``name`` compute method is mainly present to replace a default value
its compute method is updated so that it nows compute only when not having
a value. Once having a value user choice is kept.
Task ID-2452777
COM PR odoo/odoo#68618closesodoo/odoo#70254
X-original-commit: d75905f7acb1e7584d01792b4880fa76e6920d56
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Issue
- Create a partner with email 'aaa@test.com'
- In CRM settings, activate 'Leads' feature
- Go to CRM -> Leads and create a Lead:
- Set email field to 'aaa@test.com'
- Click on 'Convert to opportunity'
Neither the action or partner_id field is set to the right value.
Cause
Due to missing 'lead_id' field in template, the partner_id field
is not recomputed since action is not recomputed.
Solution
Add 'lead_id' field as invisible in form.
opw-2439722
Task ID-2452777
COM PR odoo/odoo#68618
X-original-commit: 6915d17f5f10737c03c820b69eded3a7c0151907
Some feature descriptions and titles have been reworded.
A sentence has been added below the title to indicate
that choices made on this screen are not definitive.
Task ID: 2451965
closesodoo/odoo#70252
X-original-commit: 63195ba03ccc1bf40b4682fc7c9aa4a1a55f1e43
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: Sébastien Mottet <smottet@users.noreply.github.com>
There is currently a limitation with required fields because an "on change"
compute might trigger the check for "required" before all the actual computes
have been done, leading to the required field check incorrectly failing.
The main goal is to ensure the "on change" computes are done after all the other
computes and after the check for required fields.
A check has also been added to ensure no "real" compute can trigger update cycle
side-effects anymore.
Opportunity is also taken to prevent from checking for required fields on a
record that was deleted as part of the same update cycle.
Somewhat part of task-2278551
closesodoo/odoo#70204
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
When selling a tracked product that comes from a specific place in the
warehouse, the module will ignore this information and set the parent
warehouse as source location.
To reproduce the error:
(Use demo data)
1. In Settings, enable "Multi-Warehouses"
2. Create a product P:
- Product Type: Storable Product
- Available in Pos: True
- Tracking: By Unique Serial Number
3. Update its quantity:
- Location: WH/Stock/Shelf 1
- Serial Number: USN01
- Qty: 1
4. Start a POS session
5. Sell P
- Enter the same serial number
6. Go back to quantity update page for product P
Error: The quantity for "WH/Stock/Shelf 1, USN01" is still 1, it should
be 0. Moreover, a new line appeared: "WH/Stock, USN01, -1" which is
incorrect. The POS module considered that the product sold came from
WH/Stock instead of WH/Stock/Shelf 1.
OPW-2473002
closesodoo/odoo#70194
X-original-commit: 02a68278a9af2c477cc9a30716feabb0b533b7e7
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Steps to follow to reproduce the bug:
- Install Inventory and Purchase
- In the inventory settings, Enable the "Landed Costs" option
- Go to Purchase > create a Service type product
- In the Purchase tab > Enable "is landed cost" option and choose "by quantity" in the default split method
- Go to Orders > Requests for quotation > Create a new RFQ > add Any product and confirm the order
- Validate receipt of the product
- Create a bill > add the Service you created at the beginning
- Create Landed Costs
Problem:
we do not use the split method landed cost of the product, we automatically set it to "equal"
opw-2465753
closesodoo/odoo#70247
X-original-commit: 5da8c593353edcae4540bec696e259031f2d60f5
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>
Without this commit, User was not allowed to create Unbuild Order
for the product without BoMs from Unbuild Orders menu.
But User was able to create Unbuild Order using 'Unbuild Order' button
on MO.
With this commit, We are allowing user to select Products without BoMs
to make this behavior consistent so user can create Unbuild Order from
Unbuild Orders menu.
closesodoo/odoo#70246
X-original-commit: eb332de42a36b7235d5578d39d345a5ff1df7759
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
add the name of argument, if not precision_digits is used.
closesodoo/odoo#70242
X-original-commit: 2e7dfec50e9104adf8efbc64e0342359dc8947a7
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Previously, when toggling on background shapes, they always had the
default colours. In [1] we made it so that when you toggle on a shape on
a section, it would automatically reuse the colors of the surrounding
shapes if any.
Unfortunately, when the "implicit" colors were also the default colors,
they were still marked on the shape, and it got an explicit background
image that would no longer react to changes in the palette.
This was caused by the fact that the call to _getDefaultColors returns
an empty object when the section doesn't already have a shape-container,
this was not a problem before since we were not passing in any colors
when creating the initial shape previously, the the aforementioned
change made it so that we did.
This commit fixes the issue by creating the shape-container before
calling the method that will set the colors on the shape, this way
getDefaultColors works as expected, and the colors are not marked on the
section when they are the default ones, restoring the ability of the
shape colors to adapt to the palette
[1]: https://github.com/odoo/odoo/commit/875aca63f7dab287c61485ebe999b3b8dd89d91c
task-2500607
closesodoo/odoo#70054
X-original-commit: 63acc2b0d1957dedd40af2033722f9ea4ef2e597
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Tom De Caluwé <tdc@odoo.com>
delete redundant '}' added by accident
The redundant '}' might be added by accident.
It makes the the correct avatar image cannot be found and shown as a default camera image when the user
* Open calendar
* Hover on on of the responsibles listed in the right side panel of the calendar view
closesodoo/odoo#69139
Taskid: 2504659
Signed-off-by: Arnaud Joset <arj-odoo@users.noreply.github.com>
set the specify placeholder for company partners from 'placeholder.png' to 'company_image.png'
After this commit, in the res.partner kanban view, if the company image of an individual is not set,
it will be shown as the 'company_image.png'(a company logo) rather than the 'plaeholder.png'(a camera logo).
closesodoo/odoo#68994
Taskid: 2491161
Signed-off-by: Arnaud Joset <arj-odoo@users.noreply.github.com>
Before this commit, if any workorder is stared to produce, qty
producing was 0. After this commit, if product tracking is none
then system will suggest the remaining qty of workorder to produce
when user is start it.
TaskId - 2480775
closesodoo/odoo#70207
X-original-commit: 5bbc234d43a415be18fcfa42dad33b1577644719
Related: odoo/enterprise#18086
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Previously, lazy-loading xml templates was only possible by fetching the
xml file directly, this meant that it was impossible to lazy-load an
entire bundle's templates with a single request. Additionally,
requesting the xml files directly meant that no inheritance was applied,
causing the need for a separate inheritance system using t-jquery on the
client-side.
This commit alters the /web/webclient/qweb route so that it now takes a
bundle id, meaning that it is now possible to lazy-load the xml from
arbitrary bundles.
task-2497943
closesodoo/odoo#70084
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
- Create a service product with cost 0
- Create a sales quotation
- Add the service product, change the cost to a positive quantity
- Save and Confirm.
Purchase Price (cost) will be reset to 0
opw-2481564
closesodoo/odoo#70036
X-original-commit: 8a8ff03f6111f377bcd9c2b0f584c450b82a4182
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
- Create SO with deliverable product, confirm
- Change delivery Address on SO and on Transfer
- Inventory > Stock moves (debug mode)
- Group by > Picking and Destination address
The address shows is the original and not the updated one.
opw-2429018
closesodoo/odoo#67407
X-original-commit: c813655074b3b83bdf9345ef12399b0b96feaf71
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Steps to follow to reproduce the bug :
- Install the Repairs and Accounting application
- Create a new user and give him only access to Accounting
- Connect with this user
- Create a draft invoice
- Try to delete it
- Access rights error is triggered.
Problem:
When we delete an invoice and the Repairs app is installed, we check if it is not an invoice related to a repair.
But the user does not have access to “repair.order”, so we can not check the field "repair_ids".
opw-2507867
closesodoo/odoo#70095
X-original-commit: b5588246a0e032c92b8443e67875ff4146858fe8
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>
On creating a new note, the focus was automatically set into the "tags"
field. This was inconvenient and was replaced with an autofocus on the
note itself so we the user can immediately start typing.
closesodoo/odoo#70195
X-original-commit: 8fe89c5ebc138cb517938dbd6d975b8bec4eaf4d
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
What are the steps to reproduce your issue ?
1. Create a contact and set 'VAT' to "20AAACT2803M2ZO". The 'GST Treatment' will be automatically set correctly.
2. Create a sale order for this new contact. GST Treatment is automatically filled in correctly.
3. Confirm the order.
4. Create an invoice.
What is currently happening ?
The related invoice does not fetch the 'GST Treatment' automatically
What are you expecting to happen ?
The related invoice must set the 'GST Treatment' automatically.
opw-2499503
closesodoo/odoo#70131
X-original-commit: 36582d08dee3688ea6e839bccfeaf8877e812122
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>
Make translation work for "Visitor" that was appearing in livechat
session to the visitor.
opw-2504461
closesodoo/odoo#70175
X-original-commit: 3b199007bd5a472d57f823a63b2b77841b14c7fc
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
It was the last remaining usage of the deprecated `_updateAfter` which is
therefore removed too.
Part of task-2258617
closesodoo/odoo#70170
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
When retreiving the list of badge owners in `_get_owners_info()`,
we should apply `res.users` ir rules to be sure to respect multi-company
rules.
upg-7081
closesodoo/odoo#70182
X-original-commit: d75deff4791702e1f085b2b16247d7f7c5335720
Signed-off-by: Christophe Simonis <chs@odoo.com>
Make translation works for "Website Visitor" that was appearing when a
logged-out user open a livechat session.
note: list comprehension has to be removed since translation only search
language in direct calling method closure.
opw-2504461
closesodoo/odoo#70146
X-original-commit: 7d28f32d9be1590764883f4621df04e04c4e1f12
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When closing a POS session, if there was no sale, the journal entries of
cash in/out will not be posted.
To reproduce the error:
(Need account_accountant)
1. In Point of Sale, open Shop's settings:
- Enable "Advanced Cash Control"
2. Start a new session:
- Open POS
- Close, Confirm
3. Close session
4. Click on "End of Session"
5. Add a "Cash In/out"
- +$10
6. Set Closing Cash
7. Close Session & Post Entries
8. Accounting > Cash
Error: The $10 line is present but its status is "New". It should be
"Processing".
Since there was no sale during the POS session, the module ignores all
the accounting part. When the session is closed, the accounting part is
ignored because there were no sales. As a result, it does not post the
cash in and out.
OPW-2456395
closesodoo/odoo#70160
X-original-commit: 985f1bf5b187513f71e65ab7d2b68e25ff1bfdf1
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Can be simplified a bit by using the newer features of
`tools.file_open()` and `tools.file_path()`.
Let's do it since the PR is touching these lines anyway
for the change of resource paths.
closesodoo/odoo#69614
Related: odoo/enterprise#17855
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Turn off calendar.attendees notification during synced_events creation
to improve performances. The calendar notification are only computed
once after all the synced events have been created.
Add a flag in google_calendar.js to avoid retriggering synchronization
while navigating the calendar view if the past synchronization is still
pending.
opw: 2450259 + fixes/adaptations to 14.3 branch
FW of https://github.com/odoo/odoo/pull/69619closesodoo/odoo#70035
X-original-commit: 28ccb2b88a7793058c81aabffb43071165886f40
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Arnaud Joset <arj-odoo@users.noreply.github.com>
Give a coherent group as otherwise we could have access errors. Simple
case: an Admin Rights user goes into a mail message form which is only
available in debug mode which sets `group.no_one` into such user. This
model is only readeable by `base.group_sytem` so an AccessError will
raise.
closesodoo/odoo#70119
X-original-commit: 8930e08213d0b6805e6fc91fa07561107ef43acc
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Some features of the PDF.js library doesn't work in the
webview of the mobile apps.
Initially 'window.print' is defined as an empty function in
webviews unlike browsers where it is already ready.
After that, PDF.js needs to monkey patch 'window.print' and
saves a reference to the original definition, which is not
yet fulfilled in by the mobile app (Java part).
So the print of PDF.js doesn't work in webviews and end
users will need to download the file before printing it.
Regarding the Download button, the 'download' attribute is
not supported by the webview as you can see in:
https://bugs.chromium.org/p/chromium/issues/detail?id=432414
As there's many ways to download a file in Odoo it's not
a big deal to simply hide it in PDF.js.
Because it's quite complicated to fix this, we decided
to hide the features that don't work (Download / Print)
or don't make sense (Open file).
Note that a refactoring is already in progress in order to
avoid to patch this library in master.
closesodoo/odoo#70110
Task-id: 2200168
X-original-commit: 39225827035efe11cdc90b2a7f1ae1f24a54b136
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: rfr-odoo <rfr-odoo@users.noreply.github.com>
Raphael Collet