When recieving a kits product, it will be decomponent in the picking. In
this commit, we add a column in the picking to show the info of the kits
in picking.
Task-2444000
COM PR odoo/odoo#75555
ENT PR odoo/enterprise#20440
UPG PR odoo/upgrade#2783
Before this commit the search bar was specific to products. This generalises the search bar so it can be added to any model.
A snippet is provided, and used to replace the old search bars of blog, courses, event, forum, page and shop. The search results of these pages and the autocomplete of the search bar run through the same search mechanism.
A new hybrid results page has also been created as a target of a search on "Everything".
In each involved module, `website._get_search_details()` is implemented to return search metadata for every model related to the `search_type` parameter. Search metadata for a single model is returned by `_get_search_detail()` on that specific model.
The autocomplete runs through the additional `website._render_search_results()` pre-rendering step that prepares the data to fit in the autocomplete template.
This PR also introduces a fuzzy search mechanism: if the searched term is not found then the search is performed on a resembling term. The similarity is obtained from a Levenshtein distance combined with ratios of common and different letters.
By default the dictionary against which the search term is matched is based on the content of the search fields containing a word that starts with the first letter of the search term.
If the `pg_trgm` Postgresql extension is installed the dictionary is built from matches obtained using the `word_similarity` function.
task-2379555
odoo/upgrade#2186closesodoo/odoo#65871
Signed-off-by: Benoit Socias (bso) <bso-odoo@users.noreply.github.com>
Before this commit the search on pages was only done in the main
language.
After this commit the search on pages is based on the translated "arch"
field.
task-2379555
https://github.com/odoo/odoo/pull/65871
Part-of: odoo/odoo#65871
Before this commit the `_search_get_detail` result contained callback
functions to handle special behavior during fetching and rendering.
After this commit a `website.searchable.mixin` is introduced that must
be inherited by models that participate in website-based searches.
Custom behavior previously achieved with callbacks is now achieved by
overloading methods of this mixin.
task-2379555
https://github.com/odoo/odoo/pull/65871
Part-of: odoo/odoo#65871
Before this commit searched terms were the ones entered by the end-user.
After this commit if the searched term is not found then the search is
performed on a resembling term.
The similarity is obtained from a Levenshtein distance combined with
ratios of common and different letters.
By default the dictionary against which the search term is matched is
based on the content of the search fields containing a word that starts
with the first letter of the search term.
If the `pg_trgm` Postgresql extension is installed the dictionary is
built from matches using the `<%%` operator (similar to the
`word_similarity` function).
Several approaches were benchmarked during development, those results
are available through the task record.
task-2379555
https://github.com/odoo/odoo/pull/65871
Part-of: odoo/odoo#65871
(*: website_blog, website_event, website_forum, website_sale,
website_slides)
Before this commit the search bar was specific to products.
After this commit a generic search bar is available as a general feature
of website which can be configured to inspect specific models.
The snippet is used to replace the old search bar in blog, courses,
event, forum, page and shop.
The search results of these pages and the autocomplete of the search bar
run through the same search mechanism.
A new hybrid results page has also been created as a target of a search
on "Everything".
In each involved module, `website._search_get_details()` is implemented
to return search metadata for every model related to the `search_type`
parameter.
Search metadata for a single model is returned by `_search_get_detail()`
on that specific model.
The autocomplete runs through the additional
`website._search_render_results()` pre-rendering step that prepares the
data to fit in the autocomplete template.
task-2379555
https://github.com/odoo/odoo/pull/65871
Part-of: odoo/odoo#65871
The service is called `notifications` when mocked in tests,
instead of `notification`
closesodoo/odoo#75859
Related: odoo/enterprise#20554
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
In the spreadsheet app, we need the exact same values which are saved
for "ir.filter" records.
This commit refactor a bit things to allows getting those values without
actually creating the "ir.filter" record.
Task 2572184
Part-of: odoo/odoo#75859
Co-authored-by: LucasLefevre <lul@odoo.com>
In multivat setup, we need to create taxes in foreign countries to map them with domestic taxes. Before this commit, this was only possible manually, even though all the necessary information lies in Odoo's account.tax.template objects created by l10n modules.
We now display a banner on top of foreign vat fiscal positions with a button allowing instantiating those templates directly from them when it's appropriate.
closesodoo/odoo#75803
Task: 2453325
Related: odoo/enterprise#20553
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
This commit allows users to "delete" their messages in discuss, as well
as their notes on other records. Admins can delete anyone discuss
messages or notes. Tracking messages such as a change in stage or other
cannot be deleted.
This "delete" is a "soft-delete" in that it only empties the message's
content, so that it is no longer displayed in the UI, but remains in the
database so that people who got notified by email can still reply to the
message, among other things.
task-2365646
closesodoo/odoo#74857
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit amount updates were not taken into account during the
payment operation.
After this commit amount updates are taken into account for the actual
payment operation and payment fees are updated according to the amount
and the partner country.
Part of #63133
task-2398403
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
This commit adds /donation/* routes to perform the donation:
- /pay: shows the form with the contact details and donation details
- /transaction: creates the partner_id if missing and executes the
transaction
- /confirm: displays the payment success page
PR-63133
task-2398403
Part-of: odoo/odoo#63133
As the descriptions of the donation snippet will be in hidden inputs,
we added the possibility to translate these inputs in translate mode.
PR-63133
task-2398403
Part-of: odoo/odoo#63133
There were two issues when cloning a website_form field:
1/ Cloning is not done
Steps to reproduce :
Drop a form from the editor, save
Click on edit, select the field
Click on the clone option without hovering the label position option
2/ A traceback is thrown
Drop a form from the editor, save
Click on edit, select the field
Click on the clone option after hovering the label position option
Some FieldEditor options modify directly the dom and replace the field
node, which the editor will detect as a change of unbreakables. As a
result a rollback will be required in the next call to
odooEitor.historyStep(), done in SnippetEditor.clone().
To solve that we skip potential rollbacks while recording a history step
during a clone.
task-2485093
closesodoo/odoo#75908
X-original-commit: 7a75f295087cb02f162477a9df3b138b6780dbdd
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When cloning a website_form field, we rerender the cloned field to
reassign its elements ids and for attributes with a unique ID instead of
the old ones.
Rerendering the list also removes an issue with Selection fields that
were not visible after a clone and a save, as it was usually done after
a _rerenderXML, not executed after a clone.
Also, _renderField docstring was wrong, and its return values
terminology have been replaced with correct one.
task-2485093
X-original-commit: 92bacc8907fa9577805b28a11894e7a006b2a5bf
Part-of: odoo/odoo#75908
Changes on cover attributes (bg-color, size) were not saved properly
when no other option where changed on the object.
task-2547729
closesodoo/odoo#75890
X-original-commit: 6d00c5ac0346beb57eef2192fe21a45a1158d87e
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
This allows to solve the following use case:
* we are in March
* a SO created during January shows currently a delivered quantity (timesheet on service or delivered goods on storable products): timesheets/pickings were done in February
* creating the accrued entry for January 31 should display accordingly an amount of 0 by default since everything was done in February
Invoices invoice_dates are also taken into account:
* day 0 : delivered 10
* day 2 : 5 invoiced
* accrued entries for 10 if accrual date = day 1, accrued entries for 5 if accrual date = day 3,
followup of task 2255642
closesodoo/odoo#75886
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Two changes:
- The `barcode_rule_gs1_16` was renamed `barcode_rule_gs1_17` (and its
AI was changed too) as the AI 16 is about the sale by date, not the
expiration date;
- The `qty_done` rule type was changed for `quantity` as `qty_done`
refers to the move field, but the rule isn't only about this field as
it could be used by other model like `stock.quant`.
closesodoo/odoo#75699
Related: odoo/enterprise#20482
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Before this commit, multiple package types can have the same barcode.
As it makes no sense and could lead to confusion, it's no more possible.
task-2627002
Part-of: odoo/odoo#75699
For `stock`, adds package type demo data (pallet and box).
For `barcodes_gs1_nomenclature`, adds a custom rule (AI 91) to recognize
the package type in the Barcode Application.
As there is no standard GS1 nomenclature's rule for the package as
defined by Odoo and there is a bunch of free-to-use AI (from 91 to 99),
using one of them for the package type could be useful to be able to
scan a new package and create it on the fly with the wanted type.
task-2627002
Part-of: odoo/odoo#75699
Before this commit, editing a mail.activity with the "meeting" category would
open a modal form for the mail.activity, which did not make much sense.
When editing a mail.activity that is linked to a calendar.event, you will now
jump on the calendar view to edit the related event, which is much more
convenient.
In addition, when scheduling such an activity, the "Edit" button in the chatter
is renamed to "Reschedule", to show the user that he will land on the calendar
view.
Furthermore, trying to delete an activity that is linked to a meeting will now
prompt a confirmation dialog warning the user that the meeting will be deleted
as well.
Finally, we moved the 'phonecall' activity category from the 'voip' module
(enterprise) to the base 'mail' module.
Scheduling a phonecall activity will let the user choose if he wants to:
- Simply save the activity, which will schedule a regular mail.activity
- Open the calendar to create a related calendar.event
Used typically when you want your colleagues to see that you are busy in your
calendar during this call.
Task-2486126
ENT PR odoo/enterprise#20431
UPG PR odoo/upgrade#2775closesodoo/odoo#75530
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Aurélien Warnon <awa@odoo.com>
This PR brings UX improvements in the Services Apps (Planning, Timesheets, Project, Helpdesk, Field Service)
task-2615316
Related: odoo/enterprise#20426
Related: odoo/upgrade#2773
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#75524
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
* Move the action to "technical feature" debug mode group instead of
group "advisor"
* Set the action in noupdate="1" to facilitate customization of right
task-2604155
closesodoo/odoo#75819
Related: odoo/upgrade#2794
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Before 660dc0ebaf it was possible to use Authorize to pay via your bank
account using the "Redirection to payment acquirer" option. Since the
refactor removed the redirect it was no longer possible. This commit
reintroduces that feature.
It does so by adding new form elements that accept bank account
information. Additionally it reintroduces the `billTo` and `customer`
parameters that Authorize requires when processing ACH payments.
task-2628318
closesodoo/odoo#75289
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
A new field on tax groups makes it now possible for this group to be displayed under a subtotal label. If not set, this defaults instead to "Untaxed Amount", keeping the traditional behavior. This is intended for withholding taxes, which can now be implemented with negative taxes and a tax group with this field set.
To do that, this commit entirely refactors the way amount_by_group worked, and replaces it with a more complete json field called tax_totals_json. It also streamlines the way taxe totals are displayed on invoices, PO and SO and makes it so that a common code is called instead of copy-pasting the same block 3 times as before.
[IMP] purchase: always display tax totals by groups on purchases orders
Before, tax totals on purchase.order's form were not shown by group, and were instead all aggregated in a single "Taxes" category. The same went for the pdf export. The portal view, though, did show the totals by group. We now display the tax groups in the same way all the time.
closesodoo/odoo#74138
Task: 2457374
Related: odoo/enterprise#19802
Related: odoo/upgrade#2670
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
The tax_exigible field of account.move.line made it impossible to mix 'on_payment' and 'on_invoice' taxes on the same invoice line, as the base line couldn't be be tax exigible and non-tax exigible at the same time. However, this use case is needed by some countries in order to implement withholding taxes.
To solve that, we totally remove the tax_exigible field from account.move.line and instead compute it on the fly with a domain (also passed to the query_get for SQL queries). An 'always_tax_exigible' stored computed field is also added on account.move, in order to still allow (like before) putting cash basis taxes on a miscellaneous operation without any payable/receivable line and still see it become exigible without needing any payment.
[IMP] account: improve cash basis traceability
A smart button is now available on invoices generating cash basis entries, so see them all at once. The move originally creating cash basis entries is also shown as a field on them.
Task: 2457374
Part-of: odoo/odoo#74138
Refactor the tax group widget with the new JavaScript Odoo Framework:
OWL. This widget has 2 different components, one representing a tax group
and one representing the list of tax groups.
Task ID: #2312900
Initial Task ID: #1986412
Part-of: odoo/odoo#74138
Based on their path, we retrieve snippets assets, assuming that it will
be in the form : /snippets/{snippet_id}/{version}.{scss|js}
Then we check the template definition uses that version, or if any views
or html fields contains a snippet with such version exist.
If not, the asset is deactivated.
For that, we are looking for the data-snippet attribute in snippets
already dropped. For the template definition, we look at the first class
definition if a data version attribute is also defined.
task-2212216
closesodoo/odoo#73005
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
The WebsiteAnimate option was triggering a resize on the window in its
start method, which would lead to a scroll on the wrapwrap and closing
the megamenu dropdown if it was open. Besides that, animations were not
working when selected on a section in a dropdown menu.
Now, an open dropdown that has animated content is considered as the
scrolling element so that its animations are rendered correctly and it
is not closed because of a scroll elsewhere.
The "Launch animation at first time/always" option is hidden for
dropdowns as bootstrap will launch it anytime a dropdown is open.
Part of https://github.com/odoo/odoo/pull/71143
task-2502208
closesodoo/odoo#71143
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This prevents dropping main snippets in the mega menus, but it is still
possible to move the elements inside it or drop inline snippets.
Part of https://github.com/odoo/odoo/pull/71143
task-2502208
Part-of: odoo/odoo#71143
A new class has been added for snippets that should not display their
parents options: o_no_parent_editor.
With that class the editors for the parents of this snippet won't be
created.
Part of https://github.com/odoo/odoo/pull/71143
task-2502208
Part-of: odoo/odoo#71143
*: web_editor
As the mega menu templates are now displayed as an option of the mega
menu snippet, opening the mega menu dropdown in edit mode will display
the options.
Part of https://github.com/odoo/odoo/pull/71143
task-2502208
Part-of: odoo/odoo#71143
*: web_editor
The masonry templates selection SnippetOption has been abstracted so
that mega menus content can also be replaced with template content.
Part of https://github.com/odoo/odoo/pull/71143
task-2502208
Part-of: odoo/odoo#71143
Since [1], a new option was added to the masonry snippet to be able to
switch its whole content to a different template. That option was
working great... until [2] was merged. Indeed since then, each option
change induces an update of the whole editor panel. In this case, this
happened:
- Add a masonry snippet.
- Click inside one of its column (the masonry options and the column
options appear).
- Switch masonry snippet template.
- An option was changed -> Update the whole editor panel... including
the column options... but that column is not there anymore since
removed by the template switching option.
Now, we ignore options whose target is not in the document anymore and
make sure to enable the right options post panel update. This commit
could be backported later on (even though the masonry option was not
available before, the bug is potentially there for community options).
[1]: https://github.com/odoo/odoo/commit/c90ab7b6646b603dcd0a49387b5eeba60ce17f59
[2]: https://github.com/odoo/odoo/commit/2cbb691a84ce186ddd34a2a4c76d95671ed6e834
Part of https://github.com/odoo/odoo/pull/71143
Part-of: odoo/odoo#71143
### Purpose
Allow the event manager to create and manage booths for an event.
They represent physical booths that can be rented (for free or not) at the
event by a sponsor or a partner to present their product for example. Those
booths are gathered under a booth category which is defined by the booth
size, the booth visibility, the rental period or even extra services that
can be offered (non-exhaustive list)
### Specifications
To ensure integration with other modules, it has been split into
six separate modules:
- event_booth:
It's the base module that introduce the new models event.booth,
event.booth.category and event.type.booth. The booth management can only
be done in backend through the dedicated booth views.
- event_booth_sale:
This module introduce a new model event.booth.registration that enable a
booth to be booked multiple time until a user finally pay the related sale
order. A booth sale can be made through the Sales app by using the custom
product configurator after selecting a booth product.
- website_event_booth:
This module adds the website capabilities to booths registration. A new
page is available on the related event and users can book one or more booths
by following the link.
- website_event_booth_sale:
This module adds the website_sale capabilities to booths registration
(e-commerce). When selecting the desired booths the users will add them into
their cart and they will be redirected to the e-commerce flow.
- website_event_booth_exhibitor:
This module adds the website_event_exhibitor capabilities by giving the
possibility to the event manager to create automatically a sponsor by booking
a booth belonging to a certain booth category.
- website_event_booth_sale_exhibitor:
This module is a bridge between website_event_booth_exhibitor module and
website_event_booth_sale module.
### Links
Task-2318655
Upgrade PR : odoo/upgrade#2528closesodoo/odoo#71104
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
This module is a bridge to the Exhibitor module and the E-commerce module.
The only difference from before is that the sponsor informations are stored
in the Booth Registration model and the sponsor will be created at the registration payment.
LINKS
Task-2318655
Closes : odoo/odoo#71104
PURPOSE
This module integrates the Exhibitor module which allows the event manager
to automatically create a sponsor after a booth registration.
To enable that feature an option has to be set on the booth category.
The event manager can also choose what kind of sponsor will be created at the registration.
The frontend flow changes a bit to allow the user to provide his sponsor informations.
LINKS
Task-2318655
Closes : odoo/odoo#71104
PURPOSE
This module integrates the e-commerce module which allows the
event manager to sell booths online.
The flow is the same as before but after the booths selection
they will be added to the user cart and he will be redirected
to the e-commerce flow.
LINKS
Task-2318655
Closes : odoo/odoo#71104
PURPOSE
This module enables the Booths registration on the frontend by adding
a dedicated page on the related event.
The user will have to first select a booth category and then select one
or more booths to book. He will then be asked to provide his contact informations.
The booths will directly be set to unavailable... First come, first served.
LINKS
Task-2318655
Closes : odoo/odoo#71104
PURPOSE
This module allows to sell booths to partners by setting a product and a price
to the booths categories. When selling booths on a sale order it will open the
product configurator and ask the event, booth category and booths.
It's only possible to select booths belonging to the same category for one sale order line.
A new model is introduced by this module :
- Booth Registration that allows multiple registrations to a booth.
The booth will be set unavailable when the sale order linked to the registration is paid.
All the others registrations will be cancelled
LINKS
Task-2318655
Closes : odoo/odoo#71104
PURPOSE
This new module adds a booths management capabilities to the event module.
The event manager will be able to manage booking to physical booths hosted
at his event by first creating several booths categories depending for example
on the booths size, the number of tables, extra services, ...
He will then create the actual booths to offer to the final users.
This module adds two main models :
- Event Booth Category which is used to differenciate the booths type.
- Event Booth which is the actual Booth that will be booked.
The booking is done directly on the booth form view by setting a partner and
his contact informations and by setting the booth state to unavailable.
If the event manager want to book a booth for later use he can set the state
to unavailable without setting a partner.
The booking of a booth will be displayed in the chatter of the related event
to ease the event manager overview
The user manager can use event template to adds booths by default when setting
the template to an event.
LINKS
Task-2318655
Closes : odoo/odoo#71104
PURPOSE
The is_finished computed field was added in order to avoid
displaying the booths on the registration page and warn the
user with a message.
LINKS
Task-2318655
Closes : odoo/odoo#71104
PURPOSE
Before this commit we had to pass parameters through the context to get
them to the _website_product_id_change() method.
After this commit we can pass the parameters through the kwargs parameter.
LINKS
Task-2318655
Closes : odoo/odoo#71104
yhu-odoo