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.
- Add a related on the lunch.supplier to the company id of the linked res.partner
- Add related on the product: to the company id of the linked lunch.supplier
- add multi company Record rules
closesodoo/odoo#34859
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose of this commit is to reset the optional product
when user change the quotation template
task-2005838
closesodoo/odoo#34048
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Accept payment on Paypal without having a merchant account
The merchant only need an email address to accept payment from Paypal
Paypal will send email to the merchant to create an account with the details
Odoo will send mail to the merchant to fill all the credentials after creating an account
Note: why used rm? - If IPN is disabled in the profile (case for the new user), the default action to call the return_url is a GET. This means that if your return_url is a script, you must set rm = 2 in order to have the IPN variable POSTed to that URL
task- 34668
The activation of languages was changed at bd3a553ad9
This commit makes a few changes/fixes
- When executing the toggle_active method do not open the wizard but load
directly the language
- Rename the name of the button in tree view, Download was confusing as implies
the resources are downloaded while it is only loaded
- Remove duplicated help
- Add action button to load the language from the form view (as it the only way
from the form view was using the "Unarchive" action)
- Add label directly next to the field (was making a line return)
- Set the placeholder on the field (no effect on the label)
- Remove groups as the view is already restricted to system users
Follow-up of task id 2026150
closesodoo/odoo#34940
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
It is currently impossible to create a company.
The reason being that the newly created company is
not yet in context `allowed_company_ids`.
Therefore, every consequent access to a record protected with
a multi company `ir.rule` fails for that company.
Here, the module automatically creates a project in that company
and later read that project to check a constraint.
The read raises an AccessError, hence the company is not created.
On the other hand, a user without project creation access rights
but erp manager could want to create a company. It should work
in that case too, as the project creation is transparent to the
user and the project is archived.
closesodoo/odoo#34920
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Different templates were defined for graph, pivot and cohort views
for the no content helper. Those templates were similar (only the
message sometimes slighlty changed). This rev. creates one generic
template used by those three views.
closesodoo/odoo#34916
Signed-off-by: Mathieu Duckerts-Antoine <Polymorphe57@users.noreply.github.com>
So far there are no IoT drivers for serial equipment.
This adds a base IoT serial driver as well as a base IoT serial scale driver and drivers for the two previously supported scales. For the moment the scale drivers support both the old routes and the new event and action routes.
Task: 1892412
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#33800
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Before this commit the continuous reading of the scale
was started directly in `show`.
In order for us to be able to use the scale with IoT drivers
this piece of code needs to be overriden, so it was moved to a separate function.
Task: 1892412
This commit adds a base serial and a base serial scale iot drivers,
as well as drivers extending them for the two previously supported scales
(ADAM EQUIPMENT AZEXTRA and TOLEDO 8217).
Since just adding the new drivers creates a race condition
between the old drivers and the new, the old drivers need to be removed.
The IoT scale drivers need to be backward compatible and compatible with the community version,
so client using an IoT box with those versions can still connect a scale to the PoS.
Task: 1892412
The public user doesn't have an email address.
To start a livechat conversation, the email of the user that start the
conversation is used. As the conversation was started in sudo,
the system user's email address was used.
But, since changes with sudo() and with_users(),
the public user is not able to start a livechat conversation
as the system email is not used anymore in this case as sudo is not
changing the user but only skip the user's access right.
To start a livechat conversation, and to post a message, at least
email_from must be filled in.
Anonymous name is used to fill in email_from to bypass the checks
and to build the author given back the thread window.
If anonymous name is empty, we fallback on the company's catchall email
from the mail.channel create user.
Pre-required for task ID: 2028059
Fix Task : 2037048
PR #34918
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Jigar Patel