The abilty to use a custom control panel for an action
seems to have been lost with 18e5416.
With this commit the action config can specify a custom
component to use as control panel.
Usefull for o-spreadsheet integration.
Task 2238915
closesodoo/odoo#52807
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
The point of sale user interface has been adapted to work on mobile
devices.
We modified the design of payment lines to look like payment methods and
stack them together in the mobile view.
When you had a cash method, the amount was not preffilled during
payment, now we always prefill the amount to keep it more simple.
closesodoo/odoo#51891
Task-id: 1887609
Related: odoo/upgrade#1334
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
The domain field on a website is used:
1) to get the right website in case of multi-website
2) to compute base URL of canonical URL
For the 2nd usage, a scheme can be set (eg. https://hello.world) that
will be used instead of default http://
opw-2266224
closes#52784closesodoo/odoo#52796
X-original-commit: bc2899ba0905fe14a481d922a8fc57decf069692
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
We already have BDO tag as allowed tag in sanitized HTML that is
similar to BDI tag, so this commit also adds BDI in allowed tags.
BDI* tags make sense in email since email client can have different
orientation than Odoo (alternative is to use `<div dir="auto"></div>`).
*: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/bdi
opw-2256982
closes#52787closesodoo/odoo#52801
X-original-commit: 68edebb0d862acb3dc14f839aaef744306c5e269
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Translate the repair fees description in the language of the partner, as
done for repair lines.
opw-2274120
closesodoo/odoo#52760
X-original-commit: 0bc7ac2a9d60534f0e7bec120ad716bbb7d13155
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Generally, Users are not necessarily aware that they can quick create a most
records by simply typing in their name+enter in the many2xxx field input.
The exact purpose of this commit is to make sure the user discovers the quick
create feature of our many2xxx fields.
For that, when the input is empty, display 'Start typing to create a record...'
at the bottom of the dropdown when can_create is set and no_create_edit option
not set. So the user can easily understand that by typing and pressing enter
will create the new record.
Also "Search and Create" options in the dropdown only been shown to the user
when it type anything in the input box as the same case in the "Create" option.
Task : 2266557
Co-authored-by: Mohammed Shekha <msh@openerp.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Accessing the "Create and edit" option can be bothersome when testing:
- you must click on the m2o dropdown to open it
- input a value
- click on the "Create and edit" m2o item
Now, a helper exists to compile all these tasks into a single helper:
the many2one 'createAndEdit' function.
Usage:
`await testUtils.fields.many2one.createAndEdit('m2o_field', "ABC");`
Before this commit, the mock server "_mockDefaultGet" method was a bit
naive:
- it accepted any 'default_' field coming from the 'kwargs.context'
regardless of the existence of the field
- it accepted any value for these fields
Now the method is looks a bit more like its original server-side
counterpart:
- the context keys are added if they correspond to actual fields
- a pseudo validation removes many2one fields values not corresponding
to any record
Change event onboarding rainbow message to something more relevant. Default
message is considered as less user friendly than the new one.
Before this commit the category_id for a tag had no label displayed. We choose
to wrap the category_id field inside a group so that field labels shows up.
In settings, wrap the tag_ids inside a div.o_setting_right_pane so we can have
the left border displayed correctly, like most fields in settings.
Finally remove "Online" template from the event_data since it acts like a
dummy type without pre-defined data.
Task 2257884
closesodoo/odoo#52472
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Introduce an automated tool to create leads from event registrations. Events
are a powerful source of leads as they attract attention. This leads to leads
with good quality as they mark interest while gathering contact information
which allows to follow-up.
This merge aims at automating this process by automatically creating leads
based on user-defined rules.
SPECIFICATIONS
Add a new module event_crm. It allows to create leads automatically based on
event registrations. This is done based on rules defined in a new model
event_lead_rule.
Add a new menu "Lead Generation" in the configuration tab of an event. It
allows to create generation rules. Those are a set of conditions to generate
a lead with some pre-filled values as the type of lead, tags or salesperson.
SPECIFICATIONS: CREATION TYPE
There are two types of lead creation:
* per attendee: create a lead for each registration;
* per order: create a lead for a group of registrations;
The last one is only available through interface if it is possible to register
a group of attendees in one action (when event_sale or website_event are
installed). Behavior itself is implemented directly in event_crm.
Basically a group is either a list of registrations belonging to the same
event and created in batch (website_event flow). With event_sale this
definition will be improved to be based on sale_order.
SPECIFICATIONS: CREATION TRIGGERS
There are three options to trigger lead creation. We consider basically that
lead quality increases if attendees confirmed or went to the event. Triggers
allow therefore to run rules:
* at attendee creation;
* at attendee confirmation;
* at attendee venue;
This trigger defines when the rule will run.
SPECIFICATIONS: FILTERING REGISTRATIONS
When a batch of registrations matches the rule trigger we filter them based
on conditions and rules defines on event_lead_rule model. Heuristic is the
following:
* the rule is active;
* if a filter is set: filter registrations based on this filter. This is
done like a search, and filter is a domain;
* if a company is set on the rule, it must match event's company. Note
that multi-company rules apply on event_lead_rule;
* if an event category is set, it must match;
* if an event is set, it must match;
* if both event and category are set, one of them must match (OR). If none
of those are set, it is considered as passing;
If conditions are met, leads are created with pre-filled informations defined
on the rule (type, user_id, team_id). Contact information coming from the
registrations are computed (customer, name, email, phone, mobile, contact_name).
SPECIFICATIONS: OTHER POINTS
Note that all rules matching their conditions are applied. This means more
than one lead can be created depending on the configuration. This is
intended in order to give more freedom to the user using the automatic
lead generation.
Once a lead is created for an event registration, a stat button on the event
is available to show the number of leads generated for this event and to
be able to find them in one click.
Additionally on the lead form, a stat button will be display to show the
registrations linked to this lead. On registrations a stat button is also
displayed to find the leads created from it or from its group.
Most of code has been written to run in batch, in case multiples rules have
to run on a set of new registrations. Tests are added to ensure behavior.
See sub commit for more detail.
LINKS
Task ID 2166679
PR odoo/odoo#52334
Upgrade PR odoo/upgrade#1292
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this commit is to avoid running lead creation rules when importing
registration data. Indeed import is used to bootstrap databases and/or to
update records in batch. As those are not necessarily "new" customer
information creating leads on this information adds more noise than real
utility. Moreover import can run on huge batch of records and lead creation
imply some computation that would slowdown import process.
LINKS
Task ID 2166679
PR #52334
Upgrade PR odoo/upgrade#1292
PURPOSE
Introduce an automated tool to create leads from event registrations. Events
are a powerful source of leads as they attract attention. This leads to leads
with good quality as they mark interest while gathering contact information
which allows to follow-up.
This merge aims at automating this process by automatically creating leads
based on user-defined rules.
SPECIFICATIONS
Add a module allowing to test a complete event install: add all event
dependencies. Currently only crm rules are tested as part of the lead
generation tasks. Future commits will add notably tours using all features
of event.
LINKS
Task ID 2166679
PR #52334
Upgrade PR odoo/upgrade#1292
PURPOSE
Introduce an automated tool to create leads from event registrations. Events
are a powerful source of leads as they attract attention. This leads to leads
with good quality as they mark interest while gathering contact information
which allows to follow-up.
This merge aims at automating this process by automatically creating leads
based on user-defined rules.
SPECIFICATIONS
Include in generated lead description answers from attendees to questions
defined using the website_event_questions module.
LINKS
Task ID 2166679
PR #52334
Upgrade PR odoo/upgrade#1292
Co-Authored-By: Jérémy Hennecart <jeh@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
PURPOSE
Introduce an automated tool to create leads from event registrations. Events
are a powerful source of leads as they attract attention. This leads to leads
with good quality as they mark interest while gathering contact information
which allows to follow-up.
This merge aims at automating this process by automatically creating leads
based on user-defined rules.
SPECIFICATIONS
Display group-based option for rules as registrations can now be created by
group.
LINKS
Task ID 2166679
PR #52334
Upgrade PR odoo/upgrade#1292
Co-Authored-By: Jérémy Hennecart <jeh@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
PURPOSE
Introduce an automated tool to create leads from event registrations. Events
are a powerful source of leads as they attract attention. This leads to leads
with good quality as they mark interest while gathering contact information
which allows to follow-up.
This merge aims at automating this process by automatically creating leads
based on user-defined rules.
SPECIFICATIONS
Ensure information updated on sale order also updates lead information.
Also display group-based option for rules as registrations can now be
grouped by sale order.
LINKS
Task ID 2166679
PR #52334
Upgrade PR odoo/upgrade#1292
Co-Authored-By: Jérémy Hennecart <jeh@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
PURPOSE
Introduce an automated tool to create leads from event registrations. Events
are a powerful source of leads as they attract attention. This leads to leads
with good quality as they mark interest while gathering contact information
which allows to follow-up.
This merge aims at automating this process by automatically creating leads
based on user-defined rules.
SPECIFICATIONS
Add a new module event_crm. It allows to create leads automatically based on
event registrations. This is done based on rules defined in a new model
event_lead_rule.
Add a new menu "Lead Generation" in the configuration tab of an event. It
allows to create generation rules. Those are a set of conditions to generate
a lead with some pre-filled values as the type of lead, tags or salesperson.
SPECIFICATIONS: CREATION TYPE
There are two types of lead creation:
* per attendee: create a lead for each registration;
* per order: create a lead for a group of registrations;
The last one is only available through interface if it is possible to register
a group of attendees in one action (when event_sale or website_event are
installed). Behavior itself is implemented directly in event_crm.
Basically a group is either a list of registrations belonging to the same
event and created in batch (website_event flow). With event_sale this
definition will be improved to be based on sale_order.
SPECIFICATIONS: CREATION TRIGGERS
There are three options to trigger lead creation. We consider basically that
lead quality increases if attendees confirmed or went to the event. Triggers
allow therefore to run rules:
* at attendee creation;
* at attendee confirmation;
* at attendee venue;
This trigger defines when the rule will run.
SPECIFICATIONS: FILTERING REGISTRATIONS
When a batch of registrations matches the rule trigger we filter them based
on conditions and rules defines on event_lead_rule model. Heuristic is the
following:
* the rule is active;
* if a filter is set: filter registrations based on this filter. This is
done like a search, and filter is a domain;
* if a company is set on the rule, it must match event's company. Note
that multi-company rules apply on event_lead_rule;
* if an event category is set, it must match;
* if an event is set, it must match;
* if both event and category are set, one of them must match (OR). If none
of those are set, it is considered as passing;
If conditions are met, leads are created with pre-filled informations defined
on the rule (type, user_id, team_id). Contact information coming from the
registrations are computed (customer, name, email, phone, mobile, contact_name).
SPECIFICATIONS: OTHER POINTS
Note that all rules matching their conditions are applied. This means more
than one lead can be created depending on the configuration. This is
intended in order to give more freedom to the user using the automatic
lead generation.
Once a lead is created for an event registration, a stat button on the event
is available to show the number of leads generated for this event and to
be able to find them in one click.
Additionally on the lead form, a stat button will be display to show the
registrations linked to this lead. On registrations a stat button is also
displayed to find the leads created from it or from its group.
Most of code has been written to run in batch, in case multiples rules have
to run on a set of new registrations. Tests are added to ensure behavior.
LINKS
Task ID 2166679
PR #52334
Upgrade PR odoo/upgrade#1292
Co-Authored-By: Jérémy Hennecart <jeh@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
When duplicating a registration its SO and SO line should not be copied as
it may impact a done or ongoing SO with payments already done.
LINKS
Task ID 2166679
PR #52334
Prepare event_crm link module addition by cleaning some views. Notably buttons
box has to be added directly in event and not in event_sale anymore. It allows
to add content in it independently from event_sale presence.
LINKS
Task ID 2166679
PR #52334
PURPOSE
Introduce a clearer way of handling registrations for single / multiple events
occurring at the same time and place by
* improve attendees kanban view, notably by better supporting mono and multi
event (hide unnecessary information);
* introducing a Registration Desk menu item to manage multi-event mode;
SPECIFICATIONS
Improve attendees kanban view, notably due to the following issues
* event_ticket_id as char field is hard to recognize. Notably with attendees
with same ticket directly in the kanban view;
* missing explicit icon/button of the event registration state;
Handle mono-event (coming from an event) / multi-event (global attendees
view) modes.
Replace "event_ticket_id" text by colored badge (random color on each
"event.event_ticket_id.id"). Move this field directly into event as now
tickets are supported in event, not only with event_sale.
Add button or text linked to the registration state on top-right of card.
Introduce a computed "payment_status" selection field, allowing to display
status of a registration, based on its SO and ``is_paid```field. It is better
fro UX and display. It is not stored as currently stored fields are sufficient
for current requirement. Add it to the kanban view.
Prepare barcode improvements by improving _get_registration_summary returned
data dict, adding some information to display in event_barcode.
Mobile specific: put button as big buttons on the right of the card, ensure
all cards are displayed using same height and display correct.
LINKS
Task ID #2214290
Community PR #47511
Enterprise PR odoo/enterprise#9190
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Introduce a clearer way of handling registrations for multiple events occurring
at the same time and place by
* improve attendess kanban view;
* introducing a Registration Desk menu item;
SPECIFICATIONS
Introduce a computed "payment_status" selection field, allowing to display
status of a registration, based on its SO and ``is_paid```field. It is better
fro UX and display. It is not stored as currently stored fields are sufficient
for current requirement.
Add it to the kanban view.
Prepare barcode improvements by improving _get_registration_summary returned
data dict, adding some information to display in event_barcode. Reorganize
registrations actions, and prepare a generic one leading to attendees kanban
view for registration desk.
LINKS
Task ID #2214290
Community PR odoo/odoo#47511
Enterprise PR odoo/enterprise#9190
PURPOSE
Introduce a clearer way of handling registrations for single / multiple events
occurring at the same time and place by
* improve attendees kanban view, notably by better supporting mono and multi
event (hide unnecessary information);
* introducing a Registration Desk menu item to manage multi-event mode;
SPECIFICATIONS
Improve attendees kanban view, notably due to the following issues
* event_ticket_id as char field is hard to recognize. Notably with attendees
with same ticket directly in the kanban view;
* missing explicit icon/button of the event registration state;
Handle mono-event (coming from an event) / multi-event (global attendees
view) modes.
Replace "event_ticket_id" text by colored badge (random color on each
"event.event_ticket_id.id"). Move this field directly into event as now
tickets are supported in event, not only with event_sale.
Add button or text linked to the registration state.
Kanban card structure is therefore
-----------------------
Attendee Name
Event Name (if in multi mode)
Booked by partner_id.display_name ICON/BUTTON
Ticket in a tag format
-----------------------
Buttons and icons, if registrations is
* canceled (nothing to do in Kanban, open the form view) => Canceled text
* unconfirmed and is awaiting confirmation => Attended text
* confirmed and is awaiting attendance confirmation => Button
* done, end of the flow => Icon
Mobile specific: put button as big buttons on the right of the card, ensure
all cards are displayed using same height and display correct.
LINKS
Task ID #2214290
PR #47511
PURPOSE
The purpose of this task is to improve the interface by removing the
fa-building icon which is automatically appended by the property field
(i.e. company-dependent) and, instead, indicates that a field has
company-specific values in the tooltip of the field.
closesodoo/odoo#52313
Taskid: 2266519
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
A method was written to copy translations from the template objects
(chart template) to the instantiated chart of accounts when installing
a multilang coa. (e.g. to have the translations on the accounts, taxes, ...)
The problem was that to call this functionality, this module inherited
a method, that was renamed in the meantime. The consequence being that
this method was never called.
We renamed the method correctly here.
closesodoo/odoo#52769
X-original-commit: bb31ce3bc6c0c7e1e101d93924eccea995206733
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Josse Colpaert <jco@openerp.com>
The entries comming from the optional parameter 'mapping' passed at the
instantiation of a registry were never considered when returning the
registry keys or entries. This is no longer the case.
closesodoo/odoo#52768
X-original-commit: e094ddd0ffaf3357e64ca5941ffc2e0454c24ab7
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Some companies have their office in a country, and sell and pay taxes in another one. Before this commit, they couldn't use Odoo's tax report, as the country set on the res.company than the one to be used with their taxes. It is now possible to do that, using a config parameter.
closesodoo/odoo#52734
X-original-commit: 1728dfadeac252f5cd26d7770d044ae5f06a3352
Related: odoo/enterprise#11039
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Previously, there was only one static "Sale" ribbon. Users might want to
have many types of ribbons, for different levels of sales, or to
indicate that a product is sold out. This commit lets the user create
custom ribbons and use them on prodcuts on the shop page. Additionally,
setting a ribbon on a product used to require a reload, this is no
longer the case. All ribbon modifications are stored in a cache and the
RPCs to put them into effect are only done on save.
task-1981170
Part of odoo/odoo#47574
Related: odoo/upgrade#1079
Related: odoo/design-themes#219
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Previously, the "Image full" option was on a per product basis. This is
very strange, because in most cases you either want all of your product
images to take up the entire card space, or none of them. This commit
makes the option into a global option for the shop page, so it can be
toggled for all products at once.
task-1981170
Part of odoo/odoo#47574
Before, only when you had installed the Belgian
structured communication module, when you sent an
invoice by mail then only the structured communication
would be added in the mail.
But it should be visible all the time when
you have a payment reference.
closesodoo/odoo#52618
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
When set scheduled date on PO line, set it to be the last minute of
that day to correctly decide the late of the receipt.
Task 2265912
PR #52693
Related: odoo/enterprise#11034
Related: odoo/upgrade#1323
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Some change to imporve reminder mail usability:
1. Scheduled date on POL of the PO form now is always editable.
2. Improve tooltip for the reminder email
3. don't show number of days when reminder email not checked on
both PO and partner form.
4. only show "confirm receipt date" button in debug model
5. In the mail, format date by partner.lang
6. Add button to send preview reminder mail
7. On default, receipt_reminder_email on res.partner is False
8. merge expected_date with date_planned (done by FP)
Task 2265912
PR #52693
- Create a user with only Point Of Sale User rights
- As this user, open a POS session, create a POS order
- Validate and Close the session
An `AccessError` is raised because the user has no Accounting access
rights.
A POS user should be allowed to close a POS session, as it was the case
in 12.0.
opw-2251699
closesodoo/odoo#52710
X-original-commit: bc3aec38a092c7117dd8de8f6c975cdfad04b05d
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Set rounding policy to 'Round Globally'
- Create a Tax T
Amount: 21.0%
Different tax tags for invoice and credit notes
Set any account Repartition Line
Advanced Options => Included in Price
- Create a Product P1
Sales Price: 11.8
Customer Taxes: T
- Create a Product P2
Sales Price: 15.3
Customer Taxes: T
- Create a new POS Session
- Create a POS order:
P1, Quantity: -6, Discount: 5%
P2, Quantity: 6, Discount: 5%
- Validate and close the session
A difference of 0.01 prevents from closing the session.
The error arises because the tax tags are different for an invoice and a
refund. In the following:
https://github.com/odoo/odoo/blob/1a9e147639012cc847099e69fc964f3669a36cbb/addons/point_of_sale/models/pos_session.py#L394
Both lines have different `tag_ids`, therefore their amount is not
summed when closing the session. On the other hand, the POS UI is not
aware of the `tag_ids`, so it sums then round the amounts.
The situation is quite unusual: from SO or Invoices, it is possible to
create either an invoice or a refund, but not a mixed object as the POS
is doing. Moreover, if a user invoices the POS order, there is no
problem to close the session since a regular invoice is created and tax
amounts are summed.
We consider a refund if all lines have negative quantities. We only do
it in 'Round Globally' configuration to avoid impacting non-problematic
use cases.
opw-2254211
closesodoo/odoo#52704
X-original-commit: 5f25be8eef9a9efc18a995f2c6405d08a657ac96
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
We found an error by trying to post journals entries from an expense with a use_document journals.
Add new constraint that only let the user to create invoices in use documents journals, it can not create account.move of type entry
closesodoo/odoo#52690
X-original-commit: 82bbf3784e3bdf684eef25c53bf3235ebc2b7237
Signed-off-by: Josse Colpaert <jco@openerp.com>
PURPOSE
Display the activity type through the icon of the widget and change the place to
display to whom the activity is assigned (if it is not assigned to the current
user).
SPECIFICATION
Display the deadline with a prefix as responsible if the activity assigned to
another user than the current one (uid).
Add a new 'activity_type_icon' field to the mail mixin to get the 'icon' of the
type (fa-phone, fa-users, etc...) and for the list_activity widget, display it
as an icon instead of the default 'fa-clock-o' icon.
LINKS
PR https://github.com/odoo/odoo/pull/52252
Task-2267579
closesodoo/odoo#52252
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
[1] removed the associated bg color of media list items as it was now
defined directly on the XML of the snippet. This was however enough to
break the style of old-db snippets. As the s_media_list snippet was just
refactored to need a 001 version, in the same Odoo version where the
mentioned bug was introduced, this commit can just restore the
background color associated for 000 versions.
[1]: https://github.com/odoo/odoo/commit/5953c4df6b9c08519f64a65c1cf5d5558d59f7d4#diff-62db7349afa5503cc8308e815d41db5dL10closesodoo/odoo#49697
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Lucas Lefèvre