In a flow where the reservation is used (internal transfers, deliveries,
...) adding a new stock move line is now made from the quantities
available in stock. The 'add a line' button in the show detail wizard
trigger the quant list view to directly pick the wanted lot or location
where the stock is available. Only the quantity done is needed to be
updated before the validation.
This commit remove the 'quant reserve wizard' as the behaviour is an
extension of it.
Task: 3256447
Part-of: odoo/odoo#117513
This commit changes the process flow of stock pickings. A new picking will
always be created in immediate transfer mode and 'ready' state. From
their, it can be validated directly or 'reset to draft'. This second action
switch the immediate mode to planned mode and reset the state as draft.
From their the classical workflow is processed
confirm -> (assigned ->) validated
Task: 3256447
Part-of: odoo/odoo#117513
Purpose
=======
Never select the white color for the properties tags, it should be
selected manually, because usually the white color is used to not show
a tag in the kanban view (and that color is never automatically
selected for normal many2many_tags widget).
Fix the alignment of the property label.
Task-3208449
closesodoo/odoo#114200
Related: odoo/enterprise#38944
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Like standard avatar widget, we want to open the chat window of a user
when clicking on a many2many / many2one avatar property.
Task-3208449
Part-of: odoo/odoo#114200
- Add missing account tag on repartition line taxes to fix the report 104 amounts for per tax
closesodoo/odoo#121588
X-original-commit: 368ef541466933dfe647150d58227c32035100e7
Signed-off-by: Josse Colpaert <jco@odoo.com>
- Create a Deferred Revenue Model on a Current Liability account
- Create a Sale Order yourself (User 1), with Salesperson User 2
- Create the invoice from it
- Remove the salesperson from the invoice and add User 3 instead
- Change the account to the Revenue Model's one
- Post the invoice
- Post the deferred revenue created
=> User 2 is follower of the entries generated
The problem is that the context comes from the sales order, and
contains a `default_user_id` in the context.
The solution provided is to remove it from the context given, as
it serves no purpose (the invoices are already created).
opw-3141495
closesodoo/odoo#121581
X-original-commit: c3df8fc0da2f359ac0a47695ef37aa8869063092
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
Swiss taxes retrieved by module update (and the update of taxes it triggers)
need to be active, even if the template data was set to inactive.
closesodoo/odoo#121580
X-original-commit: 04f0be5
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Claire Bretton <clbr@odoo.com>
If a tax is an aggregation of its sub-taxes it makes sense to have no
repartition line. This PR relaxes the validation in that case.
X-original-commit: a82404db4370c9b8f3ae1c58f1702abc98de0881
Part-of: odoo/odoo#121580
Switzerland changes its rates at the beginning of next year,
this change already has some implications on client's flow so
we add them to the localization so they can coexist with old rates till
the end of the year.
Changes:
- Added new taxes (2.5% -> 2.6%, 3.7% -> 3.8%, 7.7% -> 8.1%)
- Added tax fiscal positions to match those taxes
- Added tax groups
- Adds migration script to l10n_ch to apply those changes
Task: 3162286
X-original-commit: acd14e6f7f91755ea9b058eb7ab957b133266145
Part-of: odoo/odoo#121580
Steps to reproduce:
In the kanban view of projects, modify the `is_favorite` field
of a project and apply the "My Favorites" filter.
Cause:
No change is saved.
Solution:
Add autosave for the boolean favorite field.
opw-3291991
closesodoo/odoo#121499
X-original-commit: d1d6f016331c69441c9d3ec7927ed7224c06feec
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
A new POS config with the name `Shop` is created when a new company is
created with a dedicated fiscal postion and if `point_of_sale` is
installed. A `Bank` payement method is created for the POS, as well as a
`Customer Account` payement method. If a there is a cash journal that is
not already linked to a payement method it would create a cash payement
method for the dedicated POS. If the module `pos_restaurant`is installed
it would also create a POS config with the name `Bar` of type restaurant
with the same specification as for the normal pos config `Shop`.
Since the changes create default configs along with payement methods,
there was some conflicts with the test instances. Therefore the payement
methods where unlink in the set up of the test to resolve the conflicts.
task-3244511
closesodoo/odoo#119221
Related: odoo/enterprise#41003
Signed-off-by: adgu-odoo <adgu@odoo.com>
Currently when user tries to share the survey and the access mode is public
(Anyone with the link) , the 'Send by email' button is flickering and not
working properly.
As we have used the widget 'boolean_toggle' it saves everything on Change,
and as a result compute function '_compute_send_email' was called every time
which is not required and caused toggle button to deactivate itself
automatically.
This commit fixes the issue and 'Send by Email' button does not flicker and
works properly by using autosave='False' used from
(https://github.com/odoo/odoo/pull/117103).
Recipients (partner_ids) field is set to required in XML.
Hence we stopped the widget from saving on Change and hence a result every time
compute method is not called and toggle button maintains its state.
Task-3240813
closesodoo/odoo#120236
X-original-commit: 7962a7b751e18cea55b6f72208583931beec6b08
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
- Adds early pay discounts, cash dicounts accounts
- Sets the ecuadorian chart of accounts as updatable (same as most
localizations)
- Fix the account type, many should be liability current and not liability payable (otherwise the usage of these accounts affects the payable/receivable reports)
closesodoo/odoo#121579
X-original-commit: ba837dc3023327dd5bdb3cf579c59e76cbe73bbf
Signed-off-by: Josse Colpaert <jco@odoo.com>
The note "Quotation viewed by customer" posted when a public/portal user
access an order came with the order's partner name instead of the actual
user's partner name
This made confused for internal users to see something in internal note
like **Colleen Diaz** with a message **Quotation viewed by customer
Nicole Ford**
This commit makes sure to use the right partner name except the
quotation is viewed anonymously (with access token)
closesodoo/odoo#121571
X-original-commit: 8e37dcee1f5106e69d5784439e2657acf5706e4e
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit, when a cookie bar was displayed on a page and
elements of that page were animated (on scroll and on appearance), those
animations did not work while the cookie bar was present. This commit
fixes that and enables animations even if a cookie bar is displayed. The
problem was that we were looking to see if a modal (cookie bar, popup)
was displayed and if it was, all animations were based on the scroll
height of that modal. However, this should only be done for elements
that are in the modal. The other elements should always base their
animation on the scroll height of the page.
task-3151000
closesodoo/odoo#121543
X-original-commit: 406fc8a59a36313f382a34aaba143ab2a9845718
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Dieleman Guillaume <gdi@odoo.com>
- Impacted modules:
- project_todo (new module)
- note (deleted module)
- project
- mail (test adaptation)
- test_discuss_full (test adaptation)
- Changes summary: The application Notes is removed and replaced by a
new app To-do. This new app is based on the model project.task and other
related models, allowing to have a nice link with project. To-dos are
actually private task that are displayed in both Project and To-do
app. The reason why To-do could be used is that it introduces clean
views and simplified widgets to work on these tasks/to-dos.
- Commits description:
- ***[ADD] todo, note,...: replace Notes with To-do***: Deprecation
of Notes and create of To-do (module project_todo). The model
project.task is slightly modified to be able to be used in the
module project_todo (mainly security and personal stages management
methods). Views and activities are adapted to the new model.
- ***[IMP] todo: make the name of a to-do editable from the
breadcrumbs***: The name of a To-do is made editable directly in the
breadcrumbs.
- ***[IMP] todo: add conversion form for todo->task***: A new action
is introduced in To-do to be able to convert a to-do to a task in a
project.
- ***[IMP] todo,...: add an onboarding to-do***: An onboarding to-do
is added to describe the functionalities of the new app to the
users.
- ***[IMP] project: avoid to add OdooBot as default assignee on
tasks***: Improvement of the UX for both Project and To-do.
- ***[IMP] todo: integrate mark as done in To-do app***: This commit
introduces a new widget in To-do that can be used to set a to-do as
done. This widget used the new states recently introduced in Project
but present them in a simplified binary value in To-do.
- ***[MOV] project_todo: rename module todo to project_todo***:
Technical renaming to avoid confusion.
- ***[REM] note,...: remove module note***: Removing of module note.
task-3085077
closesodoo/odoo#115390
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
When creating payment links for the customer, the user can now decide on a partial amount to be
paid at the time.
Use case: when the customer cannot pay the SO amount with one payment, e.g. limit on the credit
card, the user will now have the possibility to set a partial amount on the payment links.
The order will be automatically confirmed when the amount chosen is equal to the remaining amount
to be paid.
Additionally, the customer will be notified by email for each payment done instead of only at the
confirmation of the order, which will happens only once the total amount is paid.
Task - 2672713
closesodoo/odoo#109661
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: Horacio Tellez <hote@odoo.com>
Co-authored-by: Morgane Demesmaeker <edm@odoo.com>
After uninstalling the stock module on a database which also has the purchase
(and purchase_stock) module installed, the qty_received_method is removed for
purchase order lines handling the reception of the products through the stock
module (qty_received_method = 'stock_moves'). Because of this, a recompute
is triggered on the qty_received, setting it to zero.
This leaves the purchase order in an invalid state (the received quantity did
not change through the uninstallation of the stock module), additionally the
problem cannot be corrected, since the receiving method is not set to manual.
Functionally, the uninstallation shouldn't update the purchase orders, instead
they should be decoupled from the associated stock moves. To this end, an
ondelete handler is added for the stock_moves selection option.
Steps to reproduce:
- Install Purchases app
- Install Inventory app
- Create a purchase order with purchase lines and quantity > 0
- Confirm the purchase order
- Click on receive products
- Click on validate
- Uninstall Inventory app
- Check that the purchase order lines have the received field set to zero and
it is not editable
opw-3006951
closesodoo/odoo#121549
X-original-commit: cedd0603a24aa0c0e6716c2e0f49e89c870eae04
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: De Caluwé Tom (tdc) <tdc@odoo.com>
Co-authored-by: Pedro Manuel Calheiros Lima de Sousa (peso) <peso@odoo.com>
This commit implements the functionality of using backspace key to
delete values in relation filter.
task 3324738
closesodoo/odoo#121513
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Steps:
Material Resources list view.
On a record, set roles A and B, default role A.
Now, delete role A from roles.
Issue:
Default role should be set to B, but remains A.
Cause:
The onchange return the right response.
The StaticList data is updated properly.
The issue is that this function is async, and we don't wait
for all that to be done before notifying the model.
Fix:
Wait for the result (await).
task-2959882
closesodoo/odoo#119214
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
When an error of type "ConnectionLostError" arrives in the PoS, we catch
it in order to warn the user. In the catch, a bad detection of the
instance of this error was made which blocked the flow by throwing
an error.
We were checking whether the error message was an instance of a
ConnectionLostError in a way that assumes that the error was a legacy
error which is no longer the case since the POS no longer uses the
legacy rpc service. This commit adapts the instanceof check
The necessary changes have been made, it now works.
closesodoo/odoo#121536
X-original-commit: 963ea1c5779fbf7af7d5421a294ca2a24d7940af
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Monnom David (moda) <moda@odoo.com>
`account_peppol` hooks its addition of `option_peppol` in the invoice
sending form to `option_send_by_post`.
However `option_send_by_post` is added by `snailmail_account` which
`account_peppol` does *not* depend on. And while it's likely
`snailmail_account` has long been installed when `account_peppol` gets
installed there's no actual guarantee, and `snailmail` could even have
been uninstalled.
Which is exactly the issue, when uninstalling `snailmail_account` or
any of its dependencies which don't uninstall `account_peppol`
(`snailmail`, `iap_mail`, `iap`) the "send & print" (send invoice)
wizard is broken.
Fix by re-hooking the view extension on `option_send_mail` instead,
that is installed by an actual dependency of `account_peppol`, and
part of the view which `account_peppol` actually extends
(`account.account_move_send_form`).
closesodoo/odoo#121522
Related: odoo/enterprise#41124
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
When validating leaves they generate a bunch of ancillary
objects (calendar events, resource calendar leaves).
When deleting leaves, those don't get removed, which is an issue when
uninstalling then reinstalling the module: because leaves use the
resource calendar to check availability, and how many working days the
leave covers, and because leaves must cover at least 1 working day
it's possible for the leftover calendar leaves to prevent creating hr
leaves.
Solve the problem by canceling the leave when it is deleted. This
should not be too much of an issue when deleting a leave normally as
`_unlink_if_correct_states` prevents deleting validated
leaves.
Sending the notifications is suppressed during uninstallation (seems
like most people involved would be aware the "time off" module is
getting removed), but for the case of a manual deletion it is probably
useful, especially as notifications are only sent for leaves in
`validate` and `validate1` states.
Part-of: odoo/odoo#121522
On install, `hr_work_entry_contract` only associates work entries to
contacts which are open or closed.
However during its execution (?) `hr_work_entry_contract` generates
entries associated with `Mitchell Admin Contract`, which is a draft
contract. As a result, when uninstalling then reinstalling
`hr_work_entry_contract` it is not able to re-associate the entries to
the contract, and thus can't reinstate the `required=True` on
`HrWorkEntry.contract_id` either, which is a "reinstallation failure"
on the CI.
A simple solution is to create the contract closed, though it would
also be a good idea to not be able to create work entries associated
with a draft contract either, maybe?
X-original-commit: 6b7f3f6ec40eb819dd1d94a94722610a63d5697a
Part-of: odoo/odoo#121522
Since the "dirty flag" refactoring of
384fda2c2a
`IrModelFields._prepare_update` did not cope well with fields missing
from the python-side models, which can during uninstallation for
custom fields (possibly because the script loads the registry
incorrectly, not entirely clear).
Because of a custom field created by worksheet linking to it, the
removal of the `project.task` table would fail, making the
reinstallation of project fail to restore several constraints.
This case was actually handled correctly just a few lines above when
trying to resolve field dependencies, both record and field would be
checked for their presence before actually trying to use them.
Getting the model from the registry / environment has not been noticed
to break uninstallations, but might as well do that too so everything
lines up, and just in case.
X-original-commit: 05aca6ee4ce795b85b90430efd761f0cd3a6d5a3
Part-of: odoo/odoo#121522
Issue discovered in the uninstall (and reinstall) of sale_project: a
dump has ~100 tasks, when reinstalling `sale_line_id` has to be
initialised, this is done by marking `sale_line_id` on all extant
tasks as to-recompute, which triggers their computation on the next
`flush`.
Because it's a recursive field, `Field.recompute` ensures only one
record at a time gets recomputed (as there could be cross-dependencies
in the recorset which protection would prevent from resolving).
As the field computation runs, it accesses itself, which triggers a
cache miss, which triggers a `_fetch_field` (to get the currently
stored value), this calls `_read`, which flushes the field we're
trying to read.
The problem here is that for efficiency the cache miss will look for
all records in the cache without a value for the
field (`_in_cache_without`) and try to `fetch` on them as well. This
means rather than not doing anything in flush, we're going to
`Field.recompute` on all records except the one selected the first
time around, which repeats the cycle until there is no more additional
record found in `_in_cache_without`, which could trigger the next
round of `recompute`, and the entire thing unwinds, and we probably
perform a ton of unnecessary additional `compute_value`.
Except that doesn't even happen, because the process from one compute
to the next takes 12~13 stack frames, which given the default
recursion limit of 1000 gives a hard limit of 76 fields before hitting
a RecursionError. As this is less than 100, a recursion error [is what
we get](https://runbot.odoo.com/runbot/build/31726625).
In 15.2, this was fixed by only expanding the fetch on non-recursive
fields, pessimizing recursive
fields (5c2511115b14299516fce4aa3737a62faaf5b653). Test-wise this only
impacted mail performances and in a relatively minor manner.
In 16.0, the mail tests actually match already (so that part was
skipped by the cherrypicking) however this impacts the knowledge perf
tests much more significantly e.g. `test_article_creation_multi_roots`
gets +9 queries when creating 10 top-level articles, which is a bit
much.
So use an alternative which is ugly as hell but which I didn't
consider for 15.2 (may want to backport it one day if the current fix
is an issue): catch the recursion error and use the existing
fallback (of fetching just the requested record's field without
expanding the recordset).
This likely makes for a pretty inefficient situation in the original
case as we're certainly going to hit the recursion limit repeatedly,
but that still fixes the issue, and it avoids deoptimising cases which
fall short of the recursion limit (resolving under 60 records or
so).
Plus despite creating giant stacks we might actually get good
efficiency as we're going to hit recursion limits repeatedly but
that's pure python, once we fall below the limit we can resolve
everything at once with a single SQL query (or something along those
lines).
X-original-commit: 9e71094582ec4c9b719431e77538da8f91ffa9e3
Part-of: odoo/odoo#121522
Uninstallation does not cope well with `setup_models` being performed
unconditionally as those will dramatically alter registry states, and
resurrect computes which the uninstallation has disabled: rather than
try to update registry models in-place (which is rather fraught) the
uninstallation deletes the columns, tables, and `ir.*` reflection
records and only after all of that is done does it reset the registry.
This means while it does fix up the registry caches (`field_depends`
and `field_triggers`) as it goes, resetting those may cause the
recomputation of fields whose columns have been deleted, possibly
based on dependencies whose columns have also been deleted.
As such these kinds of manipulations should either be performed in
`@ondelete` methods which don't get executed during uninstallation, or
they should be gated behind an uninstallation check.
In crm the latter is necessary, as `ondelete` runs before `unlink`
actually executes, and the registry reset would run too early (and
unnecessarily).
In base, only the latter is possible as we're not in `unlink` itself,
instead `IrModelFields._prepare_update` is called *during*
uninstallation and its trailing `setup_models` causes the issue.
X-original-commit: 357b9f2c9fd44e14e5b7c9d3c17f1794691986f3
Part-of: odoo/odoo#121522
When modules get uninstalled, first the uninstall process will drop
all the fields (removing all the columns) then it drops all the
models (removing the tables).
When uninstalling mail, this means the various (res_)model(_id) fields
don't exist anymore by the time we're deleting models, so the queries
blow up.
Skip this step if we're unlinking the mail models, it means the tables
have already been dropped, so there's nothing to delete anymore. This
should not use `ondelete` because we *do* want to delete records from
those tables when deleting modules which depend on mail, and thus have
mail stuff associated with their own models which we're deleting.
X-original-commit: e43155f940c1f0ba30378d110fc371012d791e32
Part-of: odoo/odoo#121522
Confusion between uninstall hooks can apparently trigger errors during
uninstallation as two hooks can confuse one another?
In this here case, the issue triggered during the uninstall hook of
`account_accountant`, which apparently combines with the uninstall
hook of `industry_fsm_sale` to trigger an invalid in-memory state for
`project_project`. An implicit flush during the hook then blows up
with a check constraint error.
Flushing at the end of the `industry_fsm_sale` hook or at the start of
the `account_accountant` hook fixes the issue, so might as well flush
after each hook to ensure whatever they did using models is pushed to
the database and in good shape (hopefully).
X-original-commit: b28e9a7066d29d395421a11df2b9e170fb20d35a
Part-of: odoo/odoo#121522
There is no action that uses the search models/components available in
the legacy control panel. We remove those.
closesodoo/odoo#121433
Related: odoo/enterprise#41078
Signed-off-by: Géry Debongnie <ged@odoo.com>
RATIONALE
Purpose of this change to rewrite the formatting done on messages displayed
on simple frontend i.e. portal chatter widget and project chatter.
We stop calling 'message_format' which computes a lot of unnecessary data
and sends too much information to frontend. We choose to instead manually
handcraft the returned data, already tailored for frontend widget.
SPECIFICATIONS
Remove call to '_message_format' in 'portal_message_format'. Instead have
a list of properties (fields or computation based on fields e.g. rating publisher
information) that can be overridden in sub-addons. Use those to generate
the data used by frontend chatter widget.
Remove extra formatting or data computation done in JS files. Do it directly
in 'portal_message_format' in order to have clean information sent.
This change targets mainly portal and portal_rating. Making those modules
Independent from backend message formatting allows to save queries and
also to avoid sending useless information to the frontend.
SIDE SPECS
Improve 'message_format' tests, and make new specific test for its portal
counterpart.
Provide some fixes for bugfixes that occured during the testing of this
task. Those are not crucial for stable, so currently kept in this master PR.
Task-3322905
closesodoo/odoo#121104
Related: odoo/enterprise#41056
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this commit is to add performance tests for 'portal_message_format'
that is used when displaying chatter in frontend (e.g. customer portal). It
allows to keep an eye and to optimize part of that code allowing cross-apps
optimization.
Task-3322905
Part-of: odoo/odoo#121104
Current rule to edit publisher fields (comment, ...) is to have the editor
group. However when having only portal, this group does not exist. The
feature should work as a standalone feature without depending on website.
The rule is then updated as follow: either the current user belongs to the
editor group (if it exists), either it can write on the related record
(given res_model / res_id).
Currently no crash in standard addons occur because its main usage is in
eLearning application, where editor can answer and update publisher comment
from the frontend (course review).
Task-3322905
Part-of: odoo/odoo#121104
Currently when modifying publisher comment, publisher partner id and date are
synchronized if not given in order to always have coherent values. In this
commit we do the same at create. Even if won't happen frequently better ensure
values coherency. Moreover it helps writing tests.
Task-3322905
Part-of: odoo/odoo#121104
'legacy' parameter was present only for a specific part of attachments
formatting. It was used only for portal, as the widget used in frontend
was not using the 'discuss' orm-like convention.
As portal formatting is now independent from mail/discuss formatting this
can be safely removed, simplifying the API.
Task-3322905
Part-of: odoo/odoo#121104
RATIONALE
Purpose of this change to rewrite the formatting done on messages displayed
on simple frontend i.e. portal chatter widget and project chatter.
We stop calling 'message_format' which computes a lot of unnecessary data
and sends too much information to frontend. We choose to instead manually
handcraft the returned data, already tailored for frontend widget.
SPECIFICATIONS
Remove call to '_message_format' in 'portal_message_format'. Instead have
a list of properties (fields or computation based on fields e.g. rating publisher
information) that can be overridden in sub-addons. Use those to generate
the data used by frontend chatter widget.
Remove extra formatting or data computation done in JS files. Do it directly
in 'portal_message_format' in order to have clean information sent.
This change targets mainly portal and portal_rating. Making those modules
Independent from backend message formatting allows to save queries and
also to avoid sending useless information to the frontend.
Task-3322905
Part-of: odoo/odoo#121104
Purpose is to improve the depth of 'message_format' performance tests by being
multirecords-enabled, in addition to being multimessages enabled. We also add
more 2many fields in order to better see their effect (notably link previews
and reactions, recently added).
Task-3322905
Part-of: odoo/odoo#121104
Update counters to match current runbot state. Several changes (ORM, mail
code organization) lead to some counters being obsolete.
Task-3322905
Part-of: odoo/odoo#121104
For performance reason, we avoided computing goals for the set of users
that didn't log in recently (See ec0c0f29).
However, users can stay logged in for a while without having a new "log
in event" (password asked), such that active internal users can keep
old values in their challenges when reports are sent, which is not good.
Until an improvement can be implemented in master, we drop this time
constraint for active internal users.
A test is added, checking the behavior of the method called by the cron.
Task-3226408
closesodoo/odoo#121506
X-original-commit: 6c77dd822c719a2181bac1d69130e5c4e8ef70fa
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
1- Create a BOM for a product, define an Operation on the product
2- Link a Google Slides document to the Operation as the Operation Worksheet.
3- Define an instruction on the Operation
4- Set Step Document to Specific Page of Operation Worksheet and define a page.
Issue: The step will not load the document.
Cause: tablet.js passes the wrong value to let know the viewer is a google slide url. Also when the good
value is passed the viewer always show the first page. That's because the SlideViewer has the page set in the
setup() method so it never change despite we change the step in the same document.
opw-3165142
closesodoo/odoo#121477
X-original-commit: 2160115647932ef86db3afc59b7f193075c94fd0
Related: odoo/enterprise#41098
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Djoumatchoua Eteil Junior (etdj) <etdj@odoo.com>
Steps to reproduce:
- Log in as admin
- Install `eLearning` module
- Create a course and add a youtube video as a lesson
- Publish the course
- Go to the website and click on the course
- Enable `Editor` mode (top left corner)
- Click on lesson to open it in fullscreen
- Click `Back to course` button
Issue:
Video is playing in the background.
Same issue occure with video snippet in the website editor (by default
video is mute but still playing in the background).
Cause:
When editor mode is enabled, there is a fallback iframe that clone the
content of the current page that we leave into it.
Since the youtube video has `autoplay=1` in the URL, it will
automatically start in the fallback iframe.
Solution:
For regular website pages, remove the `autoplay` param from all
media video iframes urls (targeting all `div.iframe` that have a class
`media_iframe_video`).
For eLearning, override the `WebsitePreview._cleanIframeFallback`
method to remove the `autoplay` param from youtube videos URLs.
opw-3226002
closesodoo/odoo#121475
X-original-commit: ad78585cd514f5ff16647572d34937c18a112529
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit task action from kanban click and from
stat button does not have same behavior like kanban click
does show archive task for archive project and does not
display New button while other on does not.
This commit make both action consistance to have same
behavior in both actions.
task-3224627
closesodoo/odoo#121473
X-original-commit: c95278e78325aa3831f6bfb02a7f3e377d0a8028
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
This commit fixes a bug with the navbar links in the header of a website
on mobile. When the text of a link is long enough to be wider than the
screen, the text does not wrap to the next line as intended, but instead
overflows to the right outside of the screen, causing part of the text
to be hidden.
Steps to reproduce the bug:
- Edit the text of one of the menu links on a website to make it longer
than the width of the mobile screen.
- Bug: In mobile view, part of the link text is hidden.
This bug occurs with both the "default" hamburger type and the
"off-canvas" hamburger type.
opw-3233684
closesodoo/odoo#121464
X-original-commit: eae10f2e154a1b6bf9f385460b1371faf9869a3f
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Vray Benjamin (bvr) <bvr@odoo.com>
Before this commit, there were cases where toggling the grid mode did
not work correctly. These cases are:
- when a snippet has None columns (e.g. Cover) and that an inner snippet
containing a row (e.g. Form) was dropped into it,
- when a snippet has some content outside its row (e.g. Picture) and
that an inner snippet containing a row was dropped in this outer
content,
- when a snippet has some content outside its row (e.g. Picture) and
that an inner content (e.g. Alert) was dropped in this outer content.
The first two cases happen because the row that was taken into account
when toggling the grid mode was the first `.row` element found in
general, instead of only considering the container children. Therefore,
what happened in these problematic cases is that the row found was the
inner snippet one, which should not be the case and caused the toggle to
fail because it was trying to put the element inside itself.
The third case happens because the `div` elements were excluded when
placing the outer content in a column, instead of only excluding the row
element.
This commit fixes these issues by only considering the container
children when looking for the row element when toggling the grid mode,
and by filtering out only the row element instead of every `div` when
creating a column for the outer content.
task-3279191
closesodoo/odoo#121393
X-original-commit: f94fe1d40f05a8dbb42f0f2a95d3fff68a3af0ec
Signed-off-by: Dieleman Guillaume <gdi@odoo.com>
Before this commit, input size of thread name was bigger than
the description one. This happens because the input is sized
according to the font size, and the thread name was bigger due
to `lead` classname.
This commit fixes the issue by reducing the padding of input of
thread name input, so that both input have the exact same height.
Part-of: odoo/odoo#117357
1. show hover effect in discuss sidebar
With redesign of web client style, hover effect in discuss sidebar
was not longer working.
This comes from buttons hover effect no longer having precedence
to defined bg classnames, e.g. `bg-100`.
This commit fixes the issue by explicitly defining a style for the
background when hovering items in the discuss sidebar.
2. improved background color of discuss app in dark mode
The background color was too dark. This commit fixes the issue by
using `bg-view`, which is the preferred background to put
content in both white and dark theme.
3. Send button visual matches composer rounded border
Send button lacked its border. This commit fixes the issue by
including Send button inside the element that does the pretty rounded
border of composer. That way, the border of send button will not
longer be affected by change of button style.
Also make the send button active / inactive state more visible, by
using button link (green when active, muted when inactive).
Part-of: odoo/odoo#117357
1. Display avatar in top bar next to channel name and description.
2. Edit icon appears on hover.
3. Clicking on the Edit icon opens file browser to upload a new avatar.
4. Certain file types are allowed.
5. Avatar can only be changed for group chat by any member of the channel.
6. For channel it can be done with admin rights.
7. Disable uploading text from file uploader in this case.
Also show avatar of channel/chat conversation in chat window.
Author avatar in message list no longer shown im status.
Chat window header color matches new systray color.
task-2684679
[FIX] mail: make chat window header match systray color
Part-of: odoo/odoo#117357
Before this commit, when the user is colorblind and sees the kanban
view of project.task, he cannot see the difference between
`Changes Requested` and `Approved` options and so he has to
alternatively open the form view to make sure that they are reading
it right because no check mark appeared in the dropdown to know
the current option selected.
This commit changes the icon of `Changes Requested` state option and
also adds the check mark in the dropdown options of the state field
to show which option is the current one.
task-3287326
closesodoo/odoo#121427
X-original-commit: 5e477356d2498cb0692f869053531082b4e7618f
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
William Henrotin