Before this commit, owl was in the linter's accepted global variables.
This allowed direct access to owl global object.
For instance, to use xml from owl, you could do :
`const { xml } = owl;`
or you could use it directly:
`owl.xml`
Now, owl is not accepted on linter's global variables anymore, so to
import xml, now you need to use a proper import:
`import { xml } from "@odoo/owl";`
task-id 3498859
closesodoo/odoo#137517
Related: odoo/enterprise#48364
Related: odoo/design-themes#709
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
This commit replaces some odoo classes by native ones. They are simple
classes with no big extensions or not at all.
task 3439226
closesodoo/odoo#137116
Related: odoo/enterprise#48154
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
Several reports don't include product packing info on them. This is
useful for customers to see that what they bought matches what they
expected and for pickers who need to know which product packaging they
should be selecting from stock. Reports this was added to are:
- Sales orders,
- purchase orders (including RFQs),
- picking operations,
- delivery slips.
Note that we purposely exclude backordered moves since they weren't
deemed to be necessary at the time this feature was created.
Also includes light refactoring to remove repeated code for conversion
of product qty to packaging qty and to make it easier to do this
conversion in the future (i.e. can pass product.packaging without
original record that it was assigned to)
Task id 2927379
closesodoo/odoo#96858
Signed-off-by: Steve Van Essche <svs@odoo.com>
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>
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>
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>
This commit removes a loophole in the evalContext used in form,
list and kanban views to evaluate python expressions (modifiers,
domains and contexts). Before this commit, the evalContext was a
mix of different things:
- keys of the current context (which also contained keys from the
user context);
- a key for each field in the view (allowing to use field values);
- a "parent" key in the case of x2many records (allowing to go up
to the parent record values).
- "active_id", "active_ids", "active_model", "current_company_id".
All those keys were mixed in the evalContext, and they could
obviously conflict (e.g. if there was in the context a key which
was also the name of a field).
Even though the evalContext didn't contain an explicit "context"
key, expressions like `context.get("x")` worked. This was because
the python evaluator automatically adds the whole evalContext as
value for the "context" key if this one doesn't exist. This allowed
people to also access field values with `context.get("fieldName")`
and thus bypassing the view validation, which ensures that
everything used in those expressions is either a py builtin
supported by pyjs, a field name which is in the view or some other
whitelisted keys ("uid", "allowed_company_ids"...). Fun fact:
people did it, in a form view that is used on two different models
(product.product and product.template).
With this commit, the context (and user context) keys are no longer
spread into the evalContext. Instead, a "context" key is added.
Two special user context keys can still be accessed directly though,
without doing `context.get("...")`: "uid" and "allowed_company_ids".
The reason why we keep them is simple: those were the two only keys
that could be used directly as they were whitelisted by the view
validation. The client also evaluates domains and contexts coming
from actions and from search view filters. In those cases, the
evalContext is simply the context, and those two keys are widely
used. So it's easier if we know that, e.g. "uid" can be always
directly accessed, whether we're in an action domain, in a search
view or in a form/list/kanban view.
To summarize, accessing a context key must always be done through
`context.get("...")` except for "uid" and "allowed_company_ids",
which can still be accessed directly. This doesn't change from
before. What changes is that a record field can no longer be
accessed with `context.get("...")` (which kind of allowed to bypass
the view validation).
closesodoo/odoo#135782
Related: odoo/enterprise#47522
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
cherry-pick of a4904fb4889c16322494981f5a1be586683704bd
Steps to reproduce the bug:
- Create a storable product “P1”
- costing method: avco
- Create a PO:
- Add the product “P1”:
- Line 1: Qty= 10, price= $50
- Line 2: Qty=1, price= $10
- Confirm the PO and receive the product
- Go to purchase → Reporting → Purchase Analysis
Problem:
The average price is incorrect, the current calculation is:
(50 + 10) / 2 = 30
The average should take into account the quantities purchased in each
line, And not simply the number of line, so the correct calculation
should be:
((10 * 50) + (10 * 1)) / 11 = 46.36
The SQL query is correct, it is when applying the read_group that the
calculation is incorrect, we should override it to make a personalized
calculation of the average.
opw-3136406
closesodoo/odoo#136097
X-original-commit: cd84549a3e5ea09d230dc1d02e05456a2372fd34
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Steps to reproduce
==================
- Use a mobile viewport
- Create a quotation
- Add an order line
- Set a packaging
-> The Packaging Quantity field is missing
The same happens on purchase orders
---
opw-3504829
closesodoo/odoo#136213
X-original-commit: c5d665cc2b43a0040c3f5644265e74048c3d5ded
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
In this commit
==============
- Added the discount fields to the vendor pricelist and PO line models,
making them optional and hidden.
- Implemented automatic filling of the discount field on the PO line when
the unit price is sourced from the vendor pricelist.
- Implemented a mechanism to automatically populate the discount field on the
PO line when the unit price is fetched from the vendor pricelist.
- Modified the pricing logic to ensure the discount is applied to the
tax-excluded price.
- PO confirmation process to check if a pricelist already
exists for the vendor. If not, a new pricelist line is created, including the
discount if it is present.
task - 3380306
closesodoo/odoo#126804
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Only duplicate emails used to be checked when sending a mass mail.
However it is possible (e.g. using templates) to send a mass mail
to the same person containing different information.
The existing functions to allow models to specify emails
processed in the past by some other means are kept.
A new check is added in the processing that checks the full contents
of the message, subject and attachment ids.
The strings are not hashed as most situations are:
- Sending the exact same mail to everyone
-> Only need to check against one message
-> Same complexity as hashing
- Sending all different emails
-> Checking inequality of str is usually very fast
For attachments, as we cannot compare them easily.
They are ignored for the purpose of equating emails
whenever there are the same number of attachments
in the email values as there are on the composer.
This is because each email should receive its own copy
of the composer attachments. If they have a different
number of attachments, they were generated dynamically
through reports and we assume they are all different.
We can thus remove the 'document based' information
as it is implicitly infered from this check.
-------------------------
Test utils are also updated for two purposes:
1. Add optional body and attachment_name discriminents
assertMailMail assumed all emails could at least be
differentiated by subject. Our test breaks that
assumption, so we use body and attachment to find the
best-fitting email based on the data passed in.
2. Check email_formatted on recipients
When using assertMailMailWEmails, we first find the
email using the non-formatted email of the recipient.
This does not match assertSentMail which checks against
the raw email_to value, which would often be formatted.
Task-2826811
closesodoo/odoo#99541
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
before this commit, purchase_enterprise module is
not adding any functionality to the system, other
than adding few demo data records and passing a
context to an existing action.
initially this module is added to bring the
dashaboard functionality to the purchase app,
but with the introduction of the spread sheet
app, the added dashboard is removed from
the purchase_enterprise app in this
commit: https://github.com/odoo/enterprise/commit/61c8314728fc99dd8c7deb3c55d15e30b4844e18
after this commit, this demo data and context
is moved to the purchase app and remove the
purchase_enterprise app.
closesodoo/odoo#132475
Related: odoo/enterprise#45986
Related: odoo/upgrade#5064
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Commit 72a17bafba6e7 force the PO `date_order` to be >= at ` today() to
ensure the select_seller method take the right seller price. This
introduces an error in the MPS module that may need to create PO in the
past.
Instead, this commit patch the call to `_select_seller` to take at least
`today()`
closesodoo/odoo#134217
Opw: 3167094
X-original-commit: a9cbd2a2ae2e21f1ba14379aecd908c44497b8ab
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
As tempusdominus relies on jQuery, we have written our own date(time)
picker in owl. This commit converts the remaining uses of the
tempusdominus date(time) picker and replaces them by our own.
closesodoo/odoo#133349
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Minor cleanup after odoo/odoo#104741 thanks to edge-cases and the fun
complexity of logistics code. Fixes include:
- removing some readonly=False that were added on computed/stored fields
that already have an inverse func or were already not readonly (i.e.
redundant => cleanup)
- fixed visibility of qty to prod in subcontractor portal view of a MO
(i.e. yay they know how much they're supposed to make again)
- remove unused imports
- adding back in readonly functionality of default dest of repair
operation type (and removing the now useless field override that used
to add in the readonly functionality)
- adding back in the `_set_product_qty` inverse function since it was
probably removed by mistake (and is still important to have)
unrelated to viewpocolypse change, also fixed:
- mobile view of PO was for some reason allowing products to be changed
in already confirmed/done POs, which could lead to some inconsistent
data => made this consistent with existing desktop view behavior
closesodoo/odoo#133502
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
This commit removes almost all exports of the module services/core.js
(only the bus is left) and adapts the module that imported it.
task 3439226
Part-of: odoo/odoo#133153
Up to v11 it was possible to search by purchase vendor reference when
we're using the auto-complete function in a vendor bill. With the
refactor of this functionality, this useful feature was lost.
opw:3387397
closesodoo/odoo#132896
X-original-commit: 0e7257306bb3dc8258b9642a53e2eefe7493c487
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
These changes are made as a result of simplifying attrs and 'states' in
views. However, they should have remained in a separate commit. When
applying the script making the xml changes (used later for the migration
script), the script checked the definition of the python fields in order
to convert the information into a python expression. Therefore, this
commit is not applied when the script is applied to xml changes.
During this attribute deletion pre-existing errors were found. Part of
the code was using the boolean values of 'states' and another part of
the code was not. The behavior could therefore be different (in cases
where readonly on the field had the same value as the ballan in
'states').
Following the deletion of 'states' and without the application of the
view migration, the js tests (tower) were no longer functional. Tests
using the Form view suffered the same effect. There are few tests that
had to be adapted, including two tests in business accounting (updated
by the accounting team). A test for column_invisible did not work. Test
checking if the test system triggers an error if we try to write on an
invisible field. It turns out that Form was testing on the value of
invisible but not taking into account if the column was invisible. The
test system fix is applied separately because there were a lot of tests
that were incorrect.
Part-of: odoo/odoo#104741
Goal:
* Simplified modifiers to only have one way to define modifiers;
* Remove states attributes on python field;
* Use python expression in view `required`, `readonly`, `invisible`;
* More accurate validation of xml views.
This commit change the syntax to python expression. The next commit
will update/convert all xml views.
Before this commit:
* the `required`, `readonly` and `invisible` attributes can only have
values of `True`, `False`, 1, 0 or a python expression to use the
context;
* the `attrs` attribute define a dict. The key of this dict was
`required`, `readonly` and `invisible` and the values are the domain or
a string representing a domain to be evaluate as python expression.
This python expressions was evaluate by the javascript with view fields
and other contextual values as: context, uid, parent, active_id,
active_ids, active_model, allowed_company_ids, current_company_id.
* the `states` attribute in the view was a comma separated list of the
state. This list was combined with the `invisible` attribute;
* the `invisible` attribute on python field is used as default value;
* the `states` attribute on python field was dictionnary with state as
key and list of tuple. This structure was combined with `readonly` view
attribute.
* After combining, the resulting domains of the different attributes
`required`, `readonly` and `invisible` are evaluated with the values of
the fields. The `invisible` attributes is splitted into two use:
`invisible` and `column_invisible`.
After this commit:
* The attributes `required`, `readonly`, `invisible` and
`column_invisible` define python expression. This python expressions
are evaluate by the javascript with view fields and other contextual
values as: context, uid, parent, active_id, active_ids, active_model,
allowed_company_ids, current_company_id.
The domains can contains contextual value and will be evaluate by the
javascript.
```xml
<field name="field_a" readonly="not context.get('show_a')" attrs="{'readonly': [('field_b', '!=', False), ('field_c', '=', parent.c)]}"/>
<field name="field_b" states="draft"/>
```
will be replaced by
```xml
<field name="field_a" readonly="not context.get('show_a') or field_b and field_c == parent.c"/>
<field name="field_b" invisible="state != 'draft'"/>
```
Some inherited views will be modified differently in order to maintain
the previous behavior:
```xml
<field name="field_a" readonly="not context.get('show_a')" attrs="{'invisible': [('field_b', '!=', False)]}">
```
```xml
<field name="field_a" position="attributes">
<attribute name="attrs">{'readonly': [('field_c', '=', False)], 'invisible': [('field_d', '!=', '3')]}<attribute>
</field>
```
will be replaced by
```xml
<field name="field_a" readonly="not context.get('show_a')" invisible="field_b">
```
```xml
<field name="field_a" position="attributes">
<attribute name="readonly" add="(not field_c)" separator=" or "/>
<attribute name="invisible">field_d != 3<attribute>
</field>
```
Validation:
A stricter control is made on the level of the attributes (modifiers)
and the fields necessary for these. The use of the previous attributes
'attr' and 'states' triggers an error (these no longer exist after the
application of the migration script)
task-2495504
Part-of: odoo/odoo#104741
Before [1] the demo user only has the basic right. Now it has
the administrator rights and it prevent an easy testing for user
flow.
The demo and admin users get their rights from the common
template with administrator right everywhere. Since it's a
data, we could just remove the administrator level and set
the user level in the demo data.
[1] commit 121cd0d608
X-original-commit: 7b7fdf5d4eb892bfd3c2fdb575264025dca21ca5
Part-of: odoo/odoo#131707
As all the templates are now imported in the owl app, there is not need
anymore to specify the owl="1" attribute in the templates.
Part of task~3443861
Part-of: odoo/odoo#130467
In this commit, _t import from import { _t } from
"@web/legacy/js/services/core" and from
web/static/src/legacy/js/core/translation.js are replaced by
@web/core/l10n/translation.js.
task-3292454
closesodoo/odoo#130865
Related: odoo/enterprise#45270
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
This commit fixes a really old grammar error in the help message of the
message_needaction_counter field.
Before this commit: “Number of messages which requires an action”
After: “Number of messages requiring action”
The subject of “require” is “messages”, which is third-person plural, so
it can't take the -s suffix.
closesodoo/odoo#129468
X-original-commit: 0d10cfeaa56d5df23df05f436d353978043f4a71
Related: odoo/enterprise#44509
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
The _xmlid_lookup cache contains the id of the ir.model.data with is
unused, making cache pupulation and usage more complex than needed.
Removing this id in prevision of the next commit
Part-of: odoo/odoo#129029
Allow sharing records between company
* accounts
* taxes
* fiscal positions
* products
* ...and some related models
These records can be read and used in children companies.
This can be used to
* have different branding for different businesses
* allow more complex security rules
* consolidate branches differently
* manage different tax reports with different tax ids in the same
country
task-3371677
closesodoo/odoo#125642
Related: odoo/enterprise#43215
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
before this commit, on clicking the purchase kanban view,
it allows to quick create from the kanban view,
and the value entered is going to name of purchase order
after this commit, quick create is disabled
closesodoo/odoo#129028
X-original-commit: 9c9433f3ebd65cfee8eceb751481116488ced3fc
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
This commit makes hotkey uses more coherent throughout the entire
codebase by setting alt+q as main shortcurt for confirm and default
actions and alt+x for cancel actions.
task-3370463
closesodoo/odoo#127469
Related: odoo/enterprise#43694
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
The goal of this commit is to prepare ground to remove
lazytranslate function _lt() and keep only _t()
for a better understanding of the use of the translation function.
In this commit,
the translate function _t() has been updated to return the translation
if they are loaded. If not, it throws an error.
the lazytranslate function _lt() returns _t() function.
Corollaries :
Steps in test tours are now a function that returns an array of steps
to avoid any interpolation of _t in this ones before translations has
been loaded.
Example :
registry.category("web_tour.tours").add("example", {
test: true,
steps: () => [
{...},
{...},
],
});
task-3292454
closesodoo/odoo#124157
Related: odoo/enterprise#43153
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Steps to reproduce the bug:
- Connect with a company using USD currency.
- Create a storable product "P1":
- Cost: $100
- Create a Purchase order:
- Add 1 unit of "P1"
- Currency: USD
- Create another Purchase order:
- Add 1 unit of "P1"
- Currency: EUR
- Go to the purchase analysis and select the list view.
Problem:
The purchase order in EUR is converted into the current company
currency, but the Euro currency symbol is used instead of the dollar
symbol
opw-3354221
opw-3348265
closesodoo/odoo#128479
X-original-commit: ad05cea889cb632946abceeb5c0db36b73a18afc
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Receiving a kit's component will fail in AVCO + multi-uom
To reproduce:
1. Create a product category PC
- Costing Method: AVCO
2. Create two products P_compo, P_kit
- P_kit:
- In Units
- P_compo:
- In L
- Storable
- Category PC
3. Create a BoM
- Product: P_kit
- Type: Kit
- Components: 1 x P_compo
4. Create and confirm a PO with 1 x P_kit
5. Process the receipt
Error: When validating the receipt, a user error is displayed: "The
unit of measure L defined on the order line doesn't belong to the
same category [...]"
When processing the SM, we create the in-SVL. To do so, at some
point, we need the unit price of the SM, and here is where the error
comes from:
https://github.com/odoo/odoo/blob/708c3d063482e365e49a04f633c83e90e6fa4356/addons/purchase_stock/models/stock_move.py#L39
`self.product_id` is P_component, but `line.product_id` is P_kit,
hence the error with the UoM1
And there will be some similar errors with the `if` block, L40 (we
compare some SM quantities and some POL quantities: we are mixing
components and kit)
For now, in case of a kit, we will always use the `else` block (i.e.,
the unit price of the POL). This will be improved in master
OPW-3357685
closesodoo/odoo#128386
X-original-commit: 3a81eb79cad7f25843315e39da421efa2c34aaf1
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Before the fix, when trying to autocomplete a bill with a PO using India localization, the invoice lines would not get the same currency as the autocompleted PO.
This is because with India localization, the journal_id gets updated at the same time of the currency_id, which recomputes and erases the currency set just before.
I propose to update the currency at the end to avoid all sort of recomputation it could be subject to.
opw-3374634
closesodoo/odoo#127657
X-original-commit: 7f37e523cffbe3d7d98fd7457b30e2fb93f453d5
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Benjamin Boullé (bebo) <bebo@odoo.com>
The previous commit introduced an optimization to reduce the number of
queries and fields fetched when we call `name_search`. But it works much
better when the dependencies of `display_name` contain field names used
in the calculation (on the same record/model).
Then, to improve the performance and the cache coherency, add `depends`
and `depends_context` depending on the custom `_compute_display_name`.
Add only the first level of dependencies (never traverse relational
field) because only these have a positive impact on the previous
optimization and the cost is very low (see `modified`).
About `depends_context`, we don't include `lang` because (when `_` is
used by example) it is unlikely to get the same display_name in the same
request with two different lang.
closesodoo/odoo#122085
Related: odoo/documentation#4639
Related: odoo/enterprise#42599
Related: odoo/upgrade#4780
Signed-off-by: Raphael Collet <rco@odoo.com>
Rationale
=========
Since v8, the `display_name` field is present on all models. By default,
`display_name` uses `name_get` which has pretty much the same purpose
(return record name used by the web client). Gradually, many (backend)
developers (and the ORM: https://github.com/odoo/odoo/commit/6da1c3ac4c036eac289597602976538e243cb939)
started using `display_name` (more convenient than
`record.name_get()[0][1]`) but it still had the `name_get` override.
It becomes more complex than necessary and poeple start to misunderstand
the two (and sometimes override both, leading to inconstiencies between
`display_name`/`name_get`).
To simplify the ORM and the API, we decided to keep only one of them,
the `display_name` field:
- It is much more convenient from a backend point of view
(`record.name_get()[0][1]` vs `record.display_name`)
- It is cached during the same transaction (and invalidated if
its dependencies change)
- It can be overridden like any other compute field (override
`_compute_display_name` with any extra dependencies)
- `name_get` is replaced by `read(['display_name'])`
(API perceptive), which can actually be more efficient
(if `display_name`'s depends are correct, the ORM will only fetch the
fields it needs instead of every prefetchable field)
Changes
=======
- Deprecates `name_get` for the v17 and based the method on
`display_name` (the opposite of before)
- Converts all usage of `name_get`
- Overrides of `name_get` are now overrides of `_compute_display_name`
- For `res.partner`, rename the field store `display_name` into
`complete_name` because `display_name` context-dependent and it makes
no sense to have a compute store that is context-dependent.
- Previously, it was possible to return multiple names for the same
record with `name_get`, but it was tricky and most of the usage of
this `name_get` didn't take this into account. The only example of
this is the `name_get` of `product.product`
(now use `", ".join(<names>)`).
Part-of: odoo/odoo#122085
Steps to reproduce
==================
- Go to Accounting > Vendor Bills
- Create a new record
- Click on the Auto-Complete field > Search more
- In the search bar, search for a reference
-> str is not a function
Cause of the issue
==================
The search filter is declared as such:
```xml
<
field name="name"
string="Reference"
filter_domain="['|', ('name','ilike',self), ('reference','=like',str(self)+'%')]"
/>
```
This domain is evaluated in javascript by basic python interpreter.
Going from 15 to 16, it has been rewritten. The str function isn't
present anymore in `py_builtin.js`.
Solution
========
Since this is the last remaining usage of this function and `self` is
already a string, we can simply replace `str(self)` by `self`
opw-3383708
closesodoo/odoo#126593
X-original-commit: 4485d1ca6d1dfe33f4fca6d2cc140296ce4058a5
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Currently, the Purchase tab is visible to every user in Product form view.
In this commit, I have make Purchase tab only visible to admin access.
TaskID - 3150983
Part-of: odoo/odoo#116799
*: account, crm, crm_iap_mine, event, hr_expense, hr_holidays,
hr_recruitment, lunch, mail, mass_mailing, point_of_sale, project,
purchase, purchase_stock, sale, survey, web, website, website_blog,
website_event, website_forum, website_sale, website_slides,
test_main_flows
In odoo/odoo#111103 the tour system was rewritten. The previous tour
system used to depend on the `root.widget` js module, and this module
was an async module that indirectly depended on `session_bind` which
would load the translations, meaning that the js module definition code
of the tours would only run after the translations were loaded. This is
no longer the case with the new tour system, this means that the module
definition code is executed as soon as the dependencies of that module
are fulfilled, which is generally befoe the translations are loaded,
causing most tour tips to not be translated.
This commit adds a hacky workaround for this problem: it creates a new
module that has a default export which is a promise, and has a legacy
alias, this creates an async module that waits for the translations to
be loaded. This module is then imported for its side-effect in all
onboarding tours, causing them to be translated correctly once again.
This commit also needs to convert the steps key in the tours internal
registry to a getter. In previous versions, the steps were directly
added as is to the internal state of the tour service, but since
odoo/odoo#122834 the steps are now mapped, and without a getter, any
edits to the steps occurring after registration will not be taken into
account. This causes issues in some modules that change original
behaviour of other modules (eg accounting makes invoices into a menu in
the accounting app instead of a top-level app in the home menu) as they
need to edit the steps of existing tours to make them work.
In a separate PR, we will implement a more proper fix by changing the
API of the tour manager so that we no longer need this workaround.
closesodoo/odoo#125284
X-original-commit: d130699ba82dc9919c9116f4b64a5e461ebb6319
Related: odoo/enterprise#42655
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
when the user removes the company_id and add a line in the purchase order
then the issue is generated.
Steps to reproduce:
- Create a new purchase order.
- Remove the company_id in the Purchase order.
- Now add a line in PO. Select a product with the consumable product type.
- Traceback will be generated.
Applying these changes will resolve this issue.
Sentry-4215579151
closesodoo/odoo#124035
X-original-commit: 75edec6f73b70c4b9b86ad67bc838f468c2574b7
Signed-off-by: Tiffany Chang <tic@odoo.com>
AssertionError: convert amount from unknown date
The problem occurred when removing the default value of 'Order Deadline' and
selecting a product before saving the record.
After applying this commit will fix this issue.
sentry-4175826548
closesodoo/odoo#123224
X-original-commit: 0314edf028acf7365804028f0f3ef6123b6ae321
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Failing use case: While having purchase_stock installed, create and confirm a request for quotation, received some products but no bill for it. Now select the PO is the list, click on 'Action > Accrued Expense Entry'. Make sure the wizard will effectively create an accrued expense entry (it should be the case if you have some product received and not billed).
Upon confirmation of the wizard, the system will recompute the received quantity on the original PO, logging notes that pollutes, confuses and spams its followers.
The reason is that we use a new record to compute the difference between the received and billed quantities at a given date in the past, and even if track_qty_received is called on a newid, it will find back the original PO where doing line.order_id.
The solution is to check in the context if we're in such use case before logging, because we know that calling the accrued expense entry wizard aims not to change the received quantity in any wase
closesodoo/odoo#122720
X-original-commit: b31f1ad789e92c84f85654b67e6730e413f0e06b
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
qty_received_method is not recomputed if the product type change, and can lead to issues on existing purchases when trying to generate a Vendor Bill.
# HOW TO REPRODUCE:
- Create product P, type: Service, Control Policy: 'On Received Qty'
- Create PO for 1 unit of P (do not confirm)
- Update type of P to Storable
- Confirm PO, Receive Products
=> Qty Received is 0, not able to generate Bill
closesodoo/odoo#122409
X-original-commit: fcc1e8e325e6d9f4782b2f82769e1200b7b9a0c3
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Fesquet David (dafr) <dafr@odoo.com>
Steps to reproduce:
1. Create a bill from document,
2. Fill in PO in auto complete, confirm, check the bills list.
3. The source document is not populated in the list.
What is the current behavior that you observe?
The source document is in the log, but does not show up in the dashboard.
What would be your expected behavior in this case?
The PO should show up in the source document in the list
OPW-3284992
closesodoo/odoo#122280
X-original-commit: e3289decaf95034f0ebba307350d3913a604eb8d
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Jorge Pinna Puissant