Some field strings are duplicated and raising a warning in the CI.
Solution is to remove duplicated fields and put them in a common module,
or to change the string in the field declaration and put the right one
in the view.
ISSUE
When selecting colors options from the editor toolbar on a html field,
the colorpicker was not displayed under the toolbar.
CAUSE
Before this commit, the colorpicker dropdown position was computed with
top, bottom and height css properties.
After a new colorpicker was introduced with multiple sections of
different sizes, the size of the dropdown-menu could not be fixed
anymore and [1] broke the existing computation to display the dropdown
above or below the toolbar.
SOLUTION
Using bootstrap dropdown 'dropup' class instead of top, bottom and
height css properties.
[1]: https://github.com/odoo/odoo/commit/96ab729850983162a0039e40c77537ef65cd039eclosesodoo/odoo#73947
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit adds an optional "toggler" props to the Dropdown
component. If set to 'parent', no toggler will be generated by
the Dropdown component. Instead, the parent element of the dropdown
will be its toggler.
closesodoo/odoo#73858
Related: odoo/enterprise#19702
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
The dropdown Component takes 2 slots: one for the toggler, and one
for the actual dropdown content. Before this commit, the default
slot was the toggler, and the other one was named "menu".
However, as the toggler is actually optional, and the "menu" slot
contains the central information about the dropdown, we decided to
swap them. The content of the dropdown is now the default slot and
the toggler can be specified with the "toggler" slot.
The purpose of this commit is to have a test environment
that does not depend on the OS of the machine
on which the Odoo server is deployed.
Because the navigator.platform is deprecated, we will use the
navigator.userAgent to identify the OS.
Use correct label. This link leads to opportunities, not to "Favorites"
whatever that means.
closesodoo/odoo#60036
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit *Validation Error message* was not required for questions
with *Validate Required*. This leads to having `False` displayed if
*Validation Error message* is empty.
With this commit we make *Validation Error message* required for these types
of questions which requires validation. Indeed it makes no sense to required
a validation but having no message explaning why it failed.
closesodoo/odoo#58083
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Currently, the PDF viewer is loaded from an iframe and the PDF controllers
contains empty anchor links. When the user clicks on one of these links,
the browsers based on Chromium will trigger a "scroll jump" and the iframe
will be placed at the top of the browser window.
When the PDF document is larger than the viewport, this behavior can be
quite annoying: The user will have to scroll the browser window to
see the controllers each time they click on a controller (-> link) as
(1) the controllers triggers a scroll jump and (2) the controllers are
below the document that does not fit entirely on screen. To avoid that,
the links of the PDF controllers will be replaced with spans. The
controllers will then no longer trigger a scroll jump.
SPECS
- Replace the links of the PDF controllers with spans.
- Add css rules to prevent user selection.
LINKS
Task id: 2500574
closesodoo/odoo#73937
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Since odoo/odoo#72675 the core services are now available in the
frontend, this includes the scroller service that will call
preventDefault on click events when the clicked link has an empty anchor
as this is usually used to change the cursor appearance, but we don't
want to mess with the hash which contains the webclient state.
In the configurator, the file input for logo upload is inside such an
anchor with an empty href, and so preventDefault is called, preventing
the file picker from opening. While in the configurator, we don't have
any state stored in the hash, not calling preventDefault on anchor
clicks may still cause scrolling issues among other things.
Since there is no reason other than styling for this node to be an
anchor tag, this commit replaces it with a div, and appropriate CSS to
style it.
closesodoo/odoo#73936
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
When pasting text containing url, the url was pasted twice.
One being simple text and the other one being a link.
Task ID: 2602785
closesodoo/odoo#73709
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
Currently, when sending the mail for enrichment with template
`enrich_company`, we display few data with pills, like phones,
emails, industries, sectors etc. When there are too many pills
for these information, pills sometimes break into another line
if there's no enough space and the mail looks ugly.
This commit improves the behavior by improving the inline style
for those pills, and thus by making sure that it will always
display entire information in one line, instead of breaking
them into multiple lines.
Apart from that, this commit also makes the template responsive
so that is doesn't look mess in Odoo's chatter while viewing
from small devices.
TaskID-2577809
closesodoo/odoo#72507
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
If you use electronic terminal, electronic ticket is not save in database.
I you want reprint the ticket, electronic ticket is not present in the reprint ticket.
closesodoo/odoo#73919
X-original-commit: 08583840604e71f18f3b98b6dc8d4fa04f502689
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
When installing some modules, if an other action is undertaken around
the same time it is possible for the two to deadlock, leading to the
two workers being killed by the wallclock limit watcher. This should
only be an issue on the *threaded* server, workers should not be
affected, meaning the issue is not reproducible on runbot.
A relatively reliable way to trigger this issue manually is to create
an empty database, on the "apps" kanban view install the "sales"
application, and as soon as the UI gets unblocked install the "CRM"
application. An other method (also reliable but not really doable by
hand) is to simultanously log in and install the sales
application (`sale_management` module).
The core of the issue seems to be in `_button_immediate_function`:
1. `Other` has an env ready for use and has accessed various
models (so has pretty shallow locks on the tables e.g.
ACCESS SHARE).
2. `Install` takes the registry lock to create the new registry.
3. `Install` needs to update one of the tables `other` has touched,
starts waiting on the `ACCESS EXCLUSIVE` lock (the only one
`ACCESS SHARE` conflicts with) in order to execute DDL (most `ALTER
TABLE` forms require exclusive access to the table).
4. `Other` needs a new environment (e.g. `sudo()`, `with_user`,
`with_context`, ...), starts waiting on the registry lock.
At this point the two threads are deadlocked, `other` waits on the
registry lock which `install` holds, while `install` waits on a table
lock which `other` holds. Since one of the waits is on the application
side, Postgres' deadlock detector can not notice the issue. That one
of the locks is on the Python side is why only the threaded
server *should* be affected.
An initial seemingly promising mitigation attempt was to
LOCK res_partner IN ACCESS EXCLUSIVE MODE
in the prelude of `_button_immediate_function` as `res.partner` is one
of the most commonly modified models, this would force
`_button_immediate_function` to wait until all existing requests have
completed and prevent later requests from progressing.
This turns out to be unreliable, as later requests could already have
acquired an environment and would race ahead as soon as the
transaction is committed if the scheduler lets them. Trying to lock
the registries earlier doesn't work as the locking is interleaved in
normal operation and we'd just deadlock there. The commit is because
`load_modules` does not take an externally provided cursor and instead
creates its own (thus its own connection and transaction). And because
of its lack of atomicity the issue might occur regardless.
An alternate mitigation is instead to set (or drastically reduce) the
lock wait delay during module installation, installation should
normally be entirely uncontended (or infeasible in production with
large traffic) so there is limited reason it'd be waiting several
seconds on a lock. Conveniently, this means instead of the thread
being killed entirely, the install request gets aborted *and retried*,
so it can succeed a little more slowly if that allows the other
request to complete and no other concurrent request causes the same
issue.
Other alternate mitigation which got discarded: reusing registries
when creating new environments (from existing ones) if the database is
the same, that works for some case of switching environments, it
doesn't work for other where we actually fetch a registry e.g. assets
generation calls `get_modules_order` which calls `module_boot` which
calls `module_installed_bypass_session` which gets a
registry. `get_modules_order` is the last place we know we have an
existing registry. Though maybe we could strip out the entire thing
and call `module_installed(self.env)` directly?
Issue 2581648
closesodoo/odoo#73906
X-original-commit: ab84d970dcf1a9dbd5697b6600930cd1bcba3634
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Steps to reproduce:
- Install "Sales" module (for test purpose)
- Active `External Email Servers` email feature and set an alias
- Go to any Sale Team, and set an Email Alias
- Send an email (from outside Odoo) to the sale team email alias
- Write the body text in hebrew
- !must ensure that the mail is encoded in iso-8859-8-i.
- Go to Settings -> Technical -> Messages and open the receveid mail
Issue:
Hebrew character are replaced by `�`.
Cause:
Python does not have -e and -i codecs.
More info here: https://bugs.python.org/issue18624
Solution:
Create an alias for iso-8859-8-i == iso-8859-8.
opw-2482579
closesodoo/odoo#73934
X-original-commit: 632ed24936000cfb4cb3296a25ff6195a89109a0
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Currently, pricelists can be deleted even if a pricelist rule uses this pricelist as base.
This leads to an error when the rule is used because it tries to access a deleted record.
This commit restricts the deletion of such pricelists, avoiding later tracebacks.
closesodoo/odoo#73907
X-original-commit: 8c3c7d9e85ca4353d3b8501cc5c484a3bd955754
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: vfe-odoo <Feyensv@users.noreply.github.com>
Currently, contactus page is dynamic (Google map snippet, Company Data, Contact Form), in order to make it static :
- Company data snippet has been removed and replace by static data
- Google map snippet has been removed
- Website_form module has been merged into website (before, the module needed to add data into contact us page which was not static)
- Pre-fill option has been added to s_website_form snippet and all website_form dependencies have been updated to add "fillWith" attribute during form model registry.
- Finally, contactus-thanks has also become static !
Enterprise: https://github.com/odoo/enterprise/pull/18242
Upgrade: https://github.com/odoo/upgrade/pull/2452
task-2462993
closesodoo/odoo#69888
Related: odoo/upgrade#2452
Related: odoo/enterprise#18242
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
- fixed xml data files order, otherwise form field would not be whitelisted,
including `email_to`, so the mail would not be send.
- add the same data-for behavior from website_crm to website, to be able to
prefill a field with an URL param
- removed the fallback data-for in website_crm, the JS in now in charge of
doing that. Plus it was creating a misheavior -> you could have prefill set
to false but still, it would prefill the user info
- fixed the form option so the field.name is not used as field.string if there
is already an explicitely set field.string..
- adapt field name in /contactus form (xml view), form snippet (registry) and
crm form (registry) for more consistence
- added the prefill option set to true by default on /contactus (to fit what
we had before). This came with a change in the test as we don't need to
enable it anymore.
- added also the prefill option to true by default on form snippet
Part of #69888
task-2462993
Before this commit (and the previous ones that prepare it), the contact
us page was largely editable but not entirely. The automatic address
field on the right column prevented the page to be considered like any
other page and only the left column was editable. That led to less
possibilities and difficulties to make a modern contact page.
Now, the whole page is static, like a page the user would have created
himself. Same for the thank you page. This comes with the disadvantage
of having to handle the address by yourself (but that's not a field that
would normally change a lot anyway) and the website_crm app now needs to
be enabled on the form via edit mode after install to change the form
action to lead creations.
Part of https://github.com/odoo/odoo/pull/69888
task-2462993
*: website_crm, website_form_project, website_hr_recruitment,
website_sale
Replace website_crm specific behavior by another option for all website
forms.
Part of https://github.com/odoo/odoo/pull/69888
task-2462993
*: crm_iap_lead_website, website_crm, website_form_project,
website_hr_recruitment, website_sale
Part of https://github.com/odoo/odoo/pull/69888
task-2462993
If the buyer is Italian, it must have a zip code of length 5.
If the buyer is not Italian, the zip code is optional
closesodoo/odoo#73883
X-original-commit: 86aa7507b0d86bd13dba303c75821048d420f647
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: bfr-o <bfr-o@users.noreply.github.com>
When using another language than English, the UID of a POS order may be
incorrect
To reproduce the error:
1. Open a POS's configuration and enable "Manage Orders"
2. In Settings > Languages, add ans switch to:
- French (BE) / Français (BE)
3. Start a POS session
4. Process an order
5. Open the orders managers
Error: the processed order is named "Commande de 00001-001-0001", the
"de" in the middle shouldn't be present
This is the combination of "Commande" and the UID of the order. The
latter is extract from the POS reference, which looks like "Commande
00001-001-0001" by removing the first 6 characters. It's ok in English:
from "Order 00001-001-0001", we have "00001-001-0001". But this won't
work in all other languages (specially for RTL languages)
The unique identifier of an order is a sequence of 12 digits:
https://github.com/odoo/odoo/blob/3e8d921318e86631b73c8c92c2e462fd0d761582/addons/point_of_sale/static/src/js/models.js#L2865-L2868
Knowing this, we can easily extract the UID from a POS reference
OPW-2538645
closes#71181closes#71182closesodoo/odoo#73876
X-original-commit: f5b23781cdf8a9e50c9a1fcd38ec704d4a4513fb
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Previously, loading the login page with no modules installed would
result in a crash, because the translation service assumed that there
was always a cache_hashes key in the session info. This is not the case
when the http_routing module is not installed.
This module fixes that by adding a fallback for those cache_hashes in
the translation service.
closesodoo/odoo#73874
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Purpose
=======
Currently we can write a review in the slide fullscreen view.
But if we click on the button "review", we are redirected to the reviews
page. Instead, we want to open the rating composer and to stay in the
page.
Technical
=========
Add the dependency "portal_chatter.xml" from portal rating on the portal
composer Widget. It already has the dependency "portal_chatter.xml"
from the simple portal module, but because the second file was not in
the dependency, the view was not inherited and we were not able to rate
the review.
Add a new option on the portal rating composer, "hide_rating_avg" in
order to hide the global rating on the button and allow to fully
customize the button to have the same look as other buttons in the same
view.
Task-2322583
closesodoo/odoo#62872
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Remove the flicker of the "portal rating" widget when we load the page.
Specifications
==============
Currently, the portal rating widget is composed of 2 parts
- A Python template
- A JS template
There's also 2 widget, one widget who is linked to the Python template
and which instantiate another widget (which will render the JS template).
That's why we have a flicker, the button of the widget is rendered in
Javascript.
The purpose of this commit is to simplify that, to have only 1 widget
and to have as munch as possible in the Python template.
Technical
=========
We still need 2 different template (Python / JS) because in the
non-fullscreen view, after editing our review, we do not want to refresh
the page, but we want the average rating to be updated.
Task 2322583
wan