Form view has multiple containers that are exclusive, before this commit
switching from one container to the other would lose all current chatter state.
closesodoo/odoo#102934
X-original-commit: a3d151d0c9c84c2dcffc28a342c40f38d0b28370
Related: odoo/enterprise#32644
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Purpose
=======
Convert the remaining legacy views in OWL. Before this PR, the list and form views are still in legacy in Project Sharing feature. The goal of this PR is to convert those views to have all views in OWL in Project Sharing.
Details implementation
----------------------
- Convert the list view in OWL
- Convert the chatter portal in OWL to be able to convert the form view in OWL
- Convert the form view in OWL and integrate the chatter into it.
- Review the assets used in Project Sharing to reduce the size of the assets since all components and views existing in the backend are not used (only the list, kanban and form views are used)
- Review the rows attribute set on `textarea` HTML element in`TextField` to be able to altered it with a props.
- Change the `FileInput` component to be able to override it to be able to use it when the route is different than the one set by default.
- Fix the `useInputField` hook to be able to use the `TextField` component without any `record` set on its props (since this prop could be optional).
task-2947516
closesodoo/odoo#102932
Forward-port-of: odoo/odoo#102130
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Xavier <xbo@odoo.com>
*: mail, website_livechat
This commit adds new option in Livechat Button visibility
"Show with notifcation", which allow to see livechat button
and also display a customizable floating text next to button.
This text appears 1 second after the livechat button become visible.
Task-2937993
closesodoo/odoo#102930
X-original-commit: 785356f46b49d1b3d9b975319c87f39266694b82
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
There is no strong need to have default values on identifying fields,
while allowing it adds overhead to every insert. The trade-off is not
worth it, therefore this commit removes the support for identifying field
default values and simplifies the code of findFromIdentifyingData
accordingly.
closesodoo/odoo#102912
Related: odoo/enterprise#32634
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Context:
We want to get rid of default values on identifying fields, and
SoundEffect/path is currently the only field to present this pattern.
Merging path and filename fields together makes the default value no
longer meaningful, as there is no full path that is shared by multiple
records and which would therefore consist of a relevant default value.
The point of removing default values from identifying fields is to
simplify the code of findFromIdentifyingData, which is called by every
single insert, so that we no longer have the overhead of looking for
default values.
This commit modifies the SoundEffect model in order to enable the
simplification (and therefore, optimization) of findFromIdentifyingData.
Part-of: odoo/odoo#102912
In 15.3, the width was applied on `o_form_sheet_bg`.
As the form view has been refactored in 16, we have to apply
it on the new parent `o_form_view_container`.
We also restore the chatter width to the same value as in 15.3:
```scss
.o_FormRenderer_chatterContainer {
&.o-aside {
width: $o-chatter-min-width;
}
}
```
Steps to reproduce:
- Open Helpdesk on screen at 1534x657
- Open a vip support
- Unfold 'Done'
- Click on 'Ugly Chair', the chatter take a lot of space => bug
Steps to reproduce
- Open Sales
- Open a quotation
- Switch between Order lines, Other info, Customer Signature
notebook tabs a flicker occurs => bug
closesodoo/odoo#102911
X-original-commit: 3e71df358caf878409947af1619378fbfeb2be4b
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Use case to reproduce:
- Create a new db
- Go to warehouse and create a new one.
Expected behavior (same than enable location options from settings):
- Internal location has been enable
- It's possible to create locations
It happens because during the warehouse create call, the multi warehouse
and multi locations groups are set. However `res.config.settings`
contains a hook on `set_values` that enable some views and internal
location. Write directly on the groups won't go throuhg this code.
closesodoo/odoo#102913
X-original-commit: 6f965fa75d3cf4283482f597712010d09044736f
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
- Gift cards can now be sent alongside the receipt via mail in the Receipt Screen.
- The gift card report no longer show n² gift cards
- Properly download all PDF files for the gift cards when there are multiple gift card programs
closesodoo/odoo#102910
X-original-commit: 5b269ebb3e725ff84c437e204874c14251ed1d78
Signed-off-by: Masereel Pierre <pim@odoo.com>
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
It was possible to sell gift cards without mail template or report link to the gift card program.
Thus, it was impossible to get the info related to the card unless you have backend access rights.
We now make sure the gift card program have a template and a report when starting the session.
closesodoo/odoo#102885
X-original-commit: e81db2e6e1a3179f9cb6c8410111201d311a97ab
Signed-off-by: Masereel Pierre <pim@odoo.com>
Prior to this commit the base_unit_price was computed using the price of
the template instead of the list price displayed on the eCommerce, so it
sometimes made no sense when compared to another currency.
It will now be converted properly and use the list_price instead of
template price to compute the base_unit_price.
Some other issues with the base_unit_price display in the form view have
also been fixed (mainly mobile stuff)
TaskId-3006015
closesodoo/odoo#102884
X-original-commit: 7701033a4d480881d9e1d2c3c842150ca8f55aec
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Also, as the rpm is not built from the deprecated bdist_rpm anymore, it's
time to remove useless requires from the `setup.cfg` file.
On the other hand, the soft requirements in the `setup.py` are now
synchronized with the hard requirements.
closesodoo/odoo#102849
X-original-commit: 20920ae968d6d5d2e51c970e9a2536e55965c53b
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
This commit refactors the style for borderless inputs and
adds a special class to better manage where they should be used.
closesodoo/odoo#102848
X-original-commit: 6b45cd5f3fbe0986e36401308d19214b689adc45
Related: odoo/enterprise#32609
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Make operation type a title.
Change description of some fields in General tab.
closesodoo/odoo#102703
Task: 3004014
X-original-commit: 2cc799edc58f96009c0323e0871e077339967557
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Before this commit, the assets used in project sharing takes almost all
assets in `web.assets_backend`, this way is not a good idea since only
the kanban view and list are used and the chatter is not the backend
one. So the assets could be filtered to minize the size of the bundle
for project sharing to also reduce the loading when the user goes to
project sharing feature.
This commit reviews the assets used in the project sharing to reduce
the size.
task-2947516
X-original-commit: 6805f5c9b5efa55aca711951d05bd51ea2fc8c0d
Before this commit, the form view in project sharing was always in
legacy. Moreover, in that view, the chatter used is the portal one
and so it is also a legacy widget.
This commit converts the form view and then convert the chatter in
OWL to be able to correctly compile and add the chatter in the form
view.
Also, some styling has been done to remove the overflow. Only the
overflow on the y axis in the chatter can be scrolled on the page.
task-2947516
X-original-commit: 175430f3593337ce582cbec644b9d630894c074b
Before this commit, the `FileInput` component can be used with another
route only if the route has the same params than the default one.
For instance, the portal chatter route does not have the same params
name and so, the component cannot be used.
This commit refactors the component to easily override the
component to be able to use it in each case.
task-2947516
X-original-commit: 8fdeea2e9918c8199724b177003f858716d7d5a4
Before this commit, the rows attribute given on the TextField component
was always 2, it is not possible to alter it without overriding the
component.
This commit adds a props to be able to update the rows with a prop
called `rowCount` and this prop can be set via `rows` attribute set on
the field.
task-2947516
X-original-commit: 110915c80c2a2578563283b1744e0e88d80ac4bb
Before this commit, when a component using the `useInputField` hook (for
instance `TextField`) and the `record` is not given in its props, the
hook will crash since it assume the `record` is always defined. However,
the props definition the `record` is optional.
This commit checks if `record` is defined in the component before using
it to be sure to avoid any crash because it is not defined.
task-2947516
X-original-commit: ebe3d00e52dd6097ce55986bc9e3bf9d79ca64cc
This commit converts the list view used in project sharing in OWL and
remove the legacy definition.
task-2947516
X-original-commit: 79159c0c6b715c3acbfb370523b73a664648deb2
Using patcher.start() can easily lead to incorrect cleanup.
-> after a copy paste, patcher is working, but stop is forgotten
-> stop is present, but won't be called if something fails during the
test
This commit add an utility `start(patcher)` to always have the add
cleanup.
Using a standard way to start the patcher with an automated addCleanup
should prevent this kind of mistake. This is why this commit also
replaces all valid patch.start() (followed immediately by a addCleanup)
closesodoo/odoo#102873
X-original-commit: 7d5a193d86316965a0908c65cfacfb607dc3f3ad
Related: odoo/enterprise#32618
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
# How to reproduce:
- Delete external ID "purchase_stock.route_warehouse0_buy"
- Try to create a Product
"purchase_stock.route_warehouse0_buy" was meant to be optional. We can only get the id after checking that it exist.
OPW-2972494
closesodoo/odoo#102872
X-original-commit: 1b7b4cdbee07c325753c1b9362414e8309ef8718
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: DavidFesquet <dafr@odoo.com>
Before this commit when list view is in multi edit mode and there is a field
with required and readonly modifiers, the field is underlined, which is not
intended as the field is in readonly mode.
task-3000817
closesodoo/odoo#102871
X-original-commit: fa6e2bb566f05e064ff8f4df40f1f01b048ade60
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Before this commit: syncing with google led to sending emails to
attendees of existing future events on Odoo.
Steps to reproduce the first issue:
Install 'google_calendar' module
Integrate with Google Calendar in setting
Add an event to the Odoo calendar for future date
Add one external attendee to the event
Sync with Google
Invitation emails would be sent to the attendees of the events.
Solution
It's possible to not send emails to the attendees in api calls. So
the solution is to not send emails to the attendees for the syncing
time.
opw-2819046
closesodoo/odoo#102870
X-original-commit: 5a56e37a5f54662b1f3593930738e51c010abab7
Signed-off-by: Arnaud Joset <arj@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
The goal of this commit is to add some fixes on page properties dialog
after the Owl REF [1].
- XML: use default form view style (remove </group>).
- Move the '/' back into the non editable part of the URL.
- Prevent python code from creating a different URL (and optionally
setting "website.rewrite" record for it) when the new URL is the same
as the initial one after slugify.
- 'useAutofocus()' on the first page properties field.
[1]: https://github.com/odoo/odoo/commit/61a9d7bd2abc6081b321a51d329f9e85209215e5
task-2687506
closesodoo/odoo#102869
X-original-commit: 1165dfcd4fd5677d14f3d3329ad7c62be847b31a
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Problem: If you have a customer assigned to an invoice/quotation
without an e-mail address and then share a payment link with
the customer. If the customer clicks on 'Pay', he won't be
redirected to Stripe's checkout page. He'll get instead 'Invalid
e-mail address: False' (see the image attached).
Explanation:
When there is no e-mail address defined, Odoo sends 'False' to
Stripe but Stripe sees it as the e-mail address which is indeed
Invalid. To solve the issue we replace False by None for the email
value of a customer without email address.
opw-3007866
closesodoo/odoo#102867
X-original-commit: 647a5fd79b88d4ea00eca2d6c1f9d9a2259a8414
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Fockedey Martin (mafo) <mafo@odoo.com>
Before this commit: if an event's attendee didn't have a state, it couldn't
get synced with Google.
The solution is first to set a default value for it.
opw-2915661
closesodoo/odoo#102865
X-original-commit: 89b53744c668183913b8a188730bd350fe778807
Signed-off-by: Arnaud Joset <arj@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Currently, there is no check when deleting an account report that has variants. Deleting such a report leads to variants not being accessible anymore.
When duplicating an account report, the columns are not duplicated and it can be tedious to duplicate them by hand.
There is also a bug when copying lines that have parent lines (no report_id set)
This commit fixes these issues by:
- raising a UserError when trying to delete reports with variants
- duplicating columns when duplicating a report
- correctly setting the report_id for all duplicated lines
Part of the big task fixing bugs in accounting
Task id=2996493
closesodoo/odoo#102846
X-original-commit: a84c7c6f210434dfcbf5c6a316f20981d06a3925
Related: odoo/enterprise#32607
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Popeler Antoine (anpp) <anpp@odoo.com>
Current behaviour:
Currently when settling an account in a POS session, in Saudi Arabia,
there is QR code on the receipt and a title "Simplified Tax Invoice",
which should not be present on settlement
Expected behaviour:
Receipts generated from a settlement in Saudi Arabia localisation shouldn't generate a QR code and a tax title.
Steps to reproduce:
- install the modules: `l10n_sa`, `l10n_sa_pos`, `settle_due`
- Switch to the Saudi Arabia company
- Enter POS and create at least 2 payment method:
- Cash: Identify Customer = false, Journal = Cash
- Customer Balance: Identify Customer = true, Journal = empty
- Create a new POS Session, just add "Customer Balance" to payment methods,
the rest of settings are as default (might need to add "Customer Invoices" to the journal of the session)
- Start a new session, find a customer with some "Amount Due" and click on the value,
choose one of the payment methods
- On the payment screen choose "Customer Balance", now you should have 2 payment lines,
one is the payment methods for settling, the other is the customer balance with a negative value.
- When validating, the receipt has a QR code and Invoice title, when it shouldn't.
Reason for the problem:
There is currently no state that differentiate between a normal order and a settlement.
Fix:
Implement a settlement state (computed) in the localistation order model.
Add the state to the data that goes to the templating engine.
Add conditional rendering for the templates related to the QR code and the "Simplified Tax Invoice" title.
Affected versions:
- 15.0
- saas-15.2
- saas-15.3
- 16.0
- master
opw-2976267
closesodoo/odoo#102853
X-original-commit: 0b04230d3c5e7fc1bc83340ec2fca9cf646cbc60
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Signed-off-by: Masereel Pierre <pim@odoo.com>
Since the merge of Bootstrap 5, the `btn-block` class don't exist
anymore. So we use grid instead to align the buttons.
Steps to reproduce:
* Go to field service
* Create a field service task
* Click on worksheet
* Go back to the task
* Click on sign report
* The buttons are not correctly aligned => BUG
closesodoo/odoo#102714
X-original-commit: af053ab9e21ef86e31c9a27b404658c864df1446
Related: odoo/enterprise#32540
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
Add choices for the business domain on applicability rules, so rules are more precise
Also put 'general' as domain from the view when it's what should have been.
Make analytic field visible since owl migration (for sale and purchase)
closesodoo/odoo#102461
X-original-commit: c5867d5009a7fb448fff1be487b9e9c3e7945d4b
Related: odoo/enterprise#32421
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
Since [1] the Plausible dashboard height was hard-coded to avoid the
display of a scrollbar on the iframe.
In case the Plausible dashboard height grows in the future, it will not
be possible to scroll to the bottom elements.
This commit virtually restores the scrollbar, so that in case the
Plausible dashboard grows in the future, the scrollbar will appear and
still give access to the whole dashboard.
[1]: https://github.com/odoo/odoo/commit/b8c1976e933628182496929d348dda11b5051a0c
task-2993773
closesodoo/odoo#102852
X-original-commit: 616eb5384df085fdc94cb18ab8e14336f9b68702
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce:
- set demo to receive notifs in Odoo
- go to employees
- click "launch plan" for demo user
- login as demo user
- Click on the link for the activity that is sent in discuss
Issue:
There is no chatter in the view
Explanation:
the view of en employee coming from messaging is always
hr.employee.public that does not contain the chatter.
opw-2990577
closesodoo/odoo#102851
X-original-commit: 93b95317315a1ba70ce0331c63321ab8eaa487d3
Signed-off-by: Fockedey Martin (mafo) <mafo@odoo.com>
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Rationales:
- having a textual display "Unsaved changes" implied to the user that they
had to save
- having buttons "hiding" behind a hover effect on a span of text was
very unintuitive
- since we don't want an hover anymore, having text buttons would draw a
lot of attentions => use icons + tootltip instead
closes odoo/odoo#102757
Forward-port-of: #102605
Related: odoo/enterprise#32570
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Before this commit the creation of the message(s) was done within a for loop in a big function.
Due to this there is no easy nor clean way to override and modify values on the mail.message record(s).
By placing the preparation of message data in a subfunction it can be overwritten and modified as wanted.
closesodoo/odoo#102825
X-original-commit: 6d6d7c12ac456e648bd35645f9617cd1d8ff60e6
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In case an employee has multiple contracts in several companies, we need
to only keep the contract of the current company of the employee, as
there can be only one in the main view hr_contract_history.
Before this patch, contract_information CTE returns the same ID for both
contracts:
employee_id | company_id | id | is_under_contract
-------------+------------+--------+-------------------
681 | 1 | 146842 | 0
681 | 14 | 146842 | 0
After the patch, it returns:
employee_id | company_id | id | is_under_contract
-------------+------------+--------+-------------------
681 | 1 | 4009 | 0
681 | 14 | 146842 | 0
We need to fix the WINDOW clause to make sure the id of the contract
that is selected is the one in the same company as the employee/contract
being selected in the contract_information CTE.
This way when an employee has multiple contracts, there will still be
1 line for each contract, but each with a different contract ID.
closesodoo/odoo#102821
X-original-commit: 88fa430be8a0c164e100b5f3c2f16ae906cc9a54
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Alex Thuyls (alt) <alt@odoo.com>
When there is too many options inside search view, they didn't wrap and will overflow outside the screen.
closesodoo/odoo#102812
X-original-commit: 8a63d9773b14e212618c3d0d298f0926547e1045
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
The RPC that the m2o widgets used by snippet options make are cached at
the widget level. When two m2o widgets make the same RPC, they are
indeed made twice. This commit just move the cache outside of the
widget instance and thus makes it so the same RPC made across multiple
m2o are cached.
Note: this was particularly visible because all main snippets have the
"Conditional Visibility" option which uses 3 m2m widgets. At each drop
of such main snippet in the page, the option is created and the 3 m2m
widgets made their RPC. Then each further drop of snippet made the exact
same RPC for no good reason.
In the future, the system should be further improved to not require
those RPC on initial drop and clicks, especially as the "Conditional
Visibility" m2m widgets are hidden by default. This fix focuses on
fixing the generic m2m widgets.
closesodoo/odoo#102800
X-original-commit: 8e08c896df9ed5a7a0e559f1dbd8812f87908a39
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When a snippet option uses a m2m widget, the domain used for the
internal m2o widget which allows to select records evolves to receive
the subdomain `['id', 'not in', <selected-ids>]` with `<selected-ids>`
indicating the m2m records which are already selected.
M2o rpc are cached... based on the whole query object from which they
are created. The domain is part of that query object.
Both those concepts actually conflicted: the initial RPC when no ID is
selected was made with no subdomain, while the subsequent RPC when no ID
is selected were made with the `['id', 'not in', []]` subdomain. The
cache system did treat the resulting domains as different requests. Now
we avoid adding the useless `['id', 'not in', []]` subdomain as it
should already have been done without a cache system in place.
Note: this was particularly visible because all main snippets have the
"Conditional Visibility" option which uses 3 m2m widgets. At each drop
of such main snippet in the page, the option is created and the 3 m2m
widgets made their RPC with the initial domain. Then on click on the
snippet, a new RPC was made with the problematic subdomain, making the
first click on snippets being needlessly slower.
In the future, the system should be further improved to not require
those RPC on initial drop and clicks, especially as the "Conditional
Visibility" m2m widgets are hidden by default. This fix focuses on
fixing the generic m2m widgets.
X-original-commit: 017a468547eafa3e34f584379d3f05b3ed1db487
Part-of: odoo/odoo#102800
The website edition system is based on a main mutex to guarantee the
order of user manipulations. Meaning that if an user follows any flow
really quickly, each part of the flow should be guaranteed to be done
in the order the user asked for, independently from the duration of each
part. The mutex system to ensure that is not robust yet though, or at
least it is not easy to use and should probably be replaced by something
more easier to use in the future. Indeed, some operations are badly
implemented around this mutex.
This is the case of the drag and drop of a snippet into the page. Drag
and dropping a snippet is a long series of operations, to name a few:
1. The user mousedown on a snippet thumbnail
2. The user drags the snippet around
3. The user drops the snippet in a dropzone
4. We scroll the page to the position of the snippet
5. The snippet is built (options' `onBuilt` methods)
6. The snippet public widgets are started
That whole series of operation has to be reduced to an atomic work to
be added to the mutex queue. Meaning that for example, if the user
manages to click on the save button while he is dragging a snippet
around... the editor should only save the page after the whole series
of operations of the drag and drop has completed. This is not the case
right now: the mutex lock is released between (4) and (5) because we
have too: (5) and (6) use the mutex themselves and would thus induce
a deadlock if we only release the mutex after (6) as it should be. This
means that during the scroll to the snippet (4), if the user manages to
click on the save button, the save operation will be scheduled to be
done before (5) and (6). It is thus technically possible to save a
snippet which is not built** (even if it would not be critical most of
the time). Worse, before building a snippet, its options have to be
instantiated... and that operation is not mutex protected so this is
probably (not 100% sure) possible that this happens:
a. Drag and drop a snippet. During the scrolling, click on save.
b. End of scrolling, the mutex lock is released, we create the first
option and its widgets as part of the onBuilt process. Creating each
widget is async, once the first one is created, the saving process
starts as it was scheduled in (a).
c. Saving the content, destroying all snippet options and their widgets.
d. Continuing building snippet options widgets started at (b)... but
previously-made ones were destroyed at (c)... possible crashes***.
Fixing all of this probably requires a change in the system, maybe the
use of multiple mutexes, maybe the saving operation can always be
delayed at the end of the queue somehow, ... but this requires some more
thinking and probably not possible in stable. In stable, it could be
enough to disable the saving entirely during drag and drop (like drag
and drop of another snippet is currently disabled during another drag
and drop). This will be done in another commit if this is decided.
Meanwhile, this commit just changes the behavior in tours for now:
waiting for drag&drop to fully complete before clicking on save, like
an human would.
** It is possible to reproduce by using the ALT + S shortcut: start
dragging a snippet which has a onBuilt method in its options, hover
the dropzone where you will drop, ALT + S to save (the editor waits
you drop your snippet), drop your snippet -> the snippet is saved and
the edit mode is left... but the onBuilt was not executed.
*** a crash was indeed found during a specific theme tour (out of ~30
Odoo themes because of this after the other commit of this current
PR). After those other commits especially, it is also possible to
reproduce with the ALT + S trick, although not consistently. It may
be linked to the specific last snippet added by that theme tour
instantiating specific options. But as explained saving just after
drop is an issue independently from this potential crash problem
(snippet not built, etc).
X-original-commit: e96167ae20d2a143d7def4347166b37e158003b0
Part-of: odoo/odoo#102800
Prior to this commit, the language of the snippet menu would be the same
as the snippet content. This would cause issues if the user's language
was not the same as the website they were editing.
This commit fixes that by displaying the snippet menu in the user's
selected language but getting snippet content in the website's language.
This commit also fixes SEO data not being saved according to the
website's displayed language. Prior, it was saved according to the
user's current display language.
This commit also introduces a test for a fix made at [1] that
targets a previous version of odoo.
[1]: https://github.com/odoo/odoo/commit/db5d1eae2086ff338d8211af70c2f88240393c36
task-2687506
closesodoo/odoo#102799
X-original-commit: 55a978aa86967581956f855a1c5db33b7425bd15
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Commit [1] keeps the snippet cache alive through different
instance of the website snippet menu.
This allows for the user to switch pages, even apps, while
keeping the snippets in cache, decreasing the startup time of the
snippet menu.
However, the cache is not invalidated when switching website or
installing a new theme.
This commit adds a `invalidateSnippetCache` property to the
websiteService. If this property is set to `true`, the cache will be
invalidated next time the menus loads its snippet.
This property is currently set to `true` when changing website and
switching theme.
[1]: https://github.com/odoo/odoo/commit/03c552690b15cbf2e7d6b7812386ac64042219af
task-2687506
X-original-commit: bb503962a36f3798c50049f2844e7b288b632955
Part-of: odoo/odoo#102799
Commit [1] added back the user context to every RPC called from the
legacy env when it's mapped to the WowlEnv but in doing so, overrode
the params' context keys.
This is incorrect as the params could very well have context params that
are different from the session's params for a reason.
For example, in master, after [2], editing the menus of a website
displayed in a language different from the user's will lead to incorrect
languages in the context when the page is saved. This is cause the
language in which the page is edited is passed as a context param, and
the language of the user is in the session (under the same `lang` key).
[1]: https://github.com/odoo/odoo/commit/d959638e23a92cf880049a760c42da33e5908f41
[2]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
X-original-commit: 8cdb2293f294558c3bea4ed59a49e0f52b3d217e
Part-of: odoo/odoo#102799
Before this PR, the chat window hidden menu dropdown would have been
opened to the bottom of the corresponding button. The issue is that,
this button is position at the really bottom of the page, causing the
dropdown to be outside of the page.
This PR fixes this issue by adding the missing `data-bs-toggle`
attribute.
task-3011161
closesodoo/odoo#102765
X-original-commit: a4b69feb13852dd13160564bce3b0ae1cb453c0b
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Stockbauer Matthieu (tsm) <tsm@odoo.com>
It is technically nearly impossible to delete a company
when it actually dealed with customers
(emitted invoices, received payments, ...).
Hence, if you want to get rid of a company,
for instance because you closed one of your subsidiaries,
giving the possibility to archive your company,
thanks to an active field, would be the best way to go.
We are hesitating to do a related field to the
`partner_id.active`, but we are a bit afraid
some people archive the partner linked to their company
for other valid reasons than get rid of their subsidiary
(such as avoid changing the address of their company
by mistake through the Contacts app),
while still wanting the company itself to be active.
So, we make it an independant column at the moment,
so we have the actual stored column in case we need it,
and will do a related stored to the partner
later on if we change our mind.
Manual forward-port of #102801closesodoo/odoo#102586
Signed-off-by: Olivier Dony <odo@odoo.com>
Before this commit, sending a message on a livechat whose visitor closed
the chat window would have resulted in a traceback being shown to the
visitor. This was occurring when a message was sent by an operator or the welcome
bot. An other related issue occurred when sending the feedback to the welcome
bot.
This commit fixes those issues by correctly guarding calls to
`publicLivechatGlobal.chatWindow`.
task-3010725
closesodoo/odoo#102752
X-original-commit: 524fc3e4cb0e63029e774e97de687998ccf06909
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Stockbauer Matthieu (tsm) <tsm@odoo.com>
The editor's toolbar is at the very bottom of mass_mailing's sidebar,
making dropdowns pretty awkward as they often require the user to scroll
down to see them. This extends the editor's toolbar for mass_mailing so
all dropdowns become dropups instead.
closesodoo/odoo#102734
X-original-commit: d4b5527113a6092063cba3409d870c5c45a8cd03
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Sébastien Theys