Use the pivot table instead of a mapping on all found products (which does not
scale well at all when there are many products found).
On a test case of 10000 products and 300 categories (including parent/children),
testing the /shop page with a search:
- number of queries from 138 down to 128 queries,
- total request time from 0.55s down to 0.40s
- time of the changed line from 32% of the total request time down to 10%
PR: #34249
The parent categories can be retrieved directly from the current category by
using the efficient `parents_and_self` field.
This also prevents computing the parents on the controller for no reason when
not using the collapse view.
PR: #34249
Speed up:
- all queries involving `child_of` and `parent_of` by using
´_parent_store=True` and `parent_path`
- `name_get` by also taking advantage of `parent_path`
- `order by` by indexing the sequence
This reduces the time of the corresponding search lines by 20%.
PR: #34249
When search is used, include the search term in the message.
When categories are used, include the category in the message.
Prevent editing the "click new" message shown to the sales manager.
PR: #34249
*base,hr,lunch
From now on, search panels can be activated on any multi-record views, and are no longer
restricted to kanban views.
The arch of the search panel has to be specified in the search view.
HR and lunch usecases have been adapted accordingly.
Task 1985921closesodoo/odoo#34219
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Rev. e264eca enabled the search with 'child_of' operator for
categories on many2one fields. However, it crashed if there is no
parent_field on the comodel.
Before this rev. the searchpanel could only be activated in kanban
views (and it was specified in the kanban arch). From now on, the
searchpanel can be activated in any multi record view. It's arch
is moved to the search view arch (inside the <searchpanel> tag).
Task 1985921
Co-authored-by: Aaron Bohy <aab@odoo.com>
A share button has been added to the fullscreen view to avoid
exiting the view to access the share tab on the full description
of the slide.
Task ID : 1984509
closesodoo/odoo#33418
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of the commit is to ensure parent and child partners have the
same company. When creating a new child in another company and one of them
tries to log a message on other contacts an error is raised due to
multi company record rules.
It makes no sense to have child contacts belonging to separate companies.
If parent is set on contact then the company_id should be readonly and
it will automatically set the parent's company_id.
Task-1934813
closes: #32405
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The button wasn't displayed when going through a template's variants
stat button. It was missing an inherit on this view. We also try to
align them the best we can.
task-2029011
closesodoo/odoo#34682
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Purpose of this commit is to ease slides / lessons management in eLearning
frontend.
The publisher will now be able to see if a slide is in preview mode from
the slide list in frontend of eLearning.
He'll be able to activate/deactivate the free preview mode with a button.
Task 1999705.
closesodoo/odoo#34182
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of the commit is to improve the user experience of the chat by
deleting some extra step that might be unnecessary
So when a user tries to remove him/her self from the follower, it will not ask
for confirmation and removes the user from particular document straight away
without any confirmation.
If user remove the another partner from follower then it will raise the prompt
dialog for confirmation
task-1998188
Closes: #34050
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
When we change job_id on an applicant, we want that the stages above
change (if there arre special stage for this job).
On website recruitment, a traceback prevent to complete the form to
apply for a job.
closesodoo/odoo#34981
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Indeed we don't rate slides, we rate courses. Therefore rating mixin is not
necessary as well as access token.
Access token field as we are using the _mail_post_access and a karma check.
Commit linked to task 1952064.
Purpose of this commit is filter that allows to
filter by messages is not working properly so
removed messages filter from custom filter menu
task-1939953 closes-#34141
closesodoo/odoo#34141
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
PURPOSE
Provide fixes to SMS behavior, notably in composer.
Better integration in various applications: contacts, calendar, crm.
Allow to automatically send SMS from server actions.
SPECIFICATIONS
See sub commits for more details.
Linked to task 1925950 and 1935280
closesodoo/odoo#34864
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Send SMS from server/automated actions. Indeed we can already send emails from
server actions. The goal is to have the same thing for the sms.
SPECIFICATION
Purpose of this commit is to add support of sending batch SMS through
server actions. This means sending SMS will be available also for
automated (base automation) and scheduled actions (cron).
A new type of server action is added: sms. User choose an sms.template
to use to send SMS in batch. An option allow to choose to keep archive on
selected records. If no archive is kept, a batch of sms is created. With
archive a _message_sms is performed with note subtype, allowing to have
a discuss messages with only sms customer being notified.
Linked to task 1935280
Part of PR #34864
PURPOSE
We want to integrate SMS with crm.lead in the same way it is integrated
with res.partner.
SPECIFICATION
Add phone/SMS widget on 'phone' and 'mobile' to call the same 'Send sms' modal
than on partner. This modal can also be called from the action menu in list
view. This modal should behave the same as for res.partner (same number
selection and warnings). The SMS text message should also be logged in the
chatter (similarly to res.partner)
SMS sent in batch should be logged in the chatter of the corresponding record.
Linked to task 1925950
Part of PR #34864
PURPOSE
Improve integration of SMS in various applications: calendar, contacts.
SPECIFICATIONS
Calendar_sms: set right composition mode on calendar event in form mode
aka comment
SMS: keep log when sending SMS in batch through action menu
Linked to task 1925950 and 1935280
Part of PR #34864
PURPOSE
Improve use of SMS. Followup of merge 4287481bf0 .
SPECIFICATIONS
Currently when sending an SMS through the UI a message is posted using the
comment subtype. However it is better to lessen number of notifications
and log using the note subtype as it is mainly a log to know something has
been sent.
Order SMS by ID desc to ease finding them in technical menu.
Mail, sms: fix wording of mail / SMS failures
Linked to task 1925950 and 1935280
Part of PR #34864
PURPOSE
Purpose of this commit is to add options and improve sms composer behavior.
Followup of merge 4287481bf0 .
SPECIFICATIONS
* mass mode: add an option to keep archives when doing mass sms. This mode
is actually a _message_sms in batch using the note subtype to speedup the
process;
* improve _message_sms_schedule_mass to allow more fine-tuning of options
when calling it;
* do not block sending SMS in batch if some recipients are invalid. Indeed
using notifications there will be traces of failed SMS;
* avoid reload of form view;
Linked to task 1925950 and 1935280
Part of PR #34864
`window.openerp` being undefined, the method `on_modules_loaded` throws
an error when reaching its purpose (loading additional modules)...
The commit odoo/odoo@905e01921f removed
the compatibility layer for Odoo v8 (compatibility.js) which contained
the `window.openerp` declaration.
Being broken for that long without consequences, this feature proved to
not be useful anymore. We then remove it.
closesodoo/odoo#34821
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Using api.constrains should be used instead
Simply leave a warning in case a model uses a non-empty attribute
`_constraints`.
closesodoo/odoo#34679
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
1/ web: adapt formatDate to handle NaN values
DashboardRenderer might return NaN for `Date` or `DateTime` fields if
their original value is null or incorrect.
2/ hr: add job_title in demo data
3/ hr_recruitment: link employee in the chatter for new recruits
4/ hr: remove employee documents in the model
5/ hr_attendance: improve resiliency of relative_time
6/ hr: display manager on res_users
7/ hr: change Address Book to Employee Directory
TaskID: 2009111
closesodoo/odoo#34180
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
With the PSD2 directive coming into effect on September 14th, it was time to switch our Stripe integration to use newer APIs that support Strong Customer Authentication (SCA for short).
This meant switching from the old stripe.js implementation for 'redirection' flow to the Stripe Checkout API and from the Charge API to the newer SetupIntent API for s2s flows.
This feature branch introduce these changes as well as some slight changes in the payment module (mainly functional improvement that were noticed when developing this, nothing major and no change in the flow/model of the basic payment models).
Note that the way our checkout flow is built for s2s transactions prevents us from using the PaymentIntent API (which would be a better fit that the SetupIntent in some cases) - to use that API, we would need the payment transaction to be created before the token, which is not the case in our current flows. This will probably be changed in a future task with a more flexible checkout flow.
In the mean time, the downside of using SetupIntent instead of PaymentIntent means that from the bank's point of view, the authorization of the card and the payment are 2 different requests - this could lead to a higher rejection rate in SCA flows and possibly to payments that stay 'pending'. There is no way to know for sure before PSD2 goes into full effect though, and this implementation should normally suffice.I would advise using the 'redirection' flow most of the time though, since it is clearly the best fit between Odoo and the Stripe APIs at the moment.
Task 1986267
closesodoo/odoo#33978
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
The previous commit introduced some changes for SCA/PSD2 but some things
were missing; most notably, registering payment cards in a s2s flow used
the old Charge API that is not SCA-ready.
This commit uses the SetupIntent API instead, allowing to register the
card prior to payment. The global flow is described in the Stripe
documentation in more details: https://stripe.com/docs/payments/cards/saving-cards
Unfortunately, given the complete flow of payments, it is not possible
to use the PaymentIntents API since this would require having the
reference of the transaction before it gets created (the TX is created
after the form submission, but the token must already exist at that
point). Since this is meant to be backported, this changes are kept
minimal in this feature branch. The PaymentIntents API would have been
better since registering a card during a payment makes it more likely
that future off-session transactions will not require an authentication
step. We'll have to live with that for now; it's difficult to know
exactly how this will affect customers before PSD2 goes into effect on
september 14.
Another branch might completely change the flow soon-ish to a more
asynchroneous model, although it may miss the v13 freeze date -_-
- treat s2s transactions as such
- don't filter out tokens saved on acquirers that are not set for full
s2s mode, as tokens might get created through a form and still be usable
- detect the submit event as well as the click on the 'Pay Now' button
to avoid completely wrecking the payment flow by pressing the return key
- correct start override in JS should chain promises
There is two payment flow in stripe:
1) Redirection Flow (Form Based):
in this flow, the user will redirect to stripe website for payment
- create a session for a user and redirect the user to stripe with that session
- after successful payment, the user will redirect back to odoo
- get all the details of charge by using payment intent API
- if user have tick save data then the token will be created
2) S2S Flow:
after clicking on pay now button, one popup display with card element
element is provided by a stripe with all validation facilities
After submitting details, payment flow is
- create payment method with card element on stripe
- create a customer with partner email on stripe
- attach customer to the payment method on stripe
- create a token with customer and payment method in odoo
- create payment intent in odoo
- make a request to stripe
- after successful request, payment will be charged for that card
task- 1986267
closes: https://github.com/odoo/odoo/pull/33978
PURPOSE
Mass mailing is currently a bit messy. As SMS will be added as a way to notify
people in mass through SMS let us take this opportunity to somehow clean this
application: organization, light code cleaning, model renaming.
SPECIFICATIONS
Guidelines: re-organize model files and split them according to main
models. Also reorganize views.
Move some code bits / fields declarations to reorder them. Purpose is to
make code easier to understand and find. Funny we found two override of create
that have been merged. An override of name create is not necessary considering
code was present in one of the two merged create. Make internal methods private
and rename send_mail to action_send_mail to avoid confusion with composer and
template send_mail methods.
Fix UTM management and propagation in mass mailing. Right UTM definition in
mass mailing :
* mass mailing campaign -> utm.campaign
* mass mailing -> utm.source
* "email" -> utm.medium
Therefore :
* remove campaign setting source and medium as each mailing is a source
and medium is "email";
* ensure each mailing is a separate source (otherwise name is shared);
* ensure UTM values propagate to link creation are those values and not
the one coming from the mass mailing campaign;
Rename mass mailing models. Rationale :
* remove mail prefix, as mass mailing will allow to use SMS to contact
people and will soon be less mail-dependent;
* have simpler name, easier to read, find and understand;
* mailing.list/contact/tag seems a better naming than mail.mass_mailing.
list/contact/tag;
* have a mailing prefix for all models used in mass mailing;
MIGRATION
mail.mail.statistics model -> mailing.trace
mail.statistics.report model -> mail.trace.report
mail.mass_mailing.list model -> mailing.list
mail.mass_mailing.list.merge model -> mailing.list.merge
mail.mass_mailing.contact model -> mailing.contact
mail.mass_mailing.list_contact_rel model -> mailing.contact.subscription
mail_mass_mailing_contact_list_rel table -> mailing_contact_list_rel (specific
case of a decorated m2m)
mail.mass_mailing.stage model -> mailing.stage
mail.mass_mailing.tag model -> mailing.tag
mail.mass_mailing model -> mailing.mailing
fields updated (w column change)
* link.tracker.click: mail_stat_id -> mailing_trace_id
fields updated (no column change)
* mail.mail: statistics_ids -> mailing_trace_ids
* mail.mass_mailing (mailing.mailing): statistics_ids -> mailing_trace_ids
* mail.mass_mailing.list (mailing.list): subscription_contact_ids ->
subscription_ids
LINKS
Task ID 2037906
Preparing task ID 1997464 (SMS addition in mass mailing)
PR #34938
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Mass mailing is currently a bit messy. As SMS will be added as a way to notify
people in mass through SMS let us take this opportunity to somehow clean this
application: organization, light code cleaning, model renaming.
SPECIFICATIONS
Rename mail.mass_mailing model to mailing.mailing. Rationale :
* mailing is now a prefix for mass mailing models;
* mailing.mailing is easier to read / find / understand;
Note that mail.mass_mailing.campaign is not updated as it is likely to be
removed soon and replaced by simple utm.campaign model.
MIGRATION
mail.mass_mailing model -> mailing.mailing
mail_mass_mailing table -> mailing_mailing
LINKS
Task ID 2037906
Preparing task ID 1997464 (SMS addition in mass mailing)
PR #34938
PURPOSE
Mass mailing is currently a bit messy. As SMS will be added as a way to notify
people in mass through SMS let us take this opportunity to somehow clean this
application: organization, light code cleaning, model renaming.
SPECIFICATIONS
Rename mail.mass_mailing.stage and mail.mass_mailing.tag models to mailing.
stage and mailing.tag. Rationale :
* mailing is now a prefix for models in mass mailing;
* mailing.stage and mailing.tag are easier to read / find / understand;
MIGRATION
mail.mass_mailing.stage model -> mailing.stage
mail_mass_mailing_stage table -> mailing_stage
mail.mass_mailing.tag model -> mailing.tag
mail_mass_mailing_tag table -> tag
LINKS
Task ID 2037906
Preparing task ID 1997464 (SMS addition in mass mailing)
PR #34938
PURPOSE
Mass mailing is currently a bit messy. As SMS will be added as a way to notify
people in mass through SMS let us take this opportunity to somehow clean this
application: organization, light code cleaning, model renaming.
SPECIFICATIONS
Rename mail.mass_mailing.list and mail.mass_mailing.list to mailing.list
and mailing.list.merge. Rename mail.mass_mailing.contact to mailing.contact.
Rename mail.mailing_list.list_contact_rel to mailing.contact.subscription.
Rationale :
* those new names are easier to understand: mailing.list and mailing.contact
are less mail-related, especially taking into account that SMS will allow
to be less mail-oriented;
* those names are easier to read / find / understand;
* align wizard and sub-models naming with the main naming;
* have a mailing as first part of namespacing;
MIGRATION
mail.mass_mailing.list model -> mailing.list
mail.mass_mailing.list.merge model -> mailing.list.merge
mail.mass_mailing.contact model -> mailing.contact
mail.mass_mailing.list_contact_rel model -> mailing.contact.subscription
mail_mass_mailing_contact_list_rel table -> mailing_contact_list_rel (specific
case of a decorated m2m)
fields updated (no column change)
* mailing.list: subscription_contact_ids -> subscription_ids
LINKS
Task ID 2037906
Preparing task ID 1997464 (SMS addition in mass mailing)
PR #34938
PURPOSE
Mass mailing is currently a bit messy. As SMS will be added as a way to notify
people in mass through SMS let us take this opportunity to somehow clean this
application: organization, light code cleaning, model renaming.
SPECIFICATIONS
Rename mail.mail.statistics to mailing.trace and mail.statistics.report
to mail.trace.report. Rationale :
* mail.mail.statistics is linked to mail.mail model. Soon this model will
hold data related to SMS sending. It makes sense to be broader in the
naming;
* mailing.trace is more inlined with marketing.trace model that is the
marketing automation model using it in marketing automation (enterprise
application);
* mailing.trace is shorter to write;
* mail.statistics.report model should sense to be updated at the same
time;
MIGRATION
mail.mail.statistics model -> mailing.trace
mail_mail_statistics table -> mailing_trace
mail.statistics.report model -> mail.trace.report
fields updated (w column change)
* link.tracker.click: mail_stat_id -> mailing_trace_id
fields updated (no column change)
* mail.mail: statistics_ids -> mailing_trace_ids
* mail.mass_mailing: statistics_ids -> mailing_trace_ids
LINKS
Task ID 2037906
Preparing task ID 1997464 (SMS addition in mass mailing)
PR #34938
PURPOSE
Mass mailing is currently a bit messy. As SMS will be added as a way to notify
people in mass through SMS let us take this opportunity to somehow clean this
application: organization, light code cleaning, model renaming.
SPECIFICATIONS
Fix UTM management and propagation in mass mailing.
Right UTM definition in mass mailing
* mass mailing campaign -> utm.campaign
* mass mailing -> utm.source
* "email" -> utm.medium
Therefore
* remove campaign setting source and medium as each mailing is a source
and medium is "email";
* ensure each mailing is a separate source (otherwise name is shared);
* ensure UTM values propagate to link creation are those values and not
the one coming from the mass mailing campaign;
LINKS
Task ID 2037906
Preparing task ID 1997464 (SMS addition in mass mailing)
PR #34938
PURPOSE
Mass mailing is currently a bit messy. As SMS will be added as a way to notify
people in mass through SMS let us take this opportunity to somehow clean this
application: organization, light code cleaning, model renaming.
SPECIFICATIONS
Move some code bits / fields declarations to reorder them. Purpose is to
make code easier to understand and find. Funny we found two override of create
that have been merged. An override of name create is not necessary considering
code was present in one of the two merged create.
Make internal methods private.
Rename send_mail to action_send_mail to avoid confusion with composer and
template send_mail methods.
LINKS
Task ID 2037906
Preparing task ID 1997464 (SMS addition in mass mailing)
PR #34938
PURPOSE
Mass mailing is currently a bit messy. As SMS will be added as a way to notify
people in mass through SMS let us take this opportunity to somehow clean this
application: organization, light code cleaning, model renaming.
SPECIFICATIONS
Guidelines: re-organize model files and split them according to main
models. Also reorganize views.
Done in this commit
* split big python file by main models;
* split views according to python files;
* move statistics report to /report;
* merge some exploded view files (assets, snippets, application menus);
LINKS
Task ID 2037906
Preparing task ID 1997464 (SMS addition in mass mailing)
PR #34938
The layer created to handle the valuation and costing change share the
same code but they should not share the same description.
closesodoo/odoo#34952
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
adds field_name data on category and filter lists in the
search panel template so it can be used to identify their field.
this improvement is used in the drag & drop features introduced
in the documents search panel (https://github.com/odoo/enterprise/pull/4805).
Task: #1998014closesodoo/odoo#34813
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
Create a new report in order to see quantity in the past
and in the future. Also display the planned in and out moves
at their schedule date. The view available for this report is
a graph view even if it could be display with other views.
Technically it's an SQL views based on stock.quant and stock.move
Currently the interval for the report is -3 months, +3 months because
the forecast quantity is based on quants - moves during this interval
in order to keep a linear performance that's not growing with the data.
task: 2000948
closesodoo/odoo#34898
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
The move form view from 'stock move' menu item and the form_view_ref
from the picking's operations was different. However we would like the
same kind of information from each side.
This commit remove the view from picking and complete the view from
menu item.
Sébastien Theys