Task 2092079
Accounting firms that want to give access to their customers avoiding
mistakes and risks will love this profile that can't do anything
wrong... Maybe as well as companies auditors..?
closesodoo/odoo#39860
Related: odoo/enterprise#6576
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
- Create some stock in WH/Stock for product A
- Create some stock in WH/Stock/Shelf 1 for product B
- Create a Repair Order for Product A in WH/Stock
- Add a line in Parts with B, leave the location to WH/Stock
- Process the order until the end
Negative quant is created in WH/Stock for B instead of using the
quantity in WH/Stock/Shelf 1.
We do a best effort in order to reserve the quantity in the
sub-locations.
opw-2177352
closesodoo/odoo#43716
X-original-commit: 2158f07cb2d32480f0db2a8e82aaea73ac266271
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Correct the rounding of several currencies which should be 0.001.
opw-2172122
closesodoo/odoo#43715
X-original-commit: 71f01060ea359814ffdb9ef506a01a2543dfc9ea
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create a FIFO product, Automated
- Make some stock
- Create a SO, add the product
- On the SO, add an analytic account
- Validate the picking, create the invoice
=> the analytic info are propagated to the invoice, as expected
- Validate the invoice
The analytic info is propagated on the COGS entries, in particular the
the output account, which is incorrect.
opw-2008567
closesodoo/odoo#43690
X-original-commit: e831868fe648d3a3a4981a1cf9c135e4e4102279
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
`AttributeError: 'tuple' object has no attribute 'startswith'`
When given headers that are tuples. They are expected to be string, as per [1].
The issue was introduced with [2], indeed the code was moved from inside a dict
where `,` was the usual dict separator to outside of a dict where `,` at the end
made them tuples.
To reproduce the issue, run the `test_mail` suite after having
`website_mail_channel` installed.
Issue highlighted as part of task-2178641
[1] https://docs.python.org/3/library/email.policy.html#email.policy.Policy.header_store_parse
[2] cae1c3977fclosesodoo/odoo#43698
X-original-commit: 7e5a7245e86d8a3bcdab83c740cb4d188d009a40
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This is the second move to replace Filipino by Tagalog language
Using Filipino (code fil_PH) is problematic as conflicts with Finnish
(code fi_FI) and users having their browser in Finnish were redirected
to the Filipino version of the website (cf discussion at opw-2172710).
This problem was also raised in other softwares like in the below
discssion in Mozilla L10N groups
https://groups.google.com/forum/#!topic/mozilla.dev.l10n/TW2qYyDDNoE
Quoting the discussion in above thread:
> Filipino is the national language of the Philippines, but it is
> commonly referred to (and registered as) Tagalog, since most of the
> terms therein were derived from it (Tagalog).
This commit targets the master (future 14.0 as of today), adds a new
Tagalog language and removes the Filipino.
In 12.0, only the Tagalog was added.
As fil_PH is only translated on odoo-com project but remains at 0% in
other Transifex project, it is assumed the language switch won't
impact too many people.
closesodoo/odoo#43634
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
This commit fix most `t-set` errors that either led to:
1. unwanted text to be considered as translatable.
eg: `<t t-set="classes">text-left bg-100 p4</t>` would create an
`ir.translation`.
2. text that should be translatable were not.
eg: `<t t-set="text" t-value="'Both'"/>` would not create an
`ir.translation` while it should.
If a text should be translatable, it should never be inside a `t-value`:
- `<t t-set="text">Both</t>`
If a text should not be translatable, it sould either be inside `t-value`,
`t-valuef` or the `<t>` tag should have `t-translation="off"`:
- `<t t-set="classes" t-translation="off">text-left bg-100 p4</t>`
- `<t t-set="classes" t-valuef="text-left bg-100 p4"/>`
- `<t t-set="classes" t-value="'text-left bg-100 p4'"/>`
https://github.com/odoo/odoo/pull/43660https://github.com/odoo/enterprise/pull/7839https://github.com/odoo/design-themes/pull/203closesodoo/odoo#43660
Related: odoo/enterprise#7839
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Purpose of this commit is to improve model of followers, notably management
code and its use in routes. Indeed it is quite an old model and code had
to be cleaned a bit to improve code readability and maintenance.
In this commit we
* remove unnecessary code examples in gamification about followers: using
that model as example of code for goals is probably not a good idea as it
is technical;
* rewrite routes called by JS are simplified to better match JS
implementation;
* introduce computed fields to fetch related partner or channel name,
email (partner only) and active status;
LINKS
Task 1933771
Task 2078313
closesodoo/odoo#39808
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Remy Voet <ryv@odoo.com>
Co-authored-by: jgi-odoo <jgi@odoo.com>
Co-authored-by: Xavier-Do <xdo@odoo.com>
Purpose of this commit is to always call followers API with explicit parameters
about existing followers management (check_existing and existing_policy
parameters). It makes code easier to read and maintain.
LINKS
Task 1933771
Task 2078313
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Co-Authored-By: Rémy Voet <ryv@odoo.com>
The `ref` field on `account.move` is not required and can yield a falsy
value. This produces a TypeError while doing the comparison in sorted().
closes#42434closesodoo/odoo#43674
X-original-commit: 3bb4c0c99b29bb85916af95361b86e9dc3287546
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
PURPOSE
mass_mailing and mass_mailing_sms activities are grouped as 1 item in the systray due to them using the same model name (sms inherits and distinguishes itself with a different field.Selection value). This is confusing behavior because they are 2 separate modules and the default icon ends up mismatching the sms-related activities.
SPECIFICATIONS
Split mass_mailing and mass_mailing_sms activities into 2 separate items in systray. Additionally, make it so when mass_mailing and mass_mailing_sms activities are clicked on, only the relevant activities are shown to prevent confusion. In order to only show relevant activities, an optional "domain" check is needed in __systray_activity_menu.js__ for when overriding _systray_get_activities_ methods provide a domain to apply.
Task: 2169498
PR #43272
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Previously, mapped was following a very naive approach, which was simply
calling the field name passed as input for every record in a recordset,
sequentially.
The problem with this approach is that we will potentially recompute the
same fields multiple times for differents records, when this could be
done once per field for ALL records, and store this value in cache for
further access.
Another potential problem is that we don't take advantage of the ORM's
prefetching to fetch all the records that are not in cache at once,
instead of doing the same query for every record in the recordset.
Yet another problem is the conversion of each cache value to a record
format and then combining all of the individual records into a single
recordset, which, depending on the size of the recordset, can take an
unbelievable amount of CPU time.
With this new implementation of `mapped()` we take care of all of these
problems:
This is done by first delegating `mapped()` from the model to the field,
this mapped takes a recordset as input and it will try to batch compute
and prefetch as much as possible for the entire recordset, but it will
not keep these values for the actual output, it just stores everything
in cache and then at the end, retrieves everything from the cache to
guarantee the same order.
After the mapped, the conversion from cache format to record format is
delegated to the new `convert_to_record_multi` which will fetch all the
ids and then perform a single browse to encapsulate all of the records
into a single recordset with the least amount of overhead possible.
Part of Task 2170344
closesodoo/odoo#42611
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Restrict the displayed activities when clicking on "Email Marketing"
and "SMS Marketing" modules in the activity systray. Due to their
activities being linked to the same model, we need to distinguish which
activities belong to which module based on their assigned mailing_type
value. Without this domain restriction, users can still filter based on
mailing_type, but it is much less intuitive this way due to them being
separate apps.
Task: 2169498
Addition of this optional 'domain' value for systray activity related
lines allows the restriction of which activities will be included in
the view opened when the line is clicked on.
One use case is when a model is split between 2 systray activity lines.
In this case we most likely do not want the same activities of the
model to show up when we click on either line. For example, say we
have 2 modules using the same model, but the module instances of that
model are distingushed by a field.Selection value. Then we would only
want to show the activities related to each module when we click on
their appropriate systray activity lines based on that field.Selection
value.
Task: 2169498
Due to 'mass_mailing_sms' inheriting mailing.mailing from
'mass_mailing', activities for these two modules would show up as one
"Mass Mailing" line in the systray. This commit adds additional logic
to remove this "Mass Mailing" line and replace it with 2 lines: "Email
Marketing" and "SMS Marketing" with their appropriately matching module
icon. For consistency, when only the 'mass_mailing' module is installed,
it will still display "Email Marketing".
Task: 2169498
When a payment line is created, and then the order is reloaded, by the
synchronization feature for example, the name displayed on the payment
line is empty.
This happens because the field name is not saved on the server, so
instead of using it, we are directly taking the name of the payment
method linked to the payment line.
closesodoo/odoo#43615
X-original-commit: ae4322cd81814cf4cdc462ff9d271f83ce2870c4
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
This controller is no more used, probably used in the past with calendar invitation.
closesodoo/odoo#43657
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Steps to reproduce:
- Install website_sale_wishlist,stock,sale_management,contacts
- General Settings>Sales>Multiple Sales Prices per Product
- Create or edit a product, assign 2 different prices in pricelists A and B
- Publish it to the website
- If your user is Mitchell Admin, go to its related res.partner, Sales &
Purchases tab/Pricelist, choose pricelist B
- Create a public user and assign it pricelist A
- Go to the website/shop
- Reach out the product and add to the wishlist
When the current user is internal the product page will display price of B,
but if you add the product to the wishlist, whishlist displays public price
Same for the portal user.
This happend because to avoid returning 500 when the product is
unpublished c93f371d67 the product is
filtered using sudo() but the recordset is also returned with the sudo
environment. Using it just to filter solve the issue
opw-2166484
closesodoo/odoo#43646
X-original-commit: 4335f9dbf21447f717874b2d65552dd67c634df0
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Create a new quotation, add a row with product Customizable desk.
The product configurator dialog opens. Click on 'Add'. A second
dialog opens (to select optional products).
Before this commit, the second dialog was displayed behind the
first one.
This bug is present since the introduction of Owl dialogs
(34bbdd8). It is due to an override of the 'open' function that
doesn't call _super (and thus, doesn't go through the code that
makes the last opened dialog active).
closesodoo/odoo#43424
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
*sale,sale_product_configurator
Let's assume a form view containing a many2one with an onchange
that updates the value of a one2many. Do a quick create in the
many2one. While the name_create request is pending, add a row to
the one2many but do not leave it. When the name_create returns, and
the onchange has been performed, the one2many is reset, and the row
is no longer in edition (worse, it could be invalid, i.e. in a state
that the user could not have reached in a normal situation).
This commit fixes this issue by considering the whole [name_create +
onchange] operation as one. This operation is executed in the mutex
of the model, so the other request (adding a row to the one2many) is
delayed until the many2one value has been correctly set.
This fixes an issue with the sale and rental tours (on sale_order),
that had been deactivated for a while.
This commit changes ControllerAdapter to a mixin that inherits
WidgetAdapterMixin and RendererWrapper now extends ComponentWrapper.
This commit also changes PivotController base class/mixin and uses
the Odoo legacy custom_events because of the adapter.
closesodoo/odoo#43256
Related: odoo/enterprise#7744
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
This commit adds the ComponentAdapter, an Owl component meant to
be used as universal adapter for Owl components that embed Odoo
legacy widgets.
This component will be a precious tool during the transition phase
of converting our JS codebase from the legacy (widget) framework to
Owl.
The use of 'this' to call other utils adds a restriction on the
way utils are called from the outside:
utils.patch(...); // works fine
const patch = utils.patch;
patch(...); // doesn't work
PURPOSE
As Certification PDF can be called on failed user input, generate a
certification of failure in that case.
SPECIFICATIONS
In the survey_report_templates.xml, when user_input.quizz_passed is
false, a certification of failure can be generated.
This commit is actually about applying again 57fef7c11c that has been lost
while performing major cleaning in survey templates.
LINKS
PR #42811
Task ID 2148449closesodoo/odoo#43274
X-original-commit: 6206e0e6213be14a977db028b8f4dc4f755bf11c
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
1- create a group payment (10 ~ 15 invoices);
2- Open the created journal entry.
The first issue we see is that the breadcrumb is too big to the size of
the screen.
3- Open the 'Reconciled Entries'.
Before this commit, the screen was completely shifted and not visible.
This occurs also because the breadcrumb is too big.
Now, the references added to the name of the entry is limited to 50
characters.
opw-2166551
closesodoo/odoo#43644
X-original-commit: d679c75bbeaf3e41dcdb8c91996a89ea5080669f
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Bug in 13.0 regarding company_id field of partners when creating them from
their parent contact or when setting their parent.
The field 'company_id' of res.partner is set by an onchange on 'parent_id'
to that of it's parent; unfortunately the field is readonly if parent_id
is set and not set to force_save.
Furthermore, creating a child partner from the main one (in the 'Contact'
tab of the main partner form view) does not follow the same behaviour
(company_id is unset in that case, meaning that children don't have
the same company as their parent).
Since the company_id is already set by an onchange when we change 'parent_id'
and set to readonly in that case, I assume the expected behaviour is actually
that children partners should have the same company as their parent by default.
Fine tuning of 7b49f5836c
opw:2176384,2167106
closesodoo/odoo#43621
X-original-commit: 92737f21acf9b044df99e111fceffc08e05abe65
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Add documentation about the new gantt parameter, `dynamic_range`,
The parameters were added in enterprise (odoo/enterprise#7640).
Task #2168740closesodoo/odoo#43052
Related: odoo/enterprise#7640
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The discount_amount didn't consider the quantity on Sales Order Line.
e.g:
100€ | 10% discount | 8 products
--> discount_amount was 10 € instead of 80€
Fixes#43242closesodoo/odoo#43624
X-original-commit: b8a1370c7bebe71b968555a6c9e5137c4e7cda8b
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
1/ When the new database is created without demo data, the admin has a
'silhouette' as a default picture. When a new user is created without
picture given by the current user, the new user will have a 'silhouette'
as a default profile picture.
2/ web: image for fa-user-slash. This image will be used when a record is
unassigned.
3/ web, *: Change placeholder by default when record is unassigned.
We want to have a fa-user-slash icon when a record is unassigned instead
of 'placeholder.png'. A method is created in the BaseModel to have a
generic method to change easily the placeholder for other models.
4/ Adapt kanban test to keep the same behaviour. Attention the behaviour is
a bit different. Because, now the default image is given by the server to
change easily the default image when a record doesn't have an image.
Thus, we don't say if it's the default placeholder, but we can say it's
not the same image of the record (in this test, the record, it's the
partner).
5/ misc: display 'Unassigned' in the hover on kanban cards if record is unassigned
closesodoo/odoo#41356
Taskid: 2060206
Related: odoo/enterprise#7758
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Co-authored-by: jdoutreloux <jud@odoo.com>
Co-authored-by: Yannick Tivisse <yti@odoo.com>
Computing the `cache_key` turned out to be a big factor during the
lifespan of a `BaseModel.mapped` call and a lot of this time is spent
computing the same `cache_key` over and over.
These unnecessary computations can be easily reduced to a couple by
moving the `cache_key` method on the environment (instead of the field)
and by implementing a memo for that method. The rationale is that the
`cache_key` of a field does not change for a given environment.
The result of this patch is up to 50% faster `Field.__get__` which in
turn means a GLOBAL gain in performance, especially for methods /
functions that rely heavily on `__get__` such as `BaseModel.mapped`.
closesodoo/odoo#42674
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
Instead of polluting an existing environment, use the method that was
intended for changing the company `with_company` which returns a brand
new environment and leaves the existing one unchanged.
A new tax of 10% has been introduced in October 2019 in Japan.
Add this tax and relative tax group, fiscal position, etc.
Conserve the 8% tax as some sale could use it as a reduced tax rate.
closesodoo/odoo#42538closesodoo/odoo#42629
X-original-commit: 18925d7fcadac7f30f29d46f7c45e87b083e9e5e
Original-signed-off-by: Josse Colpaert <jco@openerp.com>
Signed-off-by: Josse Colpaert <jco@openerp.com>
Steps to reproduce the bug:
- Let's consider a delivery method DM with fixed price of 10€ and a margin of 20%
- Let's consider a storable product P
- Create a SO for P and get the rate (12€) but don't add it on the SO
- Confirm the SO and process the delivery
Bug:
A SO line was created for the freight cost without the margin. So it was 10€
instead of 12€.
opw:2144894
closesodoo/odoo#43279
X-original-commit: 621dac802ddddc3a4dd58f7370250386e1031598
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
- Create a new Product
- Add a BOM to this product
- Set the BOM to be a kit
- Add components to the BOM
- Create a PO for the components for a qty of 5
- Confirm the PO but don't transfer the products
- Check the phantom kits outgoing_qty and incoming_qty they will match
A Phantom Kit Products outgoing_qty and incoming_qty are identical
Closes#43447closesodoo/odoo#43584
X-original-commit: 4b2e235be6cab947ce2e0b3b17b54530f984ce72
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When writting number on the point of sale keypad, if you click on the
"+/-" button, you will get 0 (with buffer "-0"), but then you need to
backspace 2 times to remove "-".
This seems odd since this mean that:
=> "+/-" "backspace" "backspace" "5" will get 5.0 units
=> "+/-" "backspace" "backspace" "backspace" will remove line
instead of what would be expected:
=> "+/-" "backspace" "5" will get 5.0 units
=> "+/-" "backspace" "backspace" will remove the line
opw-2169157
closes#43495closesodoo/odoo#43507
X-original-commit: d3489146e9e1e20903bf8775527cb8b32a2ba383
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Before create_multi, in case of invalid syntax used in an XPath, only
the problematic record was displayed. It was not ideal for long
definition but still usable.
Since the views are created using create_multi, the whole file content
is displayed in the error traceback, making it almost impossible to
locate on files with multiple records.
closesodoo/odoo#43590
X-original-commit: 8622469e1fdd4789cc45ed52093d0f329abca14e
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
The handling of unhandledrejection in the frontend was done with
dedicated code since the crashmanager was not in the frontend. This is
the case now so that dedicated code became useless.
closesodoo/odoo#42927
Signed-off-by: fja-odoo <fja-odoo@users.noreply.github.com>
Show the Post Inventory button to manufacturing users,
also if they are not in debug mode.
task-1887035
closesodoo/odoo#43294
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
david