This commit simply adds a sequence field to the crm.iap.lead.industry model and
re-orders the records imported in the CSV file.
This re-ordering is performed to show preferred records to the user, having
some diversified industry choices at the top that provide interesting results.
Nothing should change functionally.
UPG PR odoo/upgrade#2288
Task-2471703
Reveal industries were naively implemented to match a single ID on the reveal
service side.
While this is very convenient from a technical point of view, it does not
really work on the user end, since various industries are very similar and some
of them could be merged to ease usability.
This commit allows the crm.iap.lead.industry to have several reveal_ids.
Since we don't want to make this too complicated, we simply stored them as a
Char and separate them with a ",".
They are split right before being sent to IAP and all reveal ids are merged
back into a single list, making it work the same way as before on the IAP side.
We also took this opportunity to completely remove some of the listed
industries, since after some research they appear to give absolutely no result.
UPG PR odoo/upgrade#2288
Task-2471703
Preparation commit where we simply move the crm.iap.lead.industry model into
its own file.
As we are about to make some changes to the industry, we use that opportunity
to do a bit of cleaning.
Task-2471703
The style of website requires that the checkmarks of checklists be
offseted a little bit differently in website that in field html. This
acknowledges that difference so that they're properly centered in both
cases.
closesodoo/odoo#71348
X-original-commit: 91133da51697f77951d925141ae5cff012230b63
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Indenting a checklist item duplicated its checkbox. This properly copies
the css from the editor that was lost in translation.
X-original-commit: 14efea8ac944eba483f7300d6ba6e51592f26b80
Actually, salesmen have to add manually the acquirer_id to the link, and it isn't user-friendly. The dropdown will show the possibility to add the acquirer_id.
Task #2504225closesodoo/odoo#69334
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: Valentin Chevalier <vcr@odoo.com>
A fix was made in https://github.com/odoo/odoo/pull/66466 to consider
the situation where pin of employee is scanned using barcode. This
results to a change in behaviour in the NumberPopup where it no longer
accepts empty string as payload when it is confirmed. There are multiple
ways to solve this issue, and the simplest is just to adapt the test
following the behavior change. In this fix, we modify the starting
value of the popup so that when confirmed, the popup successfully
resolves.
closesodoo/odoo#70292
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Issue:
> Set bg color combination for a snippet... > Save
> Edit mode > Select the snippet
> Open color palette in bg option
> Hover a color option
> When a color button is left, the preview is cancelled
but the color combination class is not applied anymore.
In '_computeWidgetState' (for 'selectStyle' method), the right
value ('o_cci') is not returned because we get empty "colorNames"
(the "colorPalette" is not rendered on start).
The goal of this commit is to fix this behaviour by rendering the
colorPalette in start for snippet options, this way, the new code
won't affect the speed fix added in [1] for 'OPTIONS' tab.
[1]: https://github.com/odoo/odoo/pull/65223/commits/ce54c3f21293513673cb1fc6073ada5f0a2b5641
task-2538326
closesodoo/odoo#71365
X-original-commit: fd31c9a10f97c92a48d0589a8bbeaf13a641e891
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The `groupby` function is used to builds groups of(product, lot) keys
and their corresponding move lines / quants. `groupby` groups
*consecutive* keys, which is why the input is sorted by the keys.
`sorted` on recordsets keys will not sort as we would expect in this
particular situation, as the comparison operators on records act as
Set Comparison operators on the record ids, i.e. to compare the sets
superset/subset relationships:
```
>>> env["product.product"].browse(1) < env["product.product"].browse(2)
False
>>> env["product.product"].browse(1) < env["product.product"].browse([1, 2])
True
```
Example of sorted on stock.move.line records, where the product id 7313
is both in the slots 4 and 12 instead of being consecutive:
```
>>> [l.product_id.id for l in sorted(lines, key=itemgetter('product_id'))]
[7436, 7437, 7352, 7423, 7313, 7351, 7423, 7424, 7320, 7398, 7312, 7352, 7313, 7436, 7437, 7442, 7443, 7320, 7423, 7424, 7318, 7396, 7368, 7355, 7316]
```
Now when we group by id the 2 ids 7313 are correctly placed together in
slots 1 and 2:
```
>>> [l.product_id.id for l in sorted(lines, key=attrgetter('product_id.id'))]
[7312, 7313, 7313, 7316, 7318, 7320, 7320, 7351, 7352, 7352, 7355, 7368, 7396, 7398, 7423, 7423, 7423, 7424, 7424, 7436, 7436, 7437, 7437, 7442, 7443]
```
This commit aims to sort by "id" of the related records, to ensure the
same (product, lot) couples are consecutive.
closesodoo/odoo#71276
X-original-commit: d53d8bdf789e8f79ea4d531d944686abb59d6a26
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
In order to not show unnecessary tax groups when configuring a tax,
we'll now filter them to only shows the tax groups that are either
linked to no country, or that are linked to the same country as the tax.
Task id #2206280
Purpose of the commit is to hide the expense product from sale and
purchase menu.
So in this commit, make the expense product as sale_ok and purchase_ok
False to make them invisible in sale or product.
closesodoo/odoo#71222
Taskid: 2491238
Signed-off-by: Kevin Baptiste <kba@odoo.com>
- Create a product with Category configured with:
* Costing Method: First In First Out (FIFO)
* Inventory Valuation: Automated
- Create a PO to buy 2 units at $100 (PO1) and receive the products
- Create a SO to sell 2 units (SO1) and deliver the products
=> COGS of SO1 should be $200 ($100 * 2)
- Return 1 unit from previous delivery
=> COGS of SO1 should be $100
- Create a SO to sell 1 unit (SO2) and deliver product
=> COGS of SO2 is $100
- Create a PO to buy 1 unit at $200 (PO2) and receive the product
- Re-deliver the returned unit from SO1
=> COGS of SO1 should be $300 ($100 + $200)
- Create invoice for SO1 and post it
The journal items (account.move.line) corresponding to the COGS have an incorrect
value: $200 ($100 + $100), instead of $300 ($100 + $200)
The issue comes from the method computing the anglo saxon price unit.
It does not take into account quantities from stock moves that have been returned.
This commit computes the number of units that have been returned for each stock
moves used to compute the anglo saxon price unit and to take the result into account
during the computation (of the anglo saxon price unit).
opw-2501260
closesodoo/odoo#71346
X-original-commit: 83136c8e7569636d38e12fc45f297e4d6f22ad36
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
`./odoo-bin -h` prints unnecessary spaces between sentences.
---
task-2431630
Finetuning of #71130closesodoo/odoo#71364
X-original-commit: fcc60e219fd024394f8642509a20755f964546b6
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
These changes have been made to be able to add some behaviors in some specific points of the flow when overridden.
X-original-commit: 455f49fe74611849ee1ff6addc875352d1b6c386
This legacy package was supposed to be an alias to `odoo.upgrade`.
However, depending on how your import its sub-packages (and in which
order), we were ending with the module being loaded multiple times,
breaking the expectation of a singleton.
```python
In [1]: from odoo.addons.base.maintenance.migrations import util as m1
In [2]: import odoo.addons.base.maintenance.migrations.util as m2
In [3]: m1
Out[3]: <module 'odoo.upgrade.util' from '/Users/chs/devel/odoo/odoo/stable/odoo/addons/base/maintenance/migrations/util.py'>
In [4]: m2
Out[4]: <module 'odoo.addons.base.maintenance.migrations.util' from '/Users/chs/devel/odoo/odoo/stable/odoo/addons/base/maintenance/migrations/util.py'>
In [5]: from odoo.addons.base.maintenance.migrations import util as m3
In [6]: m3
Out[6]: <module 'odoo.addons.base.maintenance.migrations.util' from '/Users/chs/devel/odoo/odoo/stable/odoo/addons/base/maintenance/migrations/util.py'>
In [7]: m2 == m3
Out[7]: True
In [8]: m1 == m3
Out[8]: False
In [9]:
```
Now, with this import hook, we ensure that the modules imported from
`odoo.addons.base.maintenance.migrations` are aliases to ones imported
from `odoo.upgrade`.
```python
In [1]: import odoo.addons.base.maintenance.migrations.util as m2
In [2]: m2.__name__
Out[2]: 'odoo.upgrade.util'
```
closesodoo/odoo#71351
X-original-commit: 0d0458a0f370f872caacac26361f2c4730c2cbba
Signed-off-by: Christophe Simonis <chs@odoo.com>
Co-authored-by: Christophe Simonis <chs@odoo.com>
Steps:
- Go to Website
- Click "Go to Website"
Bug:
The default phone number on the website is not fictional and may cause
unwanted spam.
Explanation:
In North America, only 555-0100 through 555-0199 are specifically
reserved for fictional use.
> The industry also reserved a block of 100 numbers as fictitious,
> non-working numbers (555-0100 through 0199) for use by the
> entertainment and advertising industries.
Source: https://www.nationalnanpa.com/pdf/NRUF/ATIS-0300115.pdf
opw:2530388
closesodoo/odoo#71341
X-original-commit: 37be09d7d73bd4942396f06f5b5cfa22cca78f56
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: backspac <backspac@users.noreply.github.com>
When planning a Manufacturing Order, if an operation takes place in work
center with a different time zone, the computed date may be incorrect
(the start date may be outside the working hours)
To reproduce the error:
(Use demo data. Current timezone: Europe/Brussels)
1. In Settings, enable "Work Orders"
2. Open an existing Work Center
3. Click on "Standard 40 hours/week"
4. Set Timezone to "Asia/Bangkok"
- Note that all slots are between 8:00-12:00 and 13:00-17:00
5. Create two storable products P_compo and P_finished
6. Create a Bill of Materials BM:
- Product: P_finished
- BoM Type: Manufacture this product
- Components: 1 x P_compo
- Operations: 3 x Operation with existing work centers
7. Create a Manufacturing Order:
- Bill of Material: BM
- Quantity: 100
8. Save, Confirm, Plan
Error: (it depends on the time the test is done) The 'Scheduled Start
Date' of the second operation is incorrect. Adding the time zone
difference gives a time that is outside the work center's timetable
(i.e., outside 8:00-12:00 and 13:00-17:00).
The computations do not consider the time zone of the work center.
OPW-2393330
closesodoo/odoo#71332
X-original-commit: dab24e497f095d0c7857f07d037e9cb16749e2ea
Related: odoo/enterprise#18572
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Before this commit, when the use focused a many2one field and then
pressed tab, the first item of the autocomplete dropdown was selected.
This is not what we want if the user didn't write anything in the input,
and if he didn't use the up/down keys to highlight a specific item of
the dropdown.
This commit ensures that we only select the highlighted item when the
user presses tab if he previously wrote something in the input (which
hasn't been emptied meanwhile) or if he used the up/down keys to select
a specific item.
task-2455781
closesodoo/odoo#66443
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Bug
===
Since 4da64b3f3c , if multiple users of
different companies are in the same channel, and if the type of the
channel is "email", a traceback is raised when sending a message.
Technical
=========
"with_user" drop the SU flag and is not enough to bypass the multi
company ACLs. Moreover, we do not want to send a "channel_seen" bus
notifications and we can mark the message as seen on the JS side
directly.
Changes
=======
So now, the traceback is not raised anymore in that case, and the
message is marked as seen if the receiver has the web client open.
But, if the receiver has not the web client open, when he will login,
the message will not be marked as seen. This can be improved but at the
moment we just want to revert the fix that cause the traceback and fix
the issue in most cases.
Task 2427790
closesodoo/odoo#71320
X-original-commit: 8b5de95bea0087c48d17f40847750eb31fe97caf
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Change “default_partner_id” from “commercial_partner_id” to “bank_partner_id”
for “partner_bank_id” field in from view. If not, on an invoice, a newly created
partner bank (via “Recipient Bank” field) would be created for the partner
instead of the current company.
closesodoo/odoo#71312
Task: 2524441
X-original-commit: e18e256137e4593aee0cb6f1d0fcc4168dff79c1
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: jbw-odoo <jbw-odoo@users.noreply.github.com>
While using the cash rounding, there were issues when rounding up and down.
The pre filled amount was correct but the rest of the transaction was wrong. (Wrong due, wrong change,...)
This commit re calculate the rounding applied when using up or down payment.
closesodoo/odoo#71298
X-original-commit: bfccdf07adba35a5838a35a7bba98a1d71c67d2f
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Before, when using the manage order, if a payment method was used and then removed from the pos.config,
we couldn't load the old order anymore because of unknow reference.
To fix this, we load all methods at the opening of the pos but when we display the payment methods we only show those in the pos.config.
closesodoo/odoo#71292
Task-id: 2541708
X-original-commit: e44219b1cdb80d37b557ff74767f5f3e5aca5072
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Before this commit:
B2CS is not decreased in case of refund but it's shown in CDNUR but CDNUR has a condition that only shows a refund of B2CL.
HSN value is not decreased in case of refund
After this commit:
Refund is decreased from B2CS and not show that in CDNUR
HSN value is decreased in case of refund
B2CS = Business to Consumers Small
B2CL = Business to Consumers Large (invoice value is more than Rs.2.5 lakhs)
CDNUR = Credit/Debit Notes for Unregistered
HSN = Harmonized System of Nomenclature(hsn code per product)
closesodoo/odoo#71225
Opw: 2446769
X-original-commit: 9f6b5b889b9402a391a1215c44ce2c5501e1b5de
Related: odoo/enterprise#18497
Signed-off-by: Josse Colpaert <jco@openerp.com>
Signed-off-by: Jigar Vaghela <jva-odoo@users.noreply.github.com>
Beforehand, when installing the SEPA DD module, the Accounting App
was also installed, because of a dependency between the batch payment
feature and the account_accountant module.
Now, a bridge module breaks this dependency, and SEPA DD can be used with
the Invoicing App. This means that Batch Payment, being a dependency of
SEPA DD, is available to the Invoicing App.
task-2375697
closesodoo/odoo#65634
Related: odoo/enterprise#16161
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
The footer company name override from the website is done in a separate
template from website.layout in order to avoid duplicating it when
edited.
Related to https://github.com/odoo/odoo/pull/69943
task-2468472
closesodoo/odoo#71307
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps:
- Install Website
- Go to Website
- Click "Go to Website"
Bug:
The default phone number on the website is not fictional and may cause
unwanted spam.
Explanation:
In North America, only 555-0100 through 555-0199 are specifically
reserved for fictional use.
> The industry also reserved a block of 100 numbers as fictitious,
> non-working numbers (555-0100 through 0199) for use by the
> entertainment and advertising industries.
Source: https://www.nationalnanpa.com/pdf/NRUF/ATIS-0300115.pdf
opw:2530388
closesodoo/odoo#71303
X-original-commit: 5a047574dde6b207697244c866749d3cd439922c
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: backspac <backspac@users.noreply.github.com>
Before this commit the PyInotify filesystem watcher used by the code
autoreload feature (`--dev=reload`) would not get a chance to free
it's inotify watches before the reexec, hence at each reexec triggered
by a code reload the inotify watches where accumulated until potentially
reaching the kernel limit `fs.inotify.max_user_watches`.
This patch ensures that inotify properly closes it's file descriptor
before we reexec:
https://github.com/dsoprea/PyInotify/blob/f77596a/inotify/adapters.py#L79closesodoo/odoo#71302
X-original-commit: 8703ff1e3d9be6f2f5fce2e8c4e62589b05133fb
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Before this commit, for default colors, the text-muted class color was
set as !important from the portal and could not be overriden by the
website, leading to inconsistent display between the website and the
portal for the copyright.
As a fix for stable, we do not change the text-muted color from the
portal when using default colors.
task-2468472
closesodoo/odoo#71300
X-original-commit: d2e934631d4de02a7933434a1252dab994fed4b7
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: web
This commit brings some functionnal changes to the palette selection
screen:
- The list of suggested palettes does not depend on the uploaded logo
anymore. It is now a fixed list of 20 palettes manually chosen among the
existing ones.
- The recommended palette is not chosen among the existing palettes
based on the logo's extracted colors anymore. The recommended palette is
now a fully custom palette generated based on the two main colors
extracted from the logo.
- The selected palette has a border to indicate it is the currently
selected palette.
task-2518565
closesodoo/odoo#71268
X-original-commit: 23dee47ed51d0dfa54f68ef4b328aba957589bb9
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
In a Manufacturing Order, the components' quantities are rounded using
the rounding precision of the produced product's UoM. This leads to
incorrect values.
To reproduce the error:
1. In Settings, enable "Units of Measure"
2. In UoM, edit Units:
- Rounding Precision: 1
3. Create two products P_finished and P_compo
- P_compo's Product Type: Consumable
- P_compo's UoM: L
- P_finished's UoM: Units
4. Create a Bill of Materials
- Product: P_finished
- 1 Component:
- Product: P_compo
- Quantity: 0.2
- UoM: L
5. Create a Manufacturing Order:
- Product: P_finished
6. Confirm, Mark as Done
Error: Qty to consumes became 0 and consumed qty is 0. Both values
should be 0.2L, but they have been rounded using the rounding precision
of Units
OPW-2529462
closesodoo/odoo#71293
X-original-commit: aff3a2e06801dfb7a58df5180fb4ab5487b27f02
Signed-off-by: Steve Van Essche <svs-odoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
The optimization 2ccf0bd0dc does not take into account that to
"unblacklist" a user, you have the archive the mail.blacklist record so
only mail.blacklist active records need to be taken into account.
Added test without the fix fails with:
AssertionError: False is not true : MailTrace: email
test.record.02@test.example.com (recipient res.partner(), state:
sent, record: mailing.test.blacklist(166,)): found 0 records (1 expected)
opw-2536304
closesodoo/odoo#71277
X-original-commit: 965c67cb16d2a4ac10d35a01da3af311867a47e6
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Issue
- Install 'Survey' & 'website' module
- Enable "es_VE" language and activate on main website
- Go to Website Homepage
- Switch to "Spanish (VE)" language (footer)
- Go to "Survey" module
- Create a survey:
- Add a question of type 'Date' then save
- Click on "TEST" button
- Start survey and add a date with the datepicker
- Submit survey
Error message : 'This is not a date'
Cause
When submit survey, not using the database date format.
Solution
When validating form (on submit), check if date is formated
with database format and (not the moment locale since user can
alter date and datetime format).
opw-2452237
closesodoo/odoo#71228
X-original-commit: f3c5dd794e4de71187fd7532c39595b2297eb93d
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Before, the "Company name" placeholder was hardcoded in the frontend
layout template, and the user had to change it with his company name
from the website view, which was not user-friendly if the website module
was not installed.
Now, by default, the frontend layout template displays the user's
company name. If the website module is installed, it is editable.
task-2468472
closesodoo/odoo#71176
X-original-commit: 059804be90021559debee6f930462594a3ca8a97
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The display name of cancelled entries is "/"
This provides no information to the user - especially when the duplication message is logged.
This aims to improve the display_name of account.move so draft and cancelled entries display the id as a reference
closesodoo/odoo#70764
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
In mail_plugin module, add a method which returns translatable modules,
this method will be overridden in the other modules to add their module names.
Translations are prepared via the _prepare_translations method which uses
the get_translations_for_webclient method, this way we can easily fetch
translations without having to write python code.
We also add xml files in "static/", these files contain terms to be translated,
for each plugin we create a separate xml file so that we can easily update each
plugin separately.
This implementation will allow having translations handled by Odoo, which has
several advantages:
- existing system, nothing to develop
- it will use transifex and the terms will be translated by the community
- forces that mail_client implementations to have the same logic (consistency)
- compared to other solutions which rely on python code to return translations,
this solution is more robust as it avoids having to type the string to
translate twice
Task-2480075
closesodoo/odoo#69118
Ent-pr: https://github.com/odoo/enterprise/pull/17626
Plugin-pr: https://github.com/odoo/mail-client-extensions/pull/6
Related: odoo/enterprise#17626
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
before this commit: when many2mnay_tags widget does not have color_field in
options still hovering over many2many_tags badge shows cursor pointer, while
it should display default cursor and if there is color field given in options
then cursor should be pointer.
after this commit: cursor pointer will be displayed only when color field is
given in options else shod cursor default.
task-2451204
with this commit, we adds many2many_avatar_user widget to have same behaviour
as many2one_avatar_user where clicking on avatar image opens chat box, so to
have same feature on many2many_tags which is related to res.users we adds
many2many_avatar_user widget.
task-2451204
Steps to reproduce:
1. activate routes setting + multi-step incoming shipments (2 or 3,
doesn't matter)
2. create an immediate transfer receipt
3. add a done quantity (optional: validate)
4. open corresponding 2nd step internal transfer
Expected result:
- amount done in immediate transfer receipt will be demand of internal
transfer
Actual result:
- demand (and all other values) will be 0
closesodoo/odoo#68885
Task: 2492994
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
"Set Quantities" button does not make sense to show for immediate
transfers since there are no quantities to reserve, therefore we hide
it.
Task: 2492994
Aurélien Warnon