When migrating a database, load_marked_modules will be called multiple times, alternating
to upgrade and to install modules. The main reason for this is still a litle confusing
but it as the side effect to log "Unmet dependencies" error multiple time in add_modules,
even if the dependency will be resolved later.
This commit removes the error level for this log, and replace it by another check,
performed at the end, logging any module in "to install"/"to upgrade" state.
Also log removed module as info (25), not warning. This may be changed latter
closesodoo/odoo#43797
X-original-commit: c5d6a3977de85fb974a4940fb11d54ef847e08e4
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This commit fixes the visitor's time_statistics computation. When creating a
new visitor, last connection datetime is not set, so it's not retrieved in the
search_read and crash at search_read_result[visitor.id].
This fix also speeds up and simplifies the time_statistics computation.
As time_connection_datetime is always set (for already created visitor) and in
the depends, no need to read values before looping, the data is already fetched
in memory. We can then use directly the value for each visitor in self.
Task ID: 2120464
PR #40199closesodoo/odoo#43780
X-original-commit: 1f0c9f272ea5b6b7b891fcb8d00eb81e7fe33f81
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
At 795c7b0a94 the external dependencies was changed from trying
to import 'ldap' to checking than 'pyldap' package was installed.
The problem is that pyldap is a unmaintained library that should no
longer be used, as explained on the package page:
https://pypi.org/project/pyldap/
"The pyldap fork was merged back into python-ldap, and released as
python-ldap 3.0.0."
Having pyldap version >= 3.0 installs python-ldap automatically and
will not cause any issue.
The Debian control file package name is adapted to use the latest.
The "ldap" externalm dependency defined in __manifest__.py will cause
pkg_resources.get_distribution() to fail in both case ("python-lap" or
"pyldap"), but the "import" fallback will succeed. For that reason, the
log warning is turned into a log info.
closesodoo/odoo#43769
Note: This library should be replaced by the pure python "ldap3" library.
X-original-commit: 1afd0ccf20881ba97e3c07dffb33e9a3a0b2cda4
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Before this commit, if the records had to be sorted according a
many2one field, and there was a sequence field on the many2one
comodel, the sequence was ignored. Now, the sequence is taken into
account like the actual server does.
Linked to odoo/enterprise/pull/7407
closesodoo/odoo#43763
X-original-commit: 714e52f98eec5c64a224523cee4b1e14463ed191
Related: odoo/enterprise#7869
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
- take advantage of runbot multi-build capabilities
- get similar result when running them locally during dev
- better detect when other modules add extra queries
Query counts are split in the base value (testing with just test_mail installed)
+ the extra modules overhead.
Part of task-2178641
closes odoo/odoo#43666
Pr: #43666
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
After this commit, x2many fields can have options like
create/delete which accept a domain, to make create/delete on
x2many conditional, say for example x2many field can have options
like:
options="{'create:' [('foo', '=', True)]', 'delete:' [('foo', '=', True)]'}"
With this when foo field is True, Create and Delete actions will
be available, but if foo is False then they won't.
In case of one2many fields, if 'create' is false, then 'Add a line'
(list) or 'Add' button (kanban) won't be displayed.
In case of many2many fields, 'Add a line' or 'Add' button will
always be displayed even if 'create' condition is false as it
doesn't really create records (but rather links existing ones).
Same applies for delete.
Task-2092953
closesodoo/odoo#42919
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Parth Chokshi <pch@odoo.com>
Co-authored-by: Aaron Bohy<aab@odoo.com>
This commit will fixed the error when product has some stock quants
and product category with 'Automated' valuation method, is set to that product.
==============================
Steps to product the above mentioned error:
1. Create product with any category which has 'Manual' valuation method.
2. Update 'On Hand' quantity for the same product.
3. Create product category with valuation method set to 'Automated'.
4. Now set the above product category to the same product which you created in step 1.
5. And Click on the save button.
==============================
Also edit the test case.
closesodoo/odoo#43755
Task: 2155804
X-original-commit: c62dea6a7ce6b63f708831707811e922cd6bddd0
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Display the `display_name` rathe rthan the `name` in order to include
the variant specification.
opw-2170400
closesodoo/odoo#43753
X-original-commit: c395eb91c769ea4bd3b74b89b0ee980f4169c3e0
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit the search would search for phone numbers that contained a part of a string. The mobile phone would only look at exact matches so if we'd search for '0492700' the only result would be contacts with this exact match. After this commit every mobile phone that contains '0492700' will match and be shown. This allows for quickly finding customers by a partial mobile, just like the phone number does.
closesodoo/odoo#43752
X-original-commit: 8a34a6a66f3f06829231e5d0ba536fcdd27d17ea
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
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>