During the merge process of a negative move, it can deplete the quantity
of several existing moves (with positive quantities).
This is change is to make sure that a picking that would be depleted
this way becomes then cancelled, since no moves within would still be
relevant, as all moves would be set to 0.
Task-2797359
Part-of: odoo/odoo#86572
When updating the quantity of a manufacturing order,if multiple steps
were related to to its components, the changes would not be propagated
to them as no procurements were made.
So if updating the quantity of a two-step MO, the quantities from its
components within the MO would be updated, but not the ones from the
related picking.
Task-2797359
Part-of: odoo/odoo#86572
no need to select * in a query that looks like
select ...
from A
where exists(select * from B where ...)
we can instead use
select ...
from A
where exists(select 1 from B where ...)
closesodoo/odoo#88013
Signed-off-by: Raphael Collet <rco@odoo.com>
When the user create a button in the website builder through the
powerbox command "/button":
- call the editor fix for the link
- select the link
task-2704540
closesodoo/odoo#88010
X-original-commit: 92fcd5e15cf3fec96cdd2565157cd41ffd39a084
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Postgres is aligning columns to 4 or 8 bytes, depending on their type.
So, consecutive fixed-length columns of differing size will be padded
with empty bytes due to the alignment requirements.
Before this patch, columns where created in their definition order. Now,
they are ordered based on their size, in order to minimize the padding.
As an example, before each row uses 36 bytes (+24b header):
attname | typname | typlen
-------------+-----------+--------
id | int4 | 4
create_uid | int4 | 4
create_date | timestamp | 8
write_uid | int4 | 4 -> 4 bytes padding
write_date | timestamp | 8
active | bool | 1 -> 3 bytes padding
After each row uses 32 bytes (4 bytes saved per row):
attname | typname | typlen
-------------+-----------+--------
id | int4 | 4
create_uid | int4 | 4
write_uid | int4 | 4
active | bool | 1 -> 3 bytes padding
create_date | timestamp | 8
write_date | timestamp | 8
This saving scheme applies to all rows in all tables. We save between 4
and 8 bytes per row just on the usual create_uid, create_date,
write_uid, write_date.
closesodoo/odoo#87896
Signed-off-by: Raphael Collet <rco@odoo.com>
Before this commit, since https://github.com/odoo/odoo/pull/83574,
attempting to join a call through the channel guest page while being
logged as a portal user would give an acess error.
This commit fixes this issue
closesodoo/odoo#87995
X-original-commit: e6a637dc1d4e024c67b946fbe26a1b1e0dd144f3
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit
Calling a command of the powerbox created a step that delete the input
content of the powerbox. That input content came back upon undo.
After this commit
The input content that select a command from the powerbox should
never come back upon undo.
task-2806849
closesodoo/odoo#87994
X-original-commit: 2da3d928ad4c7e7c285b753fb1241326089d45e7
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Since a recent commit[1], we introduced a standard publisher tour for
the slides. However, it was randomly failing sometimes while trying to
change image of the course. It happened because sometimes the double
click was performed before the page was ready to be edited, and so the
modal to change the image could not open.
This commit fixes the tour by adding extra_trigger in relevant step so
that before double clicking the image, we can make sure that the page
is ready for the edition.
commit[1] - https://github.com/odoo/odoo/commit/1af6dfe47baf1f42865203d0f3edafc6b50bbae8
task-2786661
closesodoo/odoo#87974
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit removes the access to stripe credentials through model
helper methods.
closesodoo/odoo#87972
X-original-commit: 61faa2b32880d60c8cfb7c7761cd313383c26a0b
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Thibault Libioulle (tle) <tle@odoo.com>
Co-authored-by: Antoine Vandevenne (anv) <anv@odoo.com>
Add quicksearch on 'Number' (name) and 'Reference' (ref) for the journal entries
Add quicksearch on 'Label' (name) and 'Reference' (ref) for the journal items
Even though those fields are already searched on in the 'main' quicksearch
of each view (i.e. 'Journal Entry' and 'Journal Item'), users might look to
specifically search on the label and reference, and get frustrated when they
won't find it in the available quicksearches.
task-2753889
closesodoo/odoo#87532
Signed-off-by: Laurent Smet <las@odoo.com>
- Steps :
Create 4 Services :
> Product Type : Service
> Create on Order : Project & Task
> Unit of Measure -respectively- :
>> Hours (H),
>> Days (D),
>> Units (U),
>> g (Other).
Create a SO with the for of them (1 uom_qty for each) and confirm.
- Expected :
For both the 'Planned Hours' on the Tasks
and the section 'Sold' of the Project Updates,
the conversion to time should be processed as follows :
H : qty = uom_qty [Hours]
D : qty = uom_qty * 8 [Hours]
U : qty = uom_qty [Hours]
Other : qty = 0 [Hours] or uom_qty [uom]
- Issues :
The Task linked to SOL (Other) has 1 Planned Hour i/o 0.
In Project Updates, uom (U) is Units i/o Hours
and uom (Other) is Hours i/o g.
- Fix :
This fix corrects everything as expected.
opw-2784992
closesodoo/odoo#87884
X-original-commit: 3cae83635067707a99141aad3cf6b0b6081e8159
Signed-off-by: Xavier <xbo@odoo.com>
Purpose
=======
Departure reasons could be used on business code (eg: payroll).
Currently the mapping is made based on the xmlid, but it could
happen for some customers to create several departure reasons
of the same kind. (ex: "Resigned - Salary" or even
"Resigned - Personal Reasons").
This commit uses the departure reason on _get_default_departure_reasons
to allow considering them together.
closesodoo/odoo#87662
Taskid: 2811192
X-original-commit: c7f46a4760fa2beb7d50b4b95f10e14a1a326423
Related: odoo/enterprise#25771
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Commit "[IMP] core: don't save visitor default session" moved the geoip
from the session to the request with a deprecation warning. This commit
adapts the remaining modules to use `request.geoip` instead of
`request.session.geoip`.
Geoip is always set on the request but it can be an empty dictionnary in
case the geolocalization failed.
closesodoo/odoo#86015
Task: 2789035
Related: odoo/enterprise#25192
Signed-off-by: Julien Castiaux <juc@odoo.com>
Every request comes with a session, a dictionary that is persisted on
the filesystem and that saves various information such as the user
cart on the ecommerce.
When a user simply visits the website, a default session is created and
saved on disk, this bloats the filestore with many sessions. Creating
the session on-the-fly is cheaper than loading it from the filesystem.
With this work the default session is not saved on disk anymore unless
explicitly asked via `session.touch()`.
An exception to the statement "creating the session on-the-fly is
cheaper" is geoip, the ip geolocalization is not cheap. In this work,
geoip have been moved from http_routing/request.session.geoip to a
lazy property core/request.geoip. When requested the info is persisted
on the session. Like other keys from the default session, geoip will not
be persisted unless there is non-default stuff in the session.
Because the CSRF-TOKEN is based on the session-id, it is important the
session-id stays the same across multiples requests even when the
session is not persisted on disk. Even when a session is not persisted
on disk, the session-id cookie is still set so that the next session
created on-the-fly uses the same session-id.
Technical note regarding the session, it has been decided to drop the
session-snapshot protocol and to reintroduce a "modified" flag. It has
been decided not to use werkzeug's session (which natively comes with a
"modified" flag) and to keep our own session object. We decided to
extend MutableMapping instead of dict; using MutableMapping we only
have to override __setitem__ and __detitem__; using dict we would had to
override update()/pop()/... too.
Task: 2789035
Part-of: odoo/odoo#86015
Have a CL company setup
Issue a vendor bill
Then generate the credit note via 'Add Credit Note' wizard
Add a reason and confirm
Error will raise “You can not use a invoice document type with a refund
invoice”
As
https://github.com/odoo/odoo/commit/c9ff9d28ab75c02093ca54d9fbd1d2e203c5ee2e
for the invoice case
we need to add specific logic to handle credit notes in l10n_cl
opw-2801576
closesodoo/odoo#87946
X-original-commit: 0f1edf4d47d936c440e42fa105a8a5d6a75a8a77
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
In a subcontracting flow, the extra_cost on the subcontracted production
is read on the purchase line (via _get_price_unit() ) at the production
creation. In case the price unit on this purchase line change before the
validation, the stock valuation layer linked to the production will not
take this new value into account.
This commit ensures the price unit is the right one at validation
closesodoo/odoo#87726
Signed-off-by: Arnold Moyaux <arm@odoo.com>
During edit mode, editing the social media snippet induced losing the
whitespaces between the social media icons, thus reducing the space
between them. That space was however restored after saving.
After this commit, after each social media snippet change, we restore
a line break whitespace between each social media icon.
task-2739937
closesodoo/odoo#87933
X-original-commit: 3b8f11273bfa926172a4297785e58dfea92728d9
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit replaces the thumbnail for the social media block. The
previous one was a duplication of the facebook thumbnail.
task-2739937
X-original-commit: f10c16948095fb1590decf7d7c2428993d2829d7
Part-of: odoo/odoo#87933
Co-authored-by: @Guillaume-gdi <gdi@odoo.com>
Icons of social media links should not be removable, this commit fixes
all header and footer template to respect this.
task-2739937
X-original-commit: 20d4b7452bf5de81c99c153eaf65a38a2f953503
Part-of: odoo/odoo#87933
This commit permits to:
- avoid DOM modification when starting options of social_media.
- remove the useless HTML related to the social media block.
- generate all available social networks that are present in the DB for
the social media block.
- delete DB social media if there is no value for it in the DB.
- display an alert banner in edit mode if the block has no link.
- use a shared variable for social media db urls in order to avoid too
much RPC.
- custom links are no longer togglable, only deleteable.
task-2739937
X-original-commit: f243bcbafb9291d94840795951c8fd51cab0cae1
Part-of: odoo/odoo#87933
This became more and more needed. Of course, it should be avoided most
of the time as you do not want to rely on async operations to build the
initial rendering of a snippet (best to do server side during the
rendering of the editor panel).
This can however make sense and it is needed as a fix for the social
media snippet (see next commit).
task-2739937
X-original-commit: 3fb1718ce494ccf48959e6e4fe9f640621c4a3a9
Part-of: odoo/odoo#87933
As the social media can now be handled via the s_social_media snippet,
the media link tool is useless for s_share snippet.
task-2739937
X-original-commit: 2238c8883ef83251ca230acf183da3078b79b961
Part-of: odoo/odoo#87933
This commit permits to detect social media urls even if it's just the
domain name. Moreover, the icon detection is more accurate.
task-2739937
X-original-commit: 1045118985a7a04de47da6f1a4360e1eede84e34
Part-of: odoo/odoo#87933
This commit permits to check if the urls of the social media links start
with a correct protocol, if not, we correct it with https protocol.
task-2739937
X-original-commit: 7779d36749c5dd9d60f94985eefdbbe06ea2d818
Part-of: odoo/odoo#87933
Currently, if the tip does not have any content set in step (happens a
lot in test tours), the tip is not displayed properly. This happens
because the height of the tip is set based on the tip content which is
not available in our case.
This commit fixes the behavior by providing a default content in such
cases saying "Click here to go to the next step.". It has two benefits
(in case someone is manually walking through a test tour):
- The tip is displayed properly.
- We can guide the devs with a friendly message.
task-2792218
closesodoo/odoo#87939
X-original-commit: 922370ffb6c9b64e1440db2e9b92d1c9e03e7253
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
To reproduce
============
- Create one french company and one italian company with their respective localization packages.
- Go to the French company and create a contact, first set the country and then the VAT.
An error message will appear referring to Codice Fiscale but this information is not relevant on the French Company.
Purpose
=======
The VAT field has an onchange trigger `_l10n_it_onchange_vat` to set `l10n_it_codice_fiscale` value.
on `_l10n_it_onchange_vat` there is no verification if the VAT number is Italian, so we try to get
a Codice Fiscale from it, which leads to error if the VAT number is not Italian.
Specification
=============
To solve the issue we added a verification on the VAT number to make sure that it is an Italian one before
trying to get Codice Fiscale from it.
opw-2777519
closesodoo/odoo#87922
X-original-commit: cfa71276c6154d30d93a60efff6338412019118c
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: abla001 <abla@odoo.com>
The fix made in odoo/odoo#87723 was not taking into account the active
field.
closesodoo/odoo#87930
X-original-commit: ce6245470139e7615e5b857cb241c8fa51483e46
Signed-off-by: Kevin Baptiste <kba@odoo.com>
The e-faktur contains amounts that are not well rounded
Steps to reproduce:
1. Install Accounting app and l10n_id_efaktur module
2. Switch to ID Company
3. Open Accounting
4. Go to Customers > e-Faktur
5. Create a new range (at least one number available)
6. Create a new Customer Invoice for a customer in Indonesia with ID PKP
enabled, specify a 'Kode Transaksi' and add a product with a price of
147.5 and a tax of 10%
7. Download the e-faktur
8. The amounts on the product line are not rounded but truncated
Solution:
Round the amounts that are translated to int
opw-2793009
closesodoo/odoo#87938
X-original-commit: dbe11ced5e394f24379363873119988682542006
Signed-off-by: William André (wan) <wan@odoo.com>
opw-2729810
closesodoo/odoo#87918
X-original-commit: 65f4c4f29a9c747f114eb6359d3ebb036efab9d6
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Before this commit `selectStyle` was always applying inline styles as
`!important`.
After this commit the `!important` priority is only set if the style is
not taken into account without it.
Steps to reproduce:
- drop a "Text - Image" snippet
- select a solid Background color
=> `background-color` appears in inline style without `!important`
- select the image
- set a 10px Border width
=> `border-width` appears in inline style with `!important`
- set a 10px Round Corners
=> `border-radius` appears in inline style with `!important`
- set a 1px Border width
=> `border-width` does NOT appear in inline style because the added
`border` class already specifies that width
task-2765880
closesodoo/odoo#84765
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Having both an activity type "Request Signature" and "Signature
Request" on the plan were confusing and misleading for the users.
Related odoo/enterprise#25511
Related odoo/upgrade#3398closesodoo/odoo#87082
Taskid: 2796407
Signed-off-by: Kevin Baptiste <kba@odoo.com>
PURPOSE
Cleanup code and flow of customer rating: routes, rating_apply, rating and
message creation and update. Cleanup some view definitions.
SPECIFICATIONS
Cleanup code about rating controllers and rating_apply. Notably correctly
link a message to a rating once a feedback is posted, whatever the flow.
Update ``rating_apply`` to use either a token, either an existing rating to
udpate it and post a message. Always link the message and the rating to
be sure DB data are coherent.
This requires an update in several demo data to correctly set tokens on
ratings and use it in calls to ``rating_apply`` done in xml files.
Extract default subtype computation of rating_apply in a sub-method to allow
setting this parameter without having to deal with ``rating_apply`` details.
CODE CLEANUP
Split behavior that is generic but actually used only in project about stage
update based on rating. Move it directly in project. As it is used only once
and as generic approach is hardcoded based on fields names better keep it
localized.
VIEW CLEANUP
Move some ratings views specific to some modules directly into rating to
offer some different views based on usage (mainly text / image of rating).
Task-2812665 (Rating: Cleanup rating flow code)
closesodoo/odoo#80707
Related: odoo/enterprise#22690
Related: odoo/upgrade#3086
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose is to lessen access to internal methods and make them private. No
need to expose internal computation.
Task-2812665 (Rating: Cleanup rating flow code)
Part-of: odoo/odoo#80707
PURPOSE
Cleanup code and flow of customer rating: routes, rating_apply, rating and
message creation and update.
SPECIFICATIONS
Cleanup code about rating controllers and rating_apply. Notably correctly
link a message to a rating once a feedback is posted, whatever the flow.
Update ``rating_apply`` to use either a token, either an existing rating to
udpate it and post a message. Always link the message and the rating to
be sure DB data are coherent.
This requires an update in several demo data to correctly set tokens on
ratings and use it in calls to ``rating_apply`` done in xml files.
Extract default subtype computation of rating_apply in a sub-method to allow
setting this parameter without having to deal with ``rating_apply`` details.
CODE CLEANUP
Split behavior that is generic but actually used only in project about stage
update based on rating. Move it directly in project. As it is used only once
and as generic approach is hardcoded based on fields names better keep it
localized.
Task-2812665 (Rating: Cleanup rating flow code)
Part-of: odoo/odoo#80707
*= im_livechat, project, website_slides
MAIN PURPOSE
Purpose is to give access to some standardized views for rating directly
in rating application. Three main new views are defined
* form view with text instead of image (used notably in livechat and also
customized in project);
* form view with detailed information (consumed, ...), will be used in
technical menus used to debug and have a global view of ratings (less
business);
* kanban with stars instead of image (used notably in elearning);
As usage of rating is going to be improved let us have some default views
easy to customize. It will lessen number of hardcoded custom views.
In this commit we also set some higher priorities to module specific views
(higher = less chances to be default). That way views now have explicit
priorities and ordering is clearer.
WEBSITE_SLIDES VERSIONNING
We also set back website_slides to 2.6 as two bumps were done during saas
15.3 development (see odoo/odoo@6d33510beb and odoo/odoo@db63c03af9).
Task-2812665 (Rating: Cleanup rating flow code)
Part-of: odoo/odoo#80707
``/rating/`` routes are deprecated since odoo/odoo@8ca96078db (before v14).
Let us remove them as we are now going to v16.
Task-2812665 (Rating: Cleanup rating flow code)
Part-of: odoo/odoo#80707
Add a reception/delivery status on sale orders and purchase orders.
The idea is to have an indication in list view about the situation
of pickings linked to the SO/PO.
Inside the document itself, the quantity delivered decoration are
designed to indicate if everything is correctly deliver or if
it still something to do. (red if the delivery/receipt is late and
incomplete)
Task-2381757
closesodoo/odoo#63356
Signed-off-by: Arnold Moyaux <arm@odoo.com>
This commit simply lowers the delay between receiving an answer and reacting to
it within a chatbot.script.
The previous delay of one whole second would slow down the testing phase and
could even break builds as the tour would not detect the messages fast enough
if under heavy load (such as during multi-builds).
This comes from the fact that adding and displaying a message within the chat
window actually re-renders the whole thread (see '_renderMessages').
closesodoo/odoo#87904
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
========
The performances tests in TestLeadAssignPerf have a margin for queries
because of some randomness in query counts.
Those margins avoid random failures but will hide small increments,
making the query count fail randomly in future build. This margin also
makes the update of query counts difficult.
This commit tries to identify the source of this randomness and proposes
some fixes.
Sources of randomness
=====================
Comparing different executions, the query can differ on two point:
1. During the flush, while updating the lead
1.1 the written user_id can vary (~1 additional query)
1.2 the written convert_date can changes (~4 additional queries)
1.3 the written date_last_stage_update can change (~1 additional query)
2. during _handle_salesmen_assignment
2.1 write/_message_auto_subscribe can change? (~1 additional query)
the point 1.2 and 1.3 can be easily reproduced, adding sleep,
especially a 0.1 sleep in convert_opportunity
Writing different values for date will lead to multiple execute
when flushing the records:
the orm cannot group records with different values
Proposed fixes
==============
A. Use `cr.now` instead of `fields.datetime.now`
Using the transaction time will avoid randomness linked to the change of
second during the transaction. This will fix 1.2 and 1.3
B. Sorting members
The members comes from a o2m and the order is not deterministic.
During the test with a subset of lead (10 instead of 100),
the two last members ('Martin Sales Manager' and 'Orteil Sales Own')
can come in different orders, leading to different user_id set on lead.
Instead of 4 different users, the lead where sometimes dispatch on
5 different users with this setup. (5 queries in flush() instead of 4)
This is fixed by adding a complete order (adding id) on crm.team.members
This will solve 1.1
C. The leads are also ordered by id if they have the same probability,
since it shouldn't hurt and make the search more deterministic.
2.1 was fixed by B or C (or is not fixed) not sure anymore.
Links
=====
Task-2796579
closesodoo/odoo#85525
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
It looks like in enterprise, the value of has_group is already in cache
This will lead to an additional query when checking mail.message
creation access rights in community.
This commit warmup the user _has_group ormcache to avoid an
inconsistency between community and enterprise
Stack of the additional query:
```
sql('SELECT 1 FROM res_groups_users_rel WHERE uid=%s AND gid IN\n ... (SELECT res_id FROM ir_model_data WHERE module=%s AND name=%s)') (SELECT 1 FROM res_groups_users_rel WHERE uid=29 AND gid IN (SELECT res_id FROM ir_model_data WHERE module='base' AND name='group_user'))
execute (odoo/addons/base/models/res_users.py (self._cr.execute("""SELECT 1 FROM res_groups_users_rel WHERE uid=%s AND gid IN):847)
_has_group (odoo/tools/cache.py (value = d[key] = self.method(*args, **kwargs)):90)
lookup (called at <decorator-gen-111> ():2)
_has_group (odoo/addons/base/models/res_users.py (return self.with_user(uid)._has_group(group_ext_id)):832)
has_group (addons/mail/models/mail_message.py (if not self.env['res.users'].has_group('base.group_user'):):380)
check_access_rule (odoo/models.py (records.check_access_rule('create')):4321)
_create (odoo/models.py (records = self._create(data_list)):4087)
create (odoo/api.py (return create(self, arg)):410)
_model_create_multi (called at <decorator-gen-16> ():2)
create (odoo/addons/base/models/ir_fields.py (recs = super().create(vals_list)):613)
create (odoo/api.py (return create(self, arg)):410)
_model_create_multi (called at <decorator-gen-68> ():2)
create (addons/mail/models/mail_message.py (messages = super(Message, self).create(values_list)):599)
create (odoo/api.py (return create(self, arg)):410)
_model_create_multi (called at <decorator-gen-193> ():2)
create (addons/mail/models/mail_thread.py (return self.env['mail.message'].create(create_values_list)):2132)
_message_create (addons/mail/models/mail_thread.py (new_message = self._message_create(msg_values)):1874)
message_post (addons/rating/models/mail_thread.py (message = super(MailThread, self).message_post(**kwargs)):14)
message_post (addons/mail/wizard/mail_compose_message.py (ActiveModel.browse(res_id).message_post(**post_params)):321)
_action_send_mail (addons/mail/models/mail_thread.py (return composer._action_send_mail(auto_commit=auto_commit)):1964)
message_post_with_template (addons/mail/models/mail_thread.py (return record.message_post_with_template(False, **kwargs)):1929)
_message_compose_with_view (addons/mail/models/mail_thread.py (self._message_compose_with_view(views_or_xmlid, **kwargs)):1933)
message_post_with_view (addons/crm/models/crm_lead.py (opportunities_head.message_post_with_view():1336)
_merge_opportunity (addons/crm/models/crm_team.py (merged = lead_duplicates._merge_opportunity(user_id=False, team_id=False, auto_unlink=False, max_length=0)):578)
_allocate_leads_deduplicate (addons/crm/models/crm_team.py (assign_res = team._allocate_leads_deduplicate(candidate_lead, duplicates_cache=duplicates_lead_cache)):507)
_allocate_leads (addons/crm/models/crm_team.py (teams_data = self._allocate_leads(work_days=work_days)):304)
_action_assign_leads
test_assign_perf_duplicates (odoo/tools/misc.py (return func(*args, **kwargs)):792)
```
task-2796579
Part-of: odoo/odoo#85525
clesgow