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
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.
task-2796579
Part-of: odoo/odoo#85525
The profiler can be useful to debug random behaviour, but the frame
duration becomes irrelevant in this case.
A new option allows to make all sample last exactly one second,
making the duration correspond to the number of frame,
especially useful for sql and query count debugging.
task-2796579
Part-of: odoo/odoo#85525
=> Create an invoice in foreign currency
=> Register a payment of 0 using the currency of the company and select "Keep open"
A traceback is raised
closesodoo/odoo#87886
X-original-commit: 14894623029c24230dea92ccef950cff914e1704
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Laurent Smet <las@odoo.com>
- Create an invoice having a foreign currency
- Register a payment of 0.0 using a different currency with a write-off of any account
=> traceback
Task: 2809565
X-original-commit: c86faecc980523fcfa6a3258f4c17bf30b41522c
Part-of: odoo/odoo#87886
If applied, this commit will fix the following bug by changing the
price used in the discount calculation equation to be the real price.
the two prices differs when mapping a tax inculded price to a tax
excluded price
Steps to reproduce:
1- install sales - accounting
2- create a product p with customer tax t
3- create a fiscal position for a country (belgium for example) that
maps t to a lower value tax.
3- create a pricelist pl with discount d
4- create a new SO, add a customer from belgium, add p, then select pl,
click on update prices
5- the discount is not d, it is calculated based on
(p price - customer tax)
in comparison to:
4- create a new SO, add a customer from belgium, select pl first, add p
5- the discount is d.
Bug:
the wrong price is being used for discount calculation
Fix:
calculate and use the correct price similar to the normal behavoir when
the pricelist is selected first
OPW-2745421
closesodoo/odoo#87882
X-original-commit: 43f938627ad91bab2ec233756041d5712ee29323
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: Feyens Victor (vfe-odoo) <vfe@odoo.com>
When a filename is given to the function binary_content it was shadowed
by _binary_ir_attachment_redirect_content if it is an ir.attachment.
To reproduce:
1. Start a brand new database in V14, install any app on which you can add an attachment (like Project or CRM)
2. Add a file as an attachment
3. Try to call the route "/web/content/<string:model>/<int:id>/<string:field>/<string:filename>"
closesodoo/odoo#87879
Solution: Use another variable to store the return value of _binary_ir_attachment_redirect_content and use it if the filename is not provided.
X-original-commit: 55e6097502da6169b85056b4769f4bf7fd230968
Signed-off-by: Wanderscheid Mathieu (mawa) <wama@odoo.com>
Signed-off-by: Julien Castiaux <juc@odoo.com>
*: calendar, note
In order to prepare the ground for test adaptation using the startServer method,
make the systray_activity_menu more realistic : instead of using a fake model, we
now rely on a method in the mock server. This method mimics the behavior of the
`systray_get_activities` present on the res.users model.
task-2792108
closesodoo/odoo#87743
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
In preparation for the adaptation of its adaptation to the new
way to seed tests data, the `systray_activity_menu_test` is moved to test_mail. Indeed,
with this adaptation, all fake models will be replaced by real ones, the `MailTestActivity`
model is the perfect candidate for this.
task-2792108
Part-of: odoo/odoo#87743
Removing the `related` makes it properly defined on the SQL view and
allows the field to be searched.
closesodoo/odoo#87885
Taskid: 2781421
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Task: 2760136
Currently, when a credit note is created there is a message in the chatter "Invoice created", which is not coherent.
- Credit Note creation message should be "Credit Note created"
closesodoo/odoo#87868
X-original-commit: 93f65ff0b9e19037112c33ebda4cbfbd34f633e8
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Tastemirova Aliya (alta) <alta@odoo.com>
In the dashboard of Time Off, when clicking on New Time Off, there is a difference of
one day between the start and end date and the duration of the time off shows one day.
By default, when clicking on the New Time Off button, the start and end date should be
the same with a duration of one day.
task-2760487
closesodoo/odoo#87864
X-original-commit: dbc16eac2448df63de6cbdaea81e057cd4d78e8a
Signed-off-by: Kevin Baptiste <kba@odoo.com>
When looking at the list of the payments and grouping by company, the total amount per company is no longer displayed since v15.
This is due to the fact that the new variable used to represent this data was no longer stored.
By storing this data, we can regain this ability.
task-2801688
closesodoo/odoo#87535
Related: odoo/upgrade#3401
Signed-off-by: Laurent Smet <las@odoo.com>
On large databases, the method `_compute_new_application_count` could
take up to 80% of the total loading time of the Job positions as each
job was generating 2 queries.
closesodoo/odoo#87862
Taskid: 2812400
X-original-commit: 147f6a933f106fea540bd62522b941a855fffda2
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Open a activity view(record modal), that will show records, clicking on the
'o_activity_btn' of a record will show dropdown and make sure that there are
many scheduled activity there .
Before this commit:
The dropdown was bigger than the record modal which had a scroll bar. It was not
scrollable properly and "+ Schedule Activity" button is not accessible.
After this commit:
The dropdown follows the scroll, and it will be possible to click the button.
Task- 2528111
closesodoo/odoo#87823
X-original-commit: 6436950bae7a8d0e3ec4a6eb83f42a3208a100d4
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Fixes a mistake from 0c468f6c2f160dec672bd25c673401b154b2709b where the uom
autocompletion was lost and adds a test to make sure it won't happen again.
closesodoo/odoo#87667
X-original-commit: 10bc8dc114511740d549dfc5261bc244e0a98ad9
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
When entering a date in a datetime field, it will be in the format
`08/01/2022 00:00:00`. If we place our cursor at the end of the
entry (after the hour) and each time we press enter, the timezone
offset is applied (so if offset is +1 it does +1 hour each time)
opw-2754116
closesodoo/odoo#87655
X-original-commit: 33e8540d64bb6e21debb7da9a121b706f551ab2e
Signed-off-by: Achraf <abz@odoo.com>
Previously, only one popup is allowed such that when one is not
yet close, but another one is requested, the new one will replace
the old. The function that tries to wait for the replaced popup
will never resolve resulting to some potential broken state.
This commit resolves the said issue which now allows multiple
popups at a time. We can use POS instance without demo as an
example.
Before this commit: The popup that asks whether to load the demo
products will be shown but it will be replaced by the cash opening
popup.
After this commit: The popup that asks whether to load the demo
products will be shown, then the cash opening popup will show.
When the user is done with the cash opening popup, the demo products
confirmation is shown next.
closesodoo/odoo#83661
Related: odoo/enterprise#23859
Signed-off-by: Masereel Pierre <pim@odoo.com>
In hr_holidays_attendance, the model that inherits from res.users adds a request_overtime field.
This field is used to allow the user to request overtime based on the total overtime.
The domain for the time off type includes has_valid_allocation. If the user doesn't have any allocation,
he won't be able to deduct extra hours
task-2701128
closesodoo/odoo#87845
X-original-commit: b6d186d7b46df1e0f4e0af3eb7c8e7b07909a040
Related: odoo/enterprise#25843
Signed-off-by: Kevin Baptiste <kba@odoo.com>
When using the widget res_partner_many2one (e.g. in the customer invoice
form view), the VAT number disappears when being in 'edit' mode.
This is caused by the '_getDisplayNameWithoutVAT' function, which was introduced
in PR https://github.com/odoo/odoo/pull/29189, because the VAT appeared in edit mode
but disappeared when saved at that time.
Since the VAT no longer disappears when saved, we no longer need this function
removing the VAT from the edit mode.
task-2749331
closesodoo/odoo#87843
X-original-commit: 78a5e53a99d9f0f04edf42f1ed8d713fda4de36e
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
Guillaume (gdi)