Every call of initialize_sys_path was adding two new hooks to the
sys.meta_path, resulting in very long loading times on databases having
a lot of modules.
For example, 2.27s instead of 752 on a database having 130 installed
modules.
References:
- odoo/odoo#45780
- odoo/odoo#45662closesodoo/odoo#53121
X-original-commit: 2444fde7f852787d87589a93c4bc385d76ff20e9
Signed-off-by: Christophe Simonis <chs@odoo.com>
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Steps to reproduce the bug:
- Let's consider a new instance with default installed language 'en_US'
- Install CRM
- Activate a second language (e.g. en_GB)
- Set that language in all users
- Inactivate default language 'en_US'
- Reset the language of your current user (no value)
- Go to contact and try to create a new one
Bug:
A traceback was raised because the lang en_US did not exist.
opw:2267711
closesodoo/odoo#53064
X-original-commit: c43647f085a7f62c9c81db6553be6a6e402943d0
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
- Create 4 products A, B, C, D
- Create a product AB, which is a kit made from A & B
- Create a product CD, which is a kit made from C & D
- Create a product ABCD, which is a kit made from AB & CD
- Create a SO with 1 unit of ABCD, validate
=> a picking with A, B, C and D is created
- Validate the picking
The delivered quantity remains zero on the SO.
This happens because we don't find any `relevant_bom`. Indeed, the
`bom_line_id` written on the stock moves correspond to products AB & CD,
but they do not correspond to ABCD.
We fall back on the 'all-or-nothing' policy.
opw-2273392
closesodoo/odoo#53091
X-original-commit: 972eab4bcdcc9ee246621a6991d064f96ccd5ccb
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- restore "solid" icon
- restore muted style when no notification
- opportunity is taken to fix off-pixel of activity menu
task-2278416
closesodoo/odoo#53094
X-original-commit: 1164b37c5fb33d124ede52356c613b7cd31ac8e1
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Usecase to reproduce:
- Create 2 table(MTO)
- Produce 1 and use BO button
Traceback due to a reference to enterprise field.
closesodoo/odoo#53077
X-original-commit: 2fffc12f8e3cdccba4b1c9820f997f4b10dac330
Related: odoo/enterprise#11191
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
When we print a ticket status with a thermal printer we need printer's device-id
But if we add manually a printer this device-id doesn't exist
So now we update de devices list with a supported = True if
printer are manually added
closesodoo/odoo#53072
X-original-commit: 89bbc555ecf520ee34a9b1292a2bdb5c937b18e2
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
[FIX] l10n_cl: format RUT/VAT as used in Chile (99999999-X)
[FIX] l10n_cl: prevent errors with domain of available documents in invoice view.
[FIX] l10n_cl: allow to select document types when partner is empty
[ADD] l10n_cl: add ILA taxes (purchase and sale) and assign account to taxes
[ADD] l10n_cl: add fiscal position exempt for purchases and sales
[IMP] l10n_cl: configure accounts used in inventory valuation
[FIX] l10n_cl prevent to put unneeded sales documents in sales journal
[FIX] l10n_cl limit revision of document types and partner constrains only for sale and purchase journals
[FIX] l10n_cl: add extra validation to know wether there is a latam_document_type_code selected
[ADD] l10n_cl: add document type '801' Orden de compra
[WIP] add tag to costo de ventas account
[FIX] l10n_cl: fiscal position templates: fix supermarket tax
[FIX] l10n_cl: change order for boletas
[WIP] l10n_cl: fix the compute document types method
[FIX] l10n_cl: prevent expected singleton error (checked in tests) in post
[I18N] l10n_cl: add new translations
[I18N] l10n_cl: reduce size of taxes names and abbreviation for invoices (probably more work to add here)
[FIX] l10n_cl: remove countries from accounts
[FIX] l10n_cl: remove recalc of domain when journal changes
[FIX] l10n_cl: remove sale constraint
closesodoo/odoo#53068
X-original-commit: 060f083879f6094941f746928832fec253a23bb0
Signed-off-by: Josse Colpaert <jco@openerp.com>
Purpose
=======
Improve the lunch categories and mutli-company environment.
Specifications
============
- Able to archive a product category and this should archive/unarchive
all the products in that category also added the filter for same.
when unrchive the product if category is archived then raise the
Validation to change the category OR unarchive the category.
- add a default image for lunch categories
- Adapt the size of the default image, currently it's too big,
- On lunch order form view if product images is not set then display
the category image same as kanban image.
- Add a company field on the Product categories (it's already there
but it should be visible on the view form). Added the multi company
rule for the product category and if company is not set on category
then it will be sharable by all the company. so default company on
product category null.
also on lunch product and report check the multi company and display
the product accroding to company.
closes odoo/odoo#45797
Taskid: 2200002
Closes: #45797
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
PURPOSE
Currently, there is an on-change to set an activity summary to the default
summary of an activity type. This can be useful if types are properly
configured. The problem is, the activity summary will be updated even if there
isn't any default summary on the type. Meaning that it simply removing a
relevant custom summary the user might have already entered.
SPECIFICATIONS
When triggering the on-change on activity_type_id, only update the activity
summary to the default summary if there is a default summary defined on the
activity type.
LINKS
Task-2254825
PR #51373
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Configure a catchall address in Odoo, send an email to that very
address, it should bounce back to the user asking him not to send any
email to the catchall but the email is never sent.
Internally, Odoo reply to the user using the `To` header of the original
email as `From` of the bounced email. It should never use the catchall
address as it is not a valid email to send email from.
closesodoo/odoo#53036
Task: 2277661
X-original-commit: 86c8f0960f709692aa787ae62d446b4427a7c312
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Fix various issues spotted in 13.3 when testing event. Notably
computation of 2many fields coming from template.
SPECIFICATIONS
When updating template on an event, one2many fields should be better managed.
Previous heuristic was
* if event type uses o2m configuration (use_ticket / _schedule / _question)
and has lines
* erase existing lines;
* create new lines based on old one;
This has the drawback of loosing information of what is sent (mail) or
sold (tickets) or answered( questions). Another drawback is that only
types having line are synchronized. This means that if updating several
times the event type you could end up with an XMas configuration with
lines coming from different event types, depending on their o2m configuration.
We choose a better heuristic that should solve this issue
* every time we change type, independently of its use_* field that is used
mainly for UX on the type itself:
* erase existing lines that have not been used yet (no mail sent, no
ticket linked to registrations, no answer linked to registrations)
* create new lines based on old one; if type has no lines, event will
have its old empty line erased as well;
It means that we try to synchronize more the type to the event while keeping
configuration line already used in some registrations.
Also provide some other fixes like deletion restrictions or better domain
for UX purpose. See sub commits for more details.
LINKS
Task ID 2244487
PR odoo/odoo#52923closesodoo/odoo#53034
Forward-port-of: odoo/odoo#52998
Forward-port-of: odoo/odoo#52923
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Add a domain on question_id. Its event should be the same as registration
event. Otherwise when editing in backend all questions are available while
only those related to the registration's event should be.
Task ID 2244487
PR odoo/odoo#52998
FwdPort of odoo/odoo#52923
X-original-commit: 25d53430f32598a5db65be807756182d2063b3ee
Prevent to unlink tickets when having registrations by adding an ondelete
restrict attribute. Otherwise billing information may be lost.
Task ID 2244487
PR odoo/odoo#52998
FwdPort of odoo/odoo#52923
X-original-commit: 5322d76d378e4bd88a42dc0e4b01bb46c7b3546a
Synchronize only timezone value from event type if set. Otherwise keep the
existing one or fallback on user defined one.
Task ID 2244487
PR odoo/odoo#52998
FwdPort of odoo/odoo#52923
X-original-commit: 10094beec786ef0ea6e32e621d4e026fedeba19a
We consider that changing category should always update value of those fields
to avoid having oddly-configured events. Indeed if you choose a new event
category most of its configuration should be propagated to the event.
Task ID 2244487
PR odoo/odoo#52998
FwdPort of odoo/odoo#52923
X-original-commit: f7e747886caebf37d60037a3e0e760f95bd0fb68
PURPOSE
Fix various issues spotted in 13.3 when testing event. Notably
computation of 2many fields coming from template.
SPECIFICATIONS
When updating template on an event, one2many fields should be better managed.
Previous heuristic was
* if event type uses o2m configuration (use_ticket / _schedule / _question)
and has lines
* erase existing lines;
* create new lines based on old one;
This has the drawback of loosing information of what is sent (mail) or
sold (tickets) or answered( questions). Another drawback is that only
types having line are synchronized. This means that if updating several
times the event type you could end up with an XMas configuration with
lines coming from different event types, depending on their o2m configuration.
We choose a better heuristic that should solve this issue
* every time we change type, independently of its use_* field that is used
mainly for UX on the type itself:
* erase existing lines that have not been used yet (no mail sent, no
ticket linked to registrations, no answer linked to registrations)
* create new lines based on old one; if type has no lines, event will
have its old empty line erased as well;
It means that we try to synchronize more the type to the event while keeping
configuration line already used in some registrations.
Also provide some other fixes like deletion restrictions or better domain
for UX purpose. See sub commits for more details.
LINKS
Task ID 2244487
PR odoo/odoo#52998
FwdPort of odoo/odoo#52923
X-original-commit: 645f70cad033083e82a3ef9102c694c331badef9
Co-authored-by: Sebastien Mottet <oms@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
Purpose of this commit is to add some tests related to event_type to event
configuration. Indeed changing a type on an event may change its sub models
(mails, tickets, questions). Asserting current behavior is necessary before
tweaking behavior considered as to be improved.
Task ID 2244487
PR odoo/odoo#52998
FwdPort of odoo/odoo#52923
X-original-commit: 6fb42e70164bab05681b11f1e76e320db0266445
Spotted when working on event fixes.
Task ID 2244487
PR odoo/odoo#52998
FwdPort of odoo/odoo#52923
X-original-commit: f5440420b07baf32e9a6b9f84fead4f140fb921a
current expression implies that any payment of a quote from the portal (/my/quotes) will try to save a token whenever the user says they want the customer to pay online, which seems bizarre. Normally you'd only want that for quotes with subscription products, and there is an override of that method in sale_subscription for that specific case.
closesodoo/odoo#53024
X-original-commit: 47f7230cd38c4e5a2f644a04f87fa0b5a844f73b
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Steps to reproduce the bug:
- Let's consider a storable product P with automatic inventory valuation and re-invoicing policy at cost
- Create a SO with P, generate an invoice I and validate I
Bug:
A new line was added in the SO (related to the anglo saxon move line)
PS: In 12.0, no line was added on the SO when I was validated.
opw:2247915
closesodoo/odoo#53011
X-original-commit: c5cd7329529cfa27d1f65217bd54042642711048
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
- Create flexible BOM for product P
- Create a MO for 5 units
- Produce 3 units
- Post the inventory
- Cancel the MO
The MO remains 'In Progress'.
In case of a flexible BOM, the quantity produced is compared to the
quantity to produce to know whether the MO should be done. In this
specific case, however, the MO should be closed.
It's not possible to rely on the move states in this case, so we
force the MO state.
opw-2270279
closesodoo/odoo#53010
X-original-commit: c99fe9dc5b5054d8d92b7283ad9f27f150de410b
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce:
- install crm
- go to crm > configuration > settings > activate leads
- go to a contact > click the "opportunity" smart button >
create an opportunity > select the newly created opportunity > click
the "meetings" smart button
Previous behavior:
meetings are filtered with 'search_default_opportunity_id' set to active_id.
active_id is referring to the partner_id in this case. this leads to
a cache miss error.
Current behavior:
meetings are filtered by the right opportunity (current id).
opw-2272325
closesodoo/odoo#53013
X-original-commit: b9abc757da3034209b083c4ba862edd3865f7637
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: mightyjol <jhk-odoo@users.noreply.github.com>
ACLs on the wizard lines should match that of the wizard, otherwise
ERP managers can see the action but get an error as soon as they open
the wizard.
Since ERP managers have write access on arbitrary users, that's
probably the right group to use.
Task 2275134
closesodoo/odoo#53007
X-original-commit: 657d44f08c402bc0547b7cbb01c2d447e641d062
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
This commit is a significant rewriting of client-side discuss, chatter,
chat window, and messaging menu using OWL. The behavior should be broadly
the same, with some slight functional changes here and there.
From a technical standpoint, the code of messaging is mainly organized in 2
main groups of modules:
- models, which are logical entities that depict the client-side state of
messaging as a whole.
- components, which are in charge of displaying information from models.
This refactoring also introduces new JS guidelines regarding folder structure
(/static) and naming rules for JS modules.
Community PR: https://github.com/odoo/odoo/pull/39023
Enterprise PR: https://github.com/odoo/enterprise/pull/6249
Task-1914207
This PR is a collaborative work by Alexandre, Julien, Sébastien and Xavier,
with the precious help of Lucas to speed it up towards the end.
closesodoo/odoo#39023
Related: odoo/enterprise#6249
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Co-authored-by: Alexandre Kühn <aku@odoo.com>
Co-authored-by: Julien Giannone <jgi@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Co-authored-by: Sébastien Theys <seb@odoo.com>
Co-authored-by: Xavier Dubuc <xdu@odoo.com>
Ease manufacturing order edition in allowing to edit in the tree view.
Consider that one manufacturing order = 1LN/SN and create back-orders
in case several of them should be produced in the same MO.
Ease definition of operations and their different steps by allowing to
do it in the same BoM screen.
joint work Simon Lejeune <sle@openerp.com>
joint work Arnold Moyaux <arm@odoo.com>
joint work William Henrotin <whe@odoo.com>
joint work =?UTF-8?q?R=C3=A9my=20Voet=20=28ryv=29?= <ryv@odoo.com>
joint work yhu-odoo <yhu@odoo.com>
joint work "Tiffany Chang (tic)" <tic@odoo.com>
task-2241471
closesodoo/odoo#52949
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
- Activate multicurrency and use a 1.5 rate on USD to EUR (to ease
calculations)
- Create two customer invoices in EUR (company is in USD) for two
different partners (e.g. partner1 and partner2) with only one line and
an amount of 100 EUR (removed the tax as well so that payment term line
is 150 USD on receivable account)
- On the "Invoices Matching Rule" reconciliation model:
1. Set Amount Matching to 90%
2. Define any account for the counterpart
3. Remove "Same Currency Matching"
4. Ensure "Partner Is Set & Matches" is marked
- Then create a new bank statement with two lines as follows:
1. dummy label, partner1, 140 USD
2. dummy label, partner2, 100 USD
- When clicking on reconcile,
1. the line for partner1 is not matched
2. the line for partner2 is matched
This occur because the amount from the invoice is not correctly
converted in company currency before making the check with the bank
statement amounts
opw-2261134
closesodoo/odoo#52529
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Bunch of last minute fixes including:
- serial handling in tablet view
- expected durations and backorders
- button unplan unlinks the leave but the computed aren't recomputed
then we need to manually set the date_planned_start/finished
then we need to not propagate them on the related document
(move/production) because they are required
- operation company_id wrongly set
task-2241471
Removed abstract workorder
Removed the integration of expiry wizard in tablet view since it should
be moved in enterprise in the tablet view implementation (not possible
to set consumed lot on workorders on community anymore)
Refactor _set_quantity_done to use ORM command in order to not return a
dict with vals to_create/to_write
task-2241471
- The Scheduled Date can't be change if the MO have some planned WO.
(WO defines the scheduled date of the MO)
- Now the Scheduled Date 'date_planned_start' is set by default
with the deadline date if there is or now if there isn't (same than before).
- For MO, 'plan_date_finished' is now invisible. But keep the field
because it is used to set the date_expected of finished moves.
- Change the plan behaviour: Plan depending of the scheduled date if
this one is bigger than now, else try to plan as soon as possible.
task-2241471
Instead using production name + name of WO as name in the
leave record, use the display name of WO to reprensent uniquely
the leave (even this record is not really reprensent in views).
task-2241471
Paul Morelle