Only keep buttons in the header to be able to disable them with an xpath
without breaking every attrs elsewhere in the form.
Why? We want to disable these header buttons when opening a picking from
the bach transfer (by clicking on a line on a o2m list).
task-2069646
Purpose of this commit is pricelist/pricelist item can not
created/modifided linking records of diffrent companies together
closesodoo/odoo#44391
Task: 2090409
X-original-commit: 9b62813cddb2726003b4b989c32185400059dfa1
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Fix the access error you could get when filtering on ratings when not logged
in or when the user has no rights to access ratings.
How to reproduce: filter on channel review ratings in eLearning frontend
when being anonymous le portal.
As rating is a technical model, we have to first retrieve messages linked
to that rating value and afterwards return a new domain used to build
the final search.
Task ID : 2167776
PR : #42847closesodoo/odoo#44380
X-original-commit: 7a241e9c21046dababc2744dd94b0c47e2d8a931
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
purpose of this commit is to make import template compatible with v13
task-2146510
closes-#42279
closesodoo/odoo#44375
X-original-commit: 37aadf1227531838ada7dc3810cf463379736e96
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
As the keywords are added in the DOM and its' table is also toggled at
the same time, we've to put the toggling of the table after the keywords
pushed in to the DOM.
task-2063206
closesodoo/odoo#44374
X-original-commit: 09c183ab501f834666e9b292ddb9839e2f3ecc1c
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Custom model improvements needed for a Studio task:
- allow ordering custom models by something else than their id
- allow a basic `group_expand` functionality for custom models
allowing 'stage-like' behaviours (e.g. a `read_group` on `x_stage_id`
will return all the stages, including empty ones)
- small fixes detected during development:
- SQL identifiers escaping
- correct reset of the registry after `SingleTransactionCase` and `SavepointCase` tests
- correct removal of a custom class from the registry
Part of Task 2091654
Related to odoo/enterprise#7326closesodoo/odoo#43981
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
as per the task requirements pdf coupon design changed
same as email design.
Task-ID: 2027296
Closes#34620
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Fix the layout of logo to the printed coupon.
The traceability of the coupons is not clear. for Ex. coupon is send or not?
should I resend? so updated the stages of the coupon
Now the stages will be like
-pending(previously reserved) -- hidden by default
-Valid
-Sent : updated when mail is sent to customer
-used
-expired
-cancelled : hidden by default(added button to cancel the new coupon)
Cron added to expire coupon automatically.
PS: model sale.coupon do not inherit the thread so instead of message_post
change the state 'sent' from mail_compose_message.
Task-ID: 2027296
Closes#34620
Allow a naive `group_expand` for manual fields where having the
attribute set to True causes the ORM to include all records from the
relation model of the m2o field in the read_group.
This is particularly useful for custom m2o fields which represent
stages - a grouped list view or a kanban view should include all
possible stage, not only the currently used values.
Co-Authored-By: Raphaël Collet <rco@odoo.com>
Up until now, it was impossible to specify the default ordering
on models created manually.
This could somewhat be bypassed by specifying the ordering of records on
views themselves, but this has one main drawback: when using a
relational field that targets a custom model as a group-by key, the
ordering defaulted to the id of the custom record. For example, if I
create a custom field on partners that points to a custom model
'x_grade' on which an 'x_sequence' field exists, I could order my grade
in their own list view according to their sequence, but any read on
partners grouped by this 'x_grade_id' field would order the returned
groups by id while I would prefer to have them ordered according to the
'x_sequence' field.
This commit introduces a new field 'default_order' on the ir.model model
that can store this default ordering clause (as an SQL expression).
Co-Authored-By: Raphaël Collet <rco@odoo.com>
In some cases, the registry might be updated during a test step
(creating custom models/fields, for example). In those cases, there
should be an explicit call to `reset_changes` on the registry to make
sure that the next test class starts with a registry that is consistent
with the database state.
Co-Authored-By: Raphaël Collet <rco@odoo.com>
When removing a custom model, it remained listed in the base classes
(normally `base` and also possibly a list of mixins; e.g. `mail.thread`
or `mail.activity.mixin`) list of inheriting classes, possibly causing a
crash when trying to reload the registry.
This commit ensures that any custom model is removed from its parent
class `_inherit_children` set; it will be re-added automatically during
the call to `_build_model` if the custom model still exists.
Co-Authored-By: Raphaël Collet <rco@odoo.com>
When the db reflects the python models at startup, a query is generated
to update various `ir` models (models, fields, etc.). This query did not
properly escape identifiers, preventing the use of the 'order' field
name on ir.model because it is a reserved keyword in SQL and wasn't
escaped.
This commit introduces proper escaping for these reflection queries.
Co-Authored-By: Raphaël Collet <rco@odoo.com>
some layout fixed and confusing string of promo_applicability option is
changed to 'Send a Coupon' form 'Apply On Next Order'.
Task-ID: 2027296
Closes#34620
Open POS, make an order, on the payment screen select email, select a
customer, pay and validate.
The receipt will be not an attachment, but a code image. The side effect
is the visualization dependant on the viewer (email client, webmail,
etc.)
opw-2179303
closesodoo/odoo#44354
X-original-commit: c4ea4c045b97379b3c2f9e4904fb659d232bf41a
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Fill bank account information for the current company
Create an Invoice by hand, under "Other info" tab the Bank Account
section is filled.
Now create a Sale order, confirm it and create the invoice.
The invoice created from the sale order is missing the Bank Account
section, this in turn disable the QR code generation. Adding th
erequired information when creating the invoice from the sale
order fix the issue
opw-2181580
closesodoo/odoo#44353
X-original-commit: bea0ee1f484bd25fab1ed4170d88629c4fb2709c
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Event holds a description field that is not displayed nor editable in
frontend. IN this commit we display it in backend form view, allowing
to edit it.
With the upcoming facebook synchronization it allows to directly populate
it with facebook information. See Enterprise PR odoo/enterprise#8058 .
Task ID 1999230
Closes PR #44359
Related: odoo/enterprise#8058
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In case of font-awesome icon when the browser is being zoomed, we can
get a decimal font-size.
There is a system that transform font-awesome in image links so they are
readable in any email client (supporting image) but it did not take into
account decimal font-size.
With this changeset, we only send a integer font size: we do not try to
get the original value because styling is relative on elements, a 90%
zoom ratio could lead to a 98% font-awesome icon ratio.
Also improve edition of font-awesome icon edition after first save by
reverting the transformation to image on edit. Thanks to that, the
original size will also be reinstated and will not depend on zoom on
previous save.
opw-2156069
closes#43949closesodoo/odoo#44033
X-original-commit: fe72bf01b67ea20ddb74a5b05464c63cc77090ef
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
-When 'Product Description' on several line in sale.order.line.
In that case, In 'Sale Order' report description print as it is but
In 'Invoice' report lines are all fitted into one single line.
-By this commit solved this issue.
task- 2127652
closes- odoo#42006
closesodoo/odoo#42006
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
As well as background, suggested answers images are not available for public
users as they don't have access rights on that model. This commit adds a route
called by survey template that render the suggested answers image in sudo mode.
closesodoo/odoo#44351
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
There is nothing left preventing to delete an account.move.line making
the related account.move unbalanced.
closesodoo/odoo#44341
--issue: 2185112
X-original-commit: 92364270d21cc4688471597f04fe25206b320a58
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
`action_invoice_paid` should be called when the computed field
`invoice_payment_state` is set. However, the recomputation doesn't go
through `create` or `write` (since the field is protected).
A workaround is to call it at reconciliation. Indeed, an invoice can
only be paid when it is reconciled. For invoices with an amount of zero,
we call the method at posting.
closesodoo/odoo#44331
X-original-commit: 97b00da953f7860d51326a160c38fab0354458a8
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Under Projects, click on Overview, click on the smart button "Vendor
Bills".
The list will display account moves based only on the analytic account
and not the actual type of the move
opw-2180598
closesodoo/odoo#44330
X-original-commit: 5a476fb4f5d335d5460943603269f48e7ec3e026
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Was still using the old "selection:" form instead of ir.model.field.selection
closesodoo/odoo#44322
X-original-commit: fdf9b06d76f95965ed173b1631305f8c8c3a8d9d
Related: odoo/enterprise#8050
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When revamping the message fetching from the headless browser, since
stacktraces are available (by default) on console.error and
console.warning events I assumed it could / would be useful to show
them in the Python-level log. And they *were* quite useful during the
original fixing stage.
However they turn out not to be very useful day-to-day:
* they add a lot of noise and lead to the error message itself being
lost in a big block of red / logging.error
* when a tour fails (which is the vast majority of the failures) the
JS stacktrace always points to the same location in the tour
manager (the one which goes "this step never succeeded") which is
completely useless
* aside from being bundled, normal JS code (where the stacktrace could
be useful) doesn't generally use console.warn or console.error, it's
going to straight blow up with an exception in which case we always
get a stacktrace
Leave the stacktrace formatting for console.trace as that's pretty
much the only point of using this instead of console.log.
closesodoo/odoo#44343
X-original-commit: 34500853f39c9557852cb83cbc274f59d803922f
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
This is done by introducing a new threshold setting, allowing choosing a date before which all invoices and payments have to be ignored by the accounting. Once this is done, all the balances can be reimported directly, easing the migration to Odoo Accounting a lot.
account.move objects having to be ignored because of this are cancelled, and receive the new 'invoicing_legacy' payment state. account.payment objects are moved to the new 'invoicing_legacy' state and their related account.move is cancelled and marked as invoicing legacy as well.
closesodoo/odoo#41416
Task: 2092377
Related: odoo/enterprise#7071
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
The access right on payment_token is based on the partner_id
linked with the user
If there is token link with the public user,
they are shown for every request were the partner_id is not defined
If you are logged with an internal user with sales access right,
you'll see all the payment_token linked with the acquirer
We should avoid both situation and show only the payment_token
from the legit partner_id
the one of the current user or the one given as parameter
closesodoo/odoo#44346
X-original-commit: 9edad5d9018ae357e955a5e21e9366e56caa8e31
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Co-authored-by: Damien Bouvy <dbo@odoo.com>
Adapt drop zone direction when a snippet is dropped in an oe_structure
within a snippet.
Before that, the first and the last drop zone preview (when dropping a
snippet in an oe_structure inside an other snippet) was vertical if the
oe_structure width was smaller than his parent.
Part of https://github.com/odoo/odoo/pull/40690
task-2118980
When you click on an anchor link, this commit ensures that the scroll
is in the correct place if there are fixed menus on the page.
Part of https://github.com/odoo/odoo/pull/40690
task-1894456
Before this commit, when clicking on a channel mention from a chat
window, it crashed with the following error:
`TypeError: channel.detach is not a function`
This happens due to `MailService.joinChannel()` returning a promise
that is resolved with channel ID, instead of a channel object.
`channel.detach()` becomes `<Number>.detach()`, which is treated
like `undefined()`, hence crash.
closesodoo/odoo#44329
X-original-commit: 710fda06c3b30ff2267fcc1d123f15ce031b6f3a
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
PURPOSE
Integration between event and eCommerce is required only when users handle the
entire selling process online. However users may require ticketing support
while managing payments outside of Odoo. Purpose of this commit is to support
tickets directly in event application without need of sales.
RATIONALE
Remove the need to have event_sale installed to manage basic multi ticket
event type. Integration with eCommerce is needed only when one wants to handle
the entire selling flow online, i.e. order, payment, ... Integration with
Sales is needed only when one wants to create sale orders linked to attendees.
Many event users do not need all of this. Their attendees pay through bank
transfers or they simply manage payments outside of Odoo while still
requiring tickets management.
See sub commits for more details. Here are a sample of main specifications
linked to this task.
SPECIFICATIONS: TICKET MOVE / SPLIT
Remove the need to have event_sale installed to manage basic ticketing on
events.
Move ticket model (event.event.ticket) directly into event, copying most
fields from event_sale. Only sale specific fields and behavior should be kept
in event_sale :
* keep product_id and price information in event_sale;
* keep sales analysis in event_sale;
We also split tickets model used for event type (event.type.ticket) and
events (event.event.ticket). Indeed previously to this commit both are
modeled in the same table, with the following issues :
* tickets on templates use only a subset of fields: name, seats availability,
product, price;
* a ticket has either an event_id, either an event_type_id, and there are
constraints to try to avoid having lost tickets. This leads to a strange
model where m2o fields are required only in some cases with a dual
behavior;
* tickets are not shared between event.type and event.event. They are copied
and having a single model is therefore not necessary;
We therefore choose to have a light model for event.type.ticket. It is linked
to event.type when configuring template tickets. They are copied in the
onchange copying event template configuration to the event itself, leading
to event.event.ticket creation.
Some tests are moved / completed accordingly.
Access rights are copied from website_event_sale to website_even concerning
ticket access for public / portal. Currently they are kept as they are with
some rewording as it is not the purpose of this commit to rewrite them.
SPECIFICATIONS: FRONTEND
In this commit we move frontend part of ticket support from website_event_sale
to website_event. Now eCommerce / event integration adds only payment
information when registering.
About tickets
* if there is no ticket -> generic registration allowed;
* if there is one ticket -> quick registration box;
* more than one ticket -> unfolding registration box with all available
tickets;
About price
* sale not installed -> no mention of price. A ticket without price is not
free. Its description allow to tell how to pay for example;
* a price is set: price is displayed;
* no price is set: FREE is displayed;
Most event frontend templates and controllers are therefore moved from
website_event_sale to website_event. Only part about pricing and sale order
creation is now located in website_event_sale.
Buy flow remains mainly untouched. Indeed this commit is mainly about moving
template to support tickets.
SPECIFICATIONS: improve ticket model and fields propagation
Remove date fields from event.type.ticket
Propagate seats definition from ticket template to tickets
Add a description on tickets to use in frontend
Improve naming of event tickets
LINKS
Task ID 2177281
Community PR #43488
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
This commit is part of ticket model support directly in event application.
SPECIFICATIONS
Some demo data is updated in order to be able to show directly tickets
feature in event, with some registrations already configured. Some basic
demo for questions is also added on first event demo in order to have a
complex event usable in demo mode.
LINKS
Task ID 2177281
Community PR #43488
PURPOSE
Integration between event and eCommerce is required only when users handle the
entire selling process online. However users may require ticketing support
while managing payments outside of Odoo. Purpose of this commit is to support
tickets directly in event application without need of sales.
RATIONALE
Remove the need to have event_sale installed to manage basic multi ticket
event type. Integration with eCommerce is needed only when one wants to handle
the entire selling flow online, i.e. order, payment, ... Integration with
Sales is needed only when one wants to create sale orders linked to attendees.
Many event users do not need all of this. Their attendees pay through bank
transfers or they simply manage payments outside of Odoo while still
requiring tickets management.
SPECIFICATIONS
In this commit we move frontend part of ticket support from website_event_sale
to website_event. Now eCommerce / event integration adds only payment
information when registering.
About tickets
* if there is no ticket -> generic registration allowed;
* if there is one ticket -> quick registration box;
* more than one ticket -> unfolding registration box with all available
tickets;
About price
* sale not installed -> no mention of price. A ticket without price is not
free. Its description allow to tell how to pay for example;
* a price is set: price is displayed;
* no price is set: FREE is displayed;
Most event frontend templates and controllers are therefore moved from
website_event_sale to website_event. Only part about pricing and sale order
creation is now located in website_event_sale.
Buy flow remains mainly untouched. Indeed this commit is mainly about moving
template to support tickets.
LINKS
Task ID 2177281
Community PR #43488
PURPOSE
This commit is part of ticket model support directly in event application.
SPECIFICATIONS 1: remove date fields from event.type.ticket
Coming from old ticket implementation there are several unused fields on
event.type.ticket, notably dates about selling. Indeed tickets defined on
event.type are templates and should not be time bound.
Previously those fields were available on event.type tickets but not propagated
to the event tickets. Now they are not available anymore, simplifying models.
We therefore remove them from event.type.ticket model.
SPECIFICATIONS 2: propagate seats definition from ticket template to tickets
Previously to the global feature this commit is a member of, only ticket name,
product and price were copied from event.type to its events. Description has
been added in a previous commit. In this commit we also propagate maximum
seats availability.
Use case is linked to event.type defining a recurring event in a given
location. As seats availability is known it can be copied on all events
linked to this event type.
SPECIFICATIONS 3: improve naming of event tickets
Before this commit, all tickets of an event were labeled the same way
by default, using simply ``<event_name>``. This is annoying when
having several tickets as they had all the same name.
In this commit we fix that behavior by setting the name
* directly from the ticket template when tickets come from an event.type.
Configuring Standard and VIP tickets on an event type will therefore
give Standard and VIP tickets on event;
* generic 'Registration for <event_name>' when adding manually a new ticket
for an event;
LINKS
Task ID 2177281
Community PR #43488
PURPOSE
This commit is part of ticket model support directly in event application.
SPECIFICATIONS
In this commit we add a description on event.type.ticket and event.event.type
models. Its purpose is to have a description to use notably in frontend
(website_event and website_event_sale).
Currently a ticket description is available only in website_event_sale and is
the description_sale field of the ticket product. As we now have tickets
independent from products, we introduce a real description field on ticket
that is either put by hand (event), either coming from the product with
event_sale.
Field is therefore also copied from event type tickets configuration to its
event tickets.
Naming on sale order does not take into account ticket description as we
consider this fields as being used for front-end mainly. SO line descripiton
is now updated as the following
* either we have a description_sale on the product, and SO line description
is 'product.description_sale \n event.display_name';
* either not and SO line description is 'ticket.name \n event.display_name';
LINKS
Task ID 2177281
Community PR #43488
PURPOSE
Integration between event and eCommerce is required only when users handle the
entire selling process online. However users may require ticketing support
while managing payments outside of Odoo. Purpose of this commit is to support
tickets directly in event application without need of sales.
RATIONALE
Remove the need to have event_sale installed to manage basic multi ticket
event type. Integration with eCommerce is needed only when one wants to handle
the entire selling flow online, i.e. order, payment, ... Integration with
Sales is needed only when one wants to create sale orders linked to attendees.
Many event users do not need all of this. Their attendees pay through bank
transfers or they simply manage payments outside of Odoo while still
requiring tickets management.
SPECIFICATIONS
Remove the need to have event_sale installed to manage basic ticketing on
events.
Move ticket model (event.event.ticket) directly into event, copying most
fields from event_sale. Only sale specific fields and behavior should be kept
in event_sale :
* keep product_id and price information in event_sale;
* keep sales analysis in event_sale;
We also split tickets model used for event type (event.type.ticket) and
events (event.event.ticket). Indeed previously to this commit both are
modeled in the same table, with the following issues :
* tickets on templates use only a subset of fields: name, seats availability,
product, price;
* a ticket has either an event_id, either an event_type_id, and there are
constraints to try to avoid having lost tickets. This leads to a strange
model where m2o fields are required only in some cases with a dual
behavior;
* tickets are not shared between event.type and event.event. They are copied
and having a single model is therefore not necessary;
We therefore choose to have a light model for event.type.ticket. It is linked
to event.type when configuring template tickets. They are copied in the
onchange copying event template configuration to the event itself, leading
to event.event.ticket creation.
Some tests are moved / completed accordingly.
Access rights are copied from website_event_sale to website_even concerning
ticket access for public / portal. Currently they are kept as they are with
some rewording as it is not the purpose of this commit to rewrite them.
LINKS
Task ID 2177281
Community PR odoo/odoo#43488
PURPOSE
This commit is part of ticket model support directly in event application.
SPECIFICATIONS
In this commit we make a quixotic attempt to clean call chain implied by
making registrations online, either in event frontend (website_event) or
with eCommerce inclusion (website_event_sale). Purpose is to get rid of some
preparation and data management methods to handle most of the code directly
at CRUD level whenever it makes sense.
We notably
* move at create and write level support of partner_id update: updating
its name / email / phone / mobile;
* move at create and write level support of sale_order-id update: updating
event, ticket, partner;
Using that and some code cleaning some methods are removed and call chain
is a bit reduced.
LINKS
Task ID 2177281
Community PR #43488
PURPOSE
This commit is part of ticket model support directly in event application.
SPECIFICATIONS
In this commit we move menu definitions in their own file. It eases views
split and move, as otherwise there are dependencies between files that are
complicated to solve. Better to have menus defined in a main file, and updating
them at will afterwards.
We also improve menus sequences and groups, as some were missing or badly
defined.
Registration tree view is slightly updated to include phone and mobile numbers
as those are used notably for communication. They are hidden by default
like email.
Finally a small tweak of event kanban view is performed, notably to have
a better display with dependencies installed. We ensure all cards have the
same height.
LINKS
Task ID 2177281
Community PR #43488
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Co-Authored-By: Stéphane Debauche <std@odoo.com>
Before this commit, when typing something in the search view in
Japanese, and then clicking on a suggestion from the IME dropdown
menu, the search view menu did not update with selection.
Steps to reproduce:
- Enable Japanese IME in hiragana mode;
- Type "test" in search view;
- Soft-select another suggestion item, e.g. "テスト";
- Double-click on suggestion item "test";
=> The search view menu still detects "テスト".
As a result, clicking on any of these search view suggested filters
picks "テスト" instead of "test".
This commit fixes the issue by updating search menu when clicking
in a suggestion in the IME menu.
opw-2061590
closesodoo/odoo#44318
X-original-commit: 0bca4c0883f2b58842da6a8c1a4e26bf2444d5f3
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
With this commit, the url widget automatically prefixes the href
url by http:// if no protocol is specified, so that clicking on
the url will by default redirect to an external website.
To prevent this behavior, one can still specify the new option
'website_path: true' on the url field node in the view arch.
Thanks to this, we can remove a similar logic (only implemented on
res_partner model) which automatically altered the value saved in
database to force its 'http://' prefix.
task-2153184
closesodoo/odoo#42118
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Simon Lejeune