The account module needs to import Form from "tests.common" causing a
traceback when websocket-client module is not installed.
As this module is only required for the tests, there is no reason to add
it to the "requirements.txt" file.
With this commit, Odoo account can be installed even when
websocket-client is not installed, in that case, the HttpCase tests that
needs to run Chrome headless will be skipped with a warning.
Closes: #26404
Usecase to reproduce:
- Check manufacture to resupply and manufacture in 2 or 3 steps
- Uncheck manufacture to resupply
pbm and sam rules in global route(mto/manufacture) are still active
It happens because the condition to archive the rules was not complete
the check on manufacture to resupply was missing
Some fields are required only when defining an activity-based server
action. Required domain was not correctly written leading to server
actions being blocked.
warning: Some modules could not be started
Missing dependencies: web.field_utils
Non loaded modules: web.dataComparisonUtils
This commit moves 'data_comparison_utils.js' from 'assets_common'
to 'assets_backend' because 'field_utils' is only defined in
'assets_backend'.
There were tooltips on period options in the submenus of
filters menu. With the switch to Bootstrap 4, the html
structure of filters menu has changed (no more 'ul') and has
altered the way the menu items are rendered causing the
disparition of tooltips. With this commit, the tooltips come
back.
As the phantomjs project was suspended[1], there was a need to change the js test
engine. Moreover, the engine was rather old and leading to non
deterministic crashes.
Chrome headless was choosen for simplicity and the long term vision of
the devtools protocol [2].
The 'phantom_js' method still exists but will be deprecated in
favor of 'browser_js' with the same parameters.
In order to communicate with the browser, the python websocket-client package
is needed.
[1] https://github.com/ariya/phantomjs/issues/15344
[2] https://chromedevtools.github.io/devtools-protocol/
#closes 25991
It used to work by chance with Bootstrap 3, but since we are now
using Bootstrap 4, the fake good appearance collapsed, revealing
the awful structure it used to have.
Adds a checkbox to import columns (in debug mode) allowing a user to
create records M2O and M2M records not found (via name_search).
Task ID: 1850633
* uses a context key to avoid altering basically all the import callstack
* attempted to lift the creation in the `_str_to_*` functions and create
m2m via commands, but that doesn't really work out
and use it to determine if the constraint definition was changed. This prevents
endless readding of constraints that are reformatted by postgresql in an
unrecognizable way (in which e.g. "CHECK (credit*debit=0)" becomes
"CHECK ((credit * debit) = 0::numeric)")
Before this commit, the error message was not very helpful as did not specify
which statement was problematic.
By giving the reconciled name/number, the users get's a chance to identify the
offending entry and correct it.
Closes#26356
It was already present in the accounting and purchase application but not in
sale menus.
Apply the same logic as in purchase and use a group_no_one
Closes#22862
Before this commit, there was a traceback when attempting to mark
all messages as read from the 'Inbox' of Discuss.
This is due to resetting the 'needaction' counter on threads that
do not not track 'needaction', such as the 'Starred' mailbox.
In fact, only channels do track them and handle a needaction counter,
so this should only be applied on channels.
The custom filters created through the search view are still private by default
but the ir.filters created manually (e.g. through xml files) are most of the
time global.
In odoo core addons, all ir.filters defined add the line
<field name="user_id" eval="False"/>
This should simplify the development while not changing the behaviour for
actual users.
Closes#8218
Search, form views and menu cleaned
Hide attachment button when you can not attach (record not created)
Allow to submit multiple expenses of different payment mode
list: show creation date on reports, accounting date for accountants
Tests from hr_recruitments work luckily until now.
Because module maintenance imply base.group_user for group_equipment_manager
<record id="group_equipment_manager" model="res.groups">
...
<field name="implied_ids" eval="[(4, ref('base.group_user'))]"/>
</record>
and module hr_maintenante imply group_equipment_manager for hr_user
<record id="hr.group_hr_user" model="res.groups">
<field name="implied_ids" eval="[(4, ref('maintenance.group_equipment_manager'))]"/>
</record>
After this commit launch test on hr_recruitment module without any other module will works.
Design-theme repo show this error because repo tests hr_recruitment without installing maintenance
(Repo install website_* modules -> website_hr_recruitment -> hr_recruitment -> hr)
In some countries, it might be preferable not to recon the payments journal entries at the time they are registered in the system, but to do so at the date of the bank statement line they will be reconciled with.
Thus, to manage this we've added an option on bank journals to have payments generating draft account.move when they are validated, and posting them only after bank reconciliation (+overwriting their date)
Was task 1870892
Was PR #26349
As fbbf24f58a introduced multiwebsite and `website_published` became a
related and/or a computed field (depending of the mixin), we should not order
on this field as it is not on DB anymore.
We now have the field `is_published` that replace `website_published`.
Turns out %s is not the pattern for sub-minute seconds, that'd be
%S (note the casing). The former is the number of seconds since
epoch, which tends not to match sub-minute second patterns (sounds
like bull to me but there you are), and so importing datetimes was a
bit broken since the previous improvements.
Fix that.
Update the query count to avoid the runbot to be randomly red
Temporary fix!!!!! Will need to check with in details what is the
cause of this.
Those are the changes for the second part of test
In event_sale it is possible to have one product representing several tickets. But before this commit, on the sale order and invoice the client only saw the name of the product and didn't know which event/ticket they subscribed to.
The goal of this commit is to overwrite that behavior whenever a sale order or invoice line is related to an event ticket, to show the ticket name and event name instead of the product name.
Technically, the following changes have been done:
----------------------------------------
* various: add a method to compute a default name for a SaleOrderLine, based on its product
I added the method because the code to compute the name was duplicated in several places. This will make it more consistent.
Moreover this gives the option for modules to override the method to define a custom name as necessary.
----------------------------------------
* event_sale: compute a consistent description for a SaleOrderLine based on an EventTicket
The description will be the same whether the sale order comes from the front end or the back end. It takes into account the customer language.
The default description will be computed as follow:
1. The ticket name should be the first line of the product description on the SO.
2. The event name should be the second line of the product description on the SO.
To compute the ticket multi-line description we decided to ignore entirely the product name and the product description_sale because they are considered to be replaced by the ticket name and event name.
We also ignore them because the work-flow of creating a new event does not lead to filling them correctly, as the product is created through the event interface.
----------------------------------------
* event_sale: improve sale order line and event registration views
It was possible to select a ticket related to a product before an event was selected.
This is typically the case for tickets defined in an event_type but not in an event.
The ticket field is now hidden until both the product and the event have been selected.
This way we are sure the selected ticket will belong to an event and not an event_type.
We reset the ticket on event change because we don't want the user to be able to select a ticket belonging to the wrong event.
We also improve here the comments of the related on-change methods.
----------------------------------------
* website_event_sale: update views to show ticket name and event name
The standard behavior was to show the product name in several places instead of the sale order line description.
However, for event tickets, we don't want to show the product name, but the ticket name and event name instead.
----------------------------------------
* website_event_sale: add ticket on confirmation page
The ticket name was missing from the registration confirmation page (shown when the ticket is free and/or the user paid with a direct method). This is now fixed.
----------------------------------------
Task: 1837987
PR: 25819
- Instead of adding the "timesheet" statbutton on the invoice's
buttonbox, this inherit view is adding a new buttonbox which causes
conflict with the original buttonbox.
This adds a button to import several bills from the accounting dashboard: will create a new vendor bill for each, with the file attached to it. That file will be visible in the chatter (in enterprise) and allow easilly completion/encoding of it. This task also comes along with the import/export of xml files attached to the PDF files created from the invoice report.
Was task 1859277
Was PR #26339
PO that can be linked to an invoice are filtered via a domain
restricting the partner. However when no partner is selected yet, the
domain was `('partner_id', 'child_of', False)` which, beside being horribly slow, was also useless as it returns ALL partners.
Only generate a meaningfull domain.
Christophe Monniez