* website_slides
The app was still using an old BS3 variables that happened to be created
by the website_slides app (that is why the bug was not noticable
on runbot).
In enterprise version, the select elements have a custom style. For it
to work, the "appearance" CSS property must be understood... which is
not the case in most browser without vendor prefixes.
As discussed in https://github.com/odoo/odoo/commit/770aec399c4e6e29cfc5854318cbda19a605315d,
vendor prefixes are added by post-processing the scss generation.
Before this commit, when cliking on "mass mail attendees" on a event form
the default domain on the attendees for determining the mass mailing recipient
was lost in an onchange
After this commit, we retrieve the right domain
OPW 1869308
closes#26081
This reverts commit 4e5f826ce5
for two reasons:
1) A lot of people are working with splitted desktop screen and
will see the view switcher/search as on mobile: it's not efficient.
Only the burger menu should have been visible for the tablets,
not the other mobile features.
2) When you switch between vertical mode and H mode, we don't want
to change the mobile mode because widgets aren't reinstantiated and
some features don't work.
For example, the burger menu is broken if you switch from H mode to
V mode.
Task-1869468
This commit allows the user to link some mail template to activity type
with res_model.
When a activity has template, buttons appears in activity, allowing the user
to send mail based on templates.
Task: #1844563
PR: #25620
Open the web/database/manager and create a db with a country set.
The country of the first company will be set to the country set on the form
Before this commit, the currency was not set, eventhough it is a field
on res.country
After this commit, we also set the currency of the first company
opw 1869435
closes#26097
Create an asset and confirm it.
Click on Sell or Dispose
The form view of the disposal move opens
With the breadcrums, back to the asset
Click again on sell or dispose
Before this commit, literally nothing happens
This is because there is no more business to do
After this commit, in the case there is no business to do
we fallback onto the smartbutton's action
OPW 1864318
closes#26086
Before this commit, the function that computes the aged partner balance
could return a list instead of a dict if no partner were found
After this commit, we make the function's signature consistent
closes#26095
This commit updates the demo data in order to have a beautiful dashboard
when using the standard demo data.
It also enables us to display false in a graph view when using a boolean
measure, previously this was considered an empty value, as many2one
fields use false to indicate that they are empty hence we were
displaying undefined instead of false.
Task #1844742Closes#25944
In the graph view, by default the value false was considered to be a non
set value (which is the case when dealing with M2O fields). But in the
case of boolean fields, we want to display the value false.
Before this commit, saving a file being watched by watchdog
(--dev=reload) with vim (and possibly other text editors) would
crash the server via a KeyboardInterrupt error.
This happens because vim, emacs cause multiple filesystem events to
happen when saving a single file, the FSWatcher registers these events
as multiple SIGHUPs which in turn calls restart() multiple times in a
very small amount of time which makes the KeyboardInterrupts completely
shut down the server
This is fixed by only calling restart() if odoo.phoenix is False, since
catching a SIGHUP sets it to true.
Fixes#21178
Special thanks to @odony for the help :)
This field is used by the multiple payment wizard; the payments it generates are always individual and should never have multi=True. Before this commit, they did, because of the values given in context when calling the payment wizard.
When archiving records through the generic toggle_active methods we now
remove ongoing activities.
Purpose of this commit is to avoid having ongoing activities in the systray
linked to archived records. As archiving records means we won't work on
them anymore it makes no sense to keep related activities.
Purpose of this commit is to speedup tracking values creation by manually
creating them using the newly-introduced multi create. As tracking values
creation is already done manually as sudo when creating mail message we
just update the code to directly insert them as multi.
This commit is linked to task ID 1870656 and PR #26068. No functional change
should occur with this commit.
Commit 896e36edab added support of multi insertions when creating new
records. This had a great impact on mail-related tests involving several
followers update. This commit updates the counters to match the current
runbot state on master.
This commit is linked to task ID 1870656 and PR #26068. No functional change
should occur with this commit.
This reverts commit 2054b59285 which
already has been fixed multiple times [0].
However this change does not correctly handle successive onchange calls on
ony2many fields which alter existing rows.
i.e., in saas~11.4, an onchange has been added on move lines [1] in
order to create and/or update lines containing taxes amounts.
However, with diff-only onchange, a second call to onchange will discard
changes made by a first one as nothing change between the 2 calls.
Scenario: On an existing account.move, add a new credit line with a tax set.
The first onchange will update the tax line with new amount. Add a
second line (with debit amount balanced). The onchange will not change
the tax line, resulting as it value being reset to initial value. As a
result, the move is not balanced and cannot be saved.
[0] cd2ccc4110, 5e58ac16c3, 07023137cd
[1] d49ab568a2
This field is used by the multiple payment wizard; the payments it generates are always individual and should never have multi=True. Before this commit, they did, because of the values given in context when calling the payment wizard.
This issue was introduced with the following commit
https://github.com/odoo/odoo/commit/a4d6bff197b894f70eaecf5aa4e2088e5b014780
The problem is that during the task #58961 we changed the API to
generate the sale_report, but forgot to include the
website_sale_dashboard sale_report, hence when accessing we had a
traceback since this file was using the old API.
Task #1869500Closes#26070
qsm-odoo