Purpose
=======
Add a new type on the working schedule, adding "Lunch" to Morning and Afternoon. It's mandatory,
because, if you don't do that, you can't assume the difference between a time that should be
recorded as extra hours and a time that should not be counted because it's lunch time.
A company is not another, so to be clear, they will define what are the imposed lunch time
where the employee is not paid during the week.
Specification
=============
Lunch between Morning and Afternoon
When a time period is under Lunch :
- There is no working entry generated for that period of time.
- If you work before the lunch time and after it, it's not considered as extra time.
- The employee is not paid for the Lunch time.
TaskID: 3102363
This allows the tour manager to attach an event handler
that listens to the "AutoComplete:OPTION_SELECTED" event from
components that utilizes AutoComplete, and if that so happens,
the tour can proceed to the next step.
This change is proposed because of the following bug report:
> [aju] https://watch.screencastify.com/v/UBGeNfXEJmCvE963VSnk
> planning onboarding tour > creating a resource on the fly by hitting
> Enter should validate the step
closesodoo/odoo#111798
X-original-commit: dbccea9a983b3a92fe9a299e4c8704158c7019ae
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
**Current behavior before PR:**
Even when the "drag-handle" is already hidden (since the field is already readonly),
the items of x2m field can still be resequenced by the user.
**Desired behavior after PR is merged:**
User should not be able to resequence the list items when the list field is already
readonly.
**Solution**
If a shown list is representing a x2many field, it makes sense to prevent
resequencing when the field is "readonly". However, the list is oblivious
of that property unless we force it, therefore we introduce the "readonly"
props to the list renderer.
Note that a heuristic was tried to compute "resequenceability" based on
the "editable" property, but that is rather difficult if not impossible.
Also note that "readonly" defaults to "false" to be compatible with the
current situation where the list is rendered -- list view, field, select/
create dialog -- which by default, the items can be resequenced.
closesodoo/odoo#111797
X-original-commit: 7682a5c87b8e2f59a4c277143d6054adb40edef9
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since https://github.com/odoo/odoo/pull/106015, we override a few project actions in `sale_project` to add a context key
allowing to search SOLs by their partner's name. However, this override is not taking the existing context from project
into account and removes it.
This commit restores that context by adding it in the action overrides.
closesodoo/odoo#111789
X-original-commit: 391152f53fe499aa41d4f4fef35c4462f0c1cce5
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Since https://github.com/odoo/odoo/pull/106015, the action `project.action_view_my_task` contains a domain
to filter on the current user's tasks. The default filter that was previously used
to achieve the same purpose is therefore no longer necessary, but was forgotten because of
another bug that removed it when `project_sale` is installed.
This commit removes this filter.
X-original-commit: b908425f886beeee5959313c3b92b546635ee110
Part-of: odoo/odoo#111789
Reproduction:
1. On Odoo 16, install Sales
2. Go to Sales -> Configuration -> Quotation template
3. Click the example “4 person desk”
4. In the “Lines” and “Optional Products” tabs, the translation button
is not show in the Description field
5. In Odoo 15, it shows the translation button
Reason: 1. In text_field.xml, the translationButton is not in the same
div element. This causes the translation button is hidden when in the
tree view. This is the case of the Optional Products tab
2. For the case of Lines, another reason causing this issue is the use
of widget “section_and_note_text”
Fix: move the translation button to the same div element with the
textarea in text_field.xml; remove the widget “section_and_note_text”
from the Lines tab. Also added a test for the text field translation
button
The adding of div:
https://github.com/odoo-dev/odoo/commit/98e94d45fd6176d7afdcf682c10ce8894f86915a
Rewrite of Text Field js:
https://github.com/odoo-dev/odoo/commit/32bc28aa665c479e31a40afffca2f03f6f2cc805
Rewrite of section_and_note:
https://github.com/odoo-dev/odoo/commit/5a21823f4364d6db407d48178435de041b157b44
An community PR for the translationButton by niyasraphy (same change):
https://github.com/odoo/odoo/pull/111291
opw-3078122
closesodoo/odoo#111763
X-original-commit: 99a23902bd2002099322b5c36fac94c8bd500951
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Co-authored-by: niyasraphy <niyasraphyk@gmail.com>
In the Sales dashboards, click on any of the "Top *" link.
=> in the list view, there are more records than it should be.
Quotations and cancelled records are displayed
Follow up of 0fa2510
closesodoo/odoo#111762
X-original-commit: 575be2a4c2d48d5cdd3babb6b80759cf02ef23c6
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
In the Sales dashboards, the product quantities (cells B43:B52) are
displayed with the automatic pivot format which displays floats with
decimal.
If the product is a chair, it's weird to see the quantity ending with ".0"
Units
Office chair 11.0
Even if some unit of amounts can be expressed with decimal values,
we decided to round the amounts in the dashboard by forcing
the integer format.
X-original-commit: bd029041a82278a8dc7cf1b363e87c70845acd3a
Part-of: odoo/odoo#111762
In the Sales dashboards, all "Orders" columns in every "Top *" tables are
wrong.
They count the number of report records (~ sale order lines) but
some are part of the same order. For those cases, the order is counted twice.
Task 3166898
X-original-commit: f3e80f52e96ed3e2b48157467dcf3aef441e6455
Part-of: odoo/odoo#111762
To reproduce the issue:
1. Install [Inventory], [Purchase] on Apps
2. [Settings]>[Inventory]>[Storage Locations]: enable
3. On [Purchase], Create. 'Deliver to' field is ill-positioned
Desired view: use the full width of the row
Applicable versions: 16.0 - master
opw-314167
closesodoo/odoo#111759
X-original-commit: 46700f12b0b4e64029bccf3abb791fe95400331d
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Lee, Hansun (hale) <hale@odoo.com>
On the `/forum/<forum>/tag` page, since the update from BS4 to B5, the
box to subscribe supposed to be shown when hovering a tag is not shown
anymore.
This is because in BS4, `col-md-3` was bringing the `position:relative`
css property but it's not the case anymore in BS5.
The `.o_forum_tag_follow_box` which is in `position:absolute` is
therefore not working as expected.
It is actually shown, but the user can't notice it as it's shown at the
very bottom of the page below the footer (you can see the scrollbar size
being changed).
closesodoo/odoo#111751
X-original-commit: 9a45860e9df1e24760ae5ba45faee4a67dbfc80d
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce:
- install Stock
- Go to Inventory > Delivery Orders > Configuration
- Activate Show Detailed Operation
- Create a delivery order and set the delivery address
- Create a detailed operation
- Save
- Print the delivery slip
- The delivery slip don't have the delivery address
Bug:
There are 2 flows to create `stock.move` from a delivery order:
1- Create it directly from the operation tab:
* In this case `stock.picking.onchange_partner_id` handles the
`partner_id` field of the `stock.move`
2- Create a detailed operation then the move is created in `create_move`:
* There is nothing handling the assignation of the `partner_id`
field of the `stock.move`
* This creates an issue as `should_print_delivery_address` expects
the `stock.move` to have its `partner_id` set to print the
delivery address on the delivery slip
Fix:
Set the `partner_id` in `create_move`
OPW-3145779
closesodoo/odoo#111740
X-original-commit: 6bea6d99050746bfa8a70bbfc8975090ab47fdbe
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
The text and the image were overlapping in the digest tip about "Tip: Speed up
inventory operations with barcodes". This solves the problem.
Technical note: actually, the layout has been broken in 15.2 because the image
has been updated with another ratio (from that version the CDN is used instead
of an image on the server). To support more client and as it looks ok even on
small device even with the 2 columns (text-image), we have used a table for the
layout.
Task-3097167
closesodoo/odoo#111737
X-original-commit: 7b6c82f2bc0f0d3931d6bd7c571cf4854eb4bd86
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Before this commit, if a link to a page was not correct because of a
case mismatch, it would simply land on a 404 page.
While it's correct, as URL are case sensitive, it leads to a few bad UX
flow at the admin/editor level:
- Create a link in your page (on a text or a button eg), type an URL
which does not exists (to create it after) like /Page
- Click on the link/button you just made, you are redirected to /Page
which display a 404 with the "Create page" option (correct)
- When you click on that button, it will actually create a page with
/page URL, leading to a mismatch between the URL you created and the
page URL.
Your link/button will still lead to a 404 URL as it points to /Page.
Since it's just a fallback when an exact URL match is not found, it
should not break anything and should not have bad impact at any level
(seo/speed etc).
Indeed:
- It's done through a 302 redirect
- `_serve_page()` is already a fallback case, so it will only make
the `website.redirect` and 404 cases a bit slower due to the extra
search query.
The only possible scenario seems to be if the user (mind the uppercase):
- Created a /Page page
- Created a redirect from /page to /another-page
In this case, /page won't land on /another-page but on /Page.
This flow seems unlikely and is not actually wrong either way.
At least, it certainly is less important than ensuring a case
insensitive fallback.
Finally, note that another solution would have been to either:
- Force page URL to lower case.
-> This is not stable friendly, people might be relying on this to
create pages with different casing:
`/Batman-VII-The-Dark-Knight-Whatevers`, while not recommended,
doesn't sounds idiot.
On top of not being stable friendly, we probably want to keep
offering this possibility
- Redirect all URLs to lowercase endpoints.
-> This is obviously not stable and not Odoo's jobs. It should be
something decided by the sysadmin and done at nginx (etc) level.
task-3110294
opw-3104030
closesodoo/odoo#111736
X-original-commit: f05491105f93939490cbeb078cb7653c38685644
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, there was a weird issue with tooltips. If the
element was entered very slowly from the left or top, sometimes,
the tooltip didn't open.
The problem came from the way we closed the tooltip. This was done
by checking the x and y mouse positions within a setInterval, and
if it wasn't inside the element having the tooltip, the tooltip
was closed. When approaching the "?" icon, the mouseenter event was
triggered, we registered the setTimeout to open the tooltip. In the
next ms, the setInterval callback to check whether the mouse is
still hovering the element was executed. We observed that when the
mouseenter event is triggered, the x and y mouse positions aren't
yet inside the element, for 1 or 2 px (like if the mouseenter was
triggered too soon). As in the scenario, we move the mouse very
slowly, the setInterval callback determined that the mouse wasn't
hovering the element and thus cancelled the setTimeout callback that
will open the tooltip.
This commit fixes the issue by changing the way we detect that we
have to close the tooltips. We now listen to "mouseleave" events,
and when triggered on the element with and opened tooltip, we close
it.
Task 3150954
closesodoo/odoo#111718
X-original-commit: 89770d32cbb368f73ab304ea5c1637bd3cc19bcd
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Steps to reproduce:
- Create an analytic plan with the domain as a Bill
- Create an analytic account for the above plan
- Create an analytic distribution model and include condition as account prefix, and product.
Issue:
The analytic distribution model doesn't apply to the bill created via purchase order
Solution:
Make sure we set the analytic_distribution only if present in order
to trigger the compute during invoice creation.
opw-3160041
closesodoo/odoo#111717
X-original-commit: ce5cae1da3f453ce1aad0915189e0e305d7e55e0
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Steps to reproduce the bug:
- Enable “batch transfers” in the inventory settings
- Create a new warehouse “WH2”:
- Enable “Resupply From” option
- Enable “3steps”
- Go to the operation type “internal transfers” of WH2:
- Enable “Automatic Batches”
- “Destination Location”
- Create two storable product “P1” and “P2”:
- Route: warehouse # 2: Supply Product from YourCompany
- update the Qty to 10 in wh/stock
- Create a replenishment for “P1” and “p2”:
- Location: WH2/stock
- Preferred route: warehouse # 2: Supply Product from YourCompany
- Procurement Group: select two different procurement
- min qty: 1
Problem:
Two internal pickings are created for “P1” and two others for “P2”,
because two different procurement:
- from “input” to “quality control”
- from “quality control” to “wh/stock2”
But as the pickings have the same location destination, two batches
are supposed to be created to group the pickings.
The `_find_auto_batch` function is triggered when the picking is
confirmed:
https://github.com/odoo/odoo/blob/16.0/addons/stock_picking_batch/models/stock_picking.py#L120
but since the pickings are not confirmed, the function is not called:
opw-3076077
closesodoo/odoo#111716
X-original-commit: 324298967cb63d7de1144c8aee2039119443e60c
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce:
- Install mass_mailing module (for test purpose)
- Create a new mailing and change `Recipients` to `contact`
- Add a new node in the domain (by clicking on +) and set :
Field => `Zip`, Operator => `in`, Value => `123`
- click on + next to value
Issue:
Domain is not updated (same issue with `not in`).
Cause:
When adding a new value to the domain, a div is added with the value
and a cross button (to remove the value from domain).
The button have a `t-on-click` attribute that call a function
(removeTag(tag_index)) and therefore as soon as the div is added,
the function is called.
Solution:
Use `() => func(arg)` syntax instead to be able to call the function
with arguments only when button is clicked.
opw-3099583
closesodoo/odoo#111714
X-original-commit: f9a9f2da88a68040642231db2489e134d1f8096a
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Go to Contacts, click Create, leave the name empty, click on a
stat button (e.g. Meetings). Before this commit, there's a crash.
It happens because the `name` field is present twice in the view,
with different `required` attrs. Only one of them is visible,
depending on the `is_company` field.
Commit [1] introduced a sub part to the required domains to fix an
issue with the way the legacy form view handled required fields
(basically, the field `name` was displayed twice in the notification
indicating that there were invalid fields), thus making those two
domains different.
With wowl views, this patch is no longer necessary, as the required
attrs is evaluated in the model, so once for each field. Thus,
having two different required domain doesn't make sense anymore
(the last one wins).
This commit fixes the issue by removing the domain sub parts added
by [1].
[1] 8143a641a2
Task 3086014
closesodoo/odoo#111711
X-original-commit: a1ed27352f393b8fff8c4f8985e3f503a07e6e37
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
To reproduce
============
- create a payment term with Balance of 3 months and a percent with 50 as value
- create a vendor bill using this payment term
- try to register a payment, the amount is not showing
Problem
=======
the amount field would be invisible if the Group Payment check box is checked,
and in this case it should be checked because it's one deadline.
Solution
========
the problem comes from the fact that the compute method that will check or uncheck
the group payment field, is called twice in same compute process but we only execute it
once because the record is protected and that's how ORM is expected to work to avoid infinite loops.
to solve the issue, `group_payment` was removed from `_get_batches` because it's not necessary.
opw-3103465
closesodoo/odoo#111710
X-original-commit: 5fd0dc7929156b193271679be90f1cbdf4e626b3
Signed-off-by: abla001 <abla@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
When sending the same survey to the same partner, the system detects it and
allows the user to choose between sending a new invitation or resending the
old one so that the user can continue the survey that might already be ongoing.
The detection was not working anymore and this fixes the problem.
Technical note: _compute_existing_partner_ids was intersecting record set
partner_ids (the one currently added) and a record set of partner for which an
invitation has already been sent. The intersection didn't work because
partner_ids relation was not completely set and instead of id, had "origin" id.
Comparing id using a filter solves the problem (using the trick that .ids,
return also the origin ids).
Task-3087702
closesodoo/odoo#111687
X-original-commit: fea798047118f0a482dc2421d92e73f51dd04816
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Dufays Pierre-Yves (pydu) <pydu@odoo.com>
Because of the M2M relation, an account.move.line can be linked to
several sale.order.lines, making the cardinality of sale_line_ids
superior to 1.
Even if it is not possible to obtain this result with standard code,
a custom module could create this situation and posting the invoice
would result in a "ValueError: Expected singleton" exception.
This commit prevents this exception by checking whether the line is
linked to at least one downpayment SO line in the method action_post.
The test also checks that the methods button_draft and button_cancel
behave properly (spoiler alert: they will fail too in 16.0).
closesodoo/odoo#111686
X-original-commit: a2344a4cd9283e3a74caf454ce218eecf5855de0
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Paul Morelle (pmo) <pmo@odoo.com>
model/model_terms translations:
A transifex link if available is displayed after the language in the translation
dialog to help translators to contribute their translations. The tooltip message
for mouse hovering is 'Contribute'
code translations:
Setting -> Translations -> Application Terms -> Transifex Code Translations
In order to reuse the list view and search bar, model transifex.code.translation
is created to store all code translations.
This model is
1. readonly
2. reloaded on demand/by cron(7 days) to avoid increasing the Odoo restart time
3. updated for new installed modules/languages while opening the list view
4. shared to all users without duplicated translations
closesodoo/odoo#111685
X-original-commit: 7b30badb52e2a948c41f4340a01f6118818c6711
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Wang Chong (cwg) <cwg@odoo.com>
Before, when we tried to open the Partner detail screen, we had an issue when the price list weren't loaded.
But since this commit: 40f0482b680a7872d338fa8fd10eec4663637b46
The price list are not mandatory anymore, we can get rid of the check that consisted of verifying the price list were set on the partners.
closesodoo/odoo#111665
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Steps to reproduce:
- Install Dashboard, Inventory apps
- Go to Inventory > Products
- Add a custom filter "Quantity on hand > 0.00001"
- Favorites > Add to my dashboard > Add
- Go to dashboard app
Issue:
JS Traceback is raised: `Expected "]", got "(name)"`
When executing the rpc call to `/board/add_to_dashboard`, the number
`0.00001`, which is passed as argument, is decoded as `1e-05` in the
python code and stored in the custom view.
When parsing the same view in the frontend, the tokenizer fails to
detect `1e-05` as a floating number and an error is thrown while parsing.
Solution:
Add regex for floating point numbers in scientific notation in `py.js`.
The regex accepts numbers such as:
- 1.2
- 12.
- .1
- 1e-02
- 1.2E-2
- 12.e+2
- .1E3
opw-3038707
closesodoo/odoo#111664
X-original-commit: d2d23e517fb81ab3779f6f0dbf0d035544c863d8
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Stefan-Calin Crainiciuc (stcc) <stcc@odoo.com>
After this commit was introduced: 3cad1312ca35c136440a98dc1b1c82a483bdbd3e
There was an error when using the half up method in the point of sale.
The method was always set to up or down even if the method should stay as half-up.
Now, we make sure to inverse the rounding method only if it's not a half up method.
closesodoo/odoo#111627
X-original-commit: 34dc7e24ec2ee3d853c06c2865fecdccf965ae71
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Since f0beddf534a57e972ac3a7bef6afa1caae1dcff3, the crud rights of
readonly fields is not sent to the client anymore.
In most cases, it has no impact, but for fields readonly server-side
and specified as editable in the xml, the client will consider
relational fields as always creatable and writable.
See:
* many2one_field.js where canCreate and canWrite are undefined in this
situation because the server doesn't send the crud data.
* owl library, where undefined props fallback on the default props
value, which is true for Many2OneField canCreate and canWrite.
After investigation, it has been concluded that modifying the data sent
to the client was too heavy for such a rare usecase that we don't want
to support anymore.
This commit fixes the only know case where a readonly field was supposed
to be editable client side, by converting it to a compute editable,
s.t. the server doesn't consider it as a readonly field and correctly
sends all the necessary information to the client for this field.
It also allows users to disable product templates creation & update in
the lines of a Sales Order (and makes sure that if it's enabled, you have
the creation/edit rights to see 'Create' & 'Create & Edit' dropdown choices).
opw-3144319
opw-3140988
opw-3080838
closesodoo/odoo#111546
X-original-commit: dbc56c66366dbb54384e2098c57484853a6d1daf
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit
==================
GST Treatment will not be assigned to those invoices/bills
whose partners don't have GST Treatment.
After this commit
=================
GST Treatment will be assigned to those invoices/bills whose
partners don't have GST Treatment.
closesodoo/odoo#111528
X-original-commit: de944b54715db0a0b6898fb9b049449c5ced29c9
Related: odoo/enterprise#36555
Signed-off-by: Josse Colpaert <jco@odoo.com>
This demo data was made for the purpose of GST return report but now we have
new functionality of GST return E-filing(l10n_in_reports_gstr) so moves demo
data in that module so we don't need the demo data in this module.
X-original-commit: 0981188715210c6e5a170e9a70f2bcb5a6785e04
Part-of: odoo/odoo#111528
Runbot currently doesn't use Pylint 3 in order to still have "style"
lints (since removed), however compatibility with pylint 3 is useful
to run tests / lints locally (and possibly eventually in future python
versions for which 2 might not be compatible).
Fix a few deprecation warnings:
- the `__implements__` magic thing has been deprecated
- `check_messages` has been renamed to
`only_required_for_messages` (better explains the purpose)
Also remove second parameter of `is_message_enabled` call, if
specified it's supposed to be a `Confidence` value, not a
number. Recent pylints changed the way it's checked, so it now errors
even if not using the confidence system (or something like that).
closesodoo/odoo#107960
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Before this commit, the `field_digits` options of the monetary field
has not been reimplemented since the owl conversion and so the digits
of the currency was used.
Now, when the `field_digits` option is given, the digits of the field
is used instead of the currency digits.
task 3072702
closesodoo/odoo#111308
X-original-commit: 996cc74745a2fb72547053991a79d233d6916587
Related: odoo/enterprise#36568
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The goal of this commit is to add the possibility to define a <control>
in the arch of a kanban view. This works exactly like in the list view
arch. So we can add <create> and <button> that will be present when the
arch is used by an x2m in kanban view.
As a reminder, <control> allows you to add buttons to an x2m in list or
kanban view without js customization:
<create> allows to add a button allowing the creation of a record with
a different context
<button> allows to add a button action.
closesodoo/odoo#111307
Taskid: 3143419
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
*: website_event
Since [1], it was not possible to customize the SEO values of an event
sub-page because a condition was inverted by mistake. Opening the SEO
dialog on those sub-pages actually displayed (and allowed to save) SEO
values related to the event main page.
[1]: https://github.com/odoo/odoo/commit/ac55f2bb113ecf7c774fe6e96d28e716184a97d1
Related to task-3129034
closesodoo/odoo#111289
X-original-commit: 2072a7739eb9a9ee87c8b3c7b0d43a82a7e2375f
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website_sale
During the big "website-in-backend" refactoring, [1] and [2] were made
to add the "edit-in-backend" and publish buttons in the systray. At the
same time, the information about if the main object of the iframe is
available to "edit-in-backend" / is published was added on the loaded
iframe's html element (as was already the information about what the
main object is).
The problem is that [1] + [2] were merged around the same time as [3]
which decided to put the existing data addition on the html element...
in a t-if. [1] and [2] ended up adding the new information only if the
user is a designer, while it is actually needed as restricted editor
users. As a result: the publish and "edit-in-backend" buttons did not
appear anymore for restricted editor users.
At the same time, [3] seems wrong on its own, as it moved some
information in the conditional block although we wanted that information
to be available even for visitors (especially, the main object which is
for example used by the product snippet*). This is fixed by this
commit too.
* Steps to reproduce:
- As a restricted editor, go to /shop in the backend iframe
- Click on a category at the top
- Edit
- Add a "Products" snippet in the category-related area
- Click on it and choose "Current" as the value for the category
=> Crash. That crash actually also occurs as a visitor on page load if
such a snippet was saved by an admin first (but the crash in that case
is silent).
Note that the "seo-object" info is not needed by public users but was
restored as a public data as it was the case in 15.0. It might make
sense to some custo. However, the "oe-company-name" info, which was
public in 15.0, is kept shown for designers only as it seems to be dead
code in 16.0 (will be removed later on in master).
Unfortunately, no stable fix can really be made to solve this issue:
this commit had to modify the existing `website.layout` XML. So to solve
this issue in existing databases, you either have to patch the view
accordingly or update the website app. That should be ok, considering
that the only real problem is that some options cannot be used as a
restricted editor user.
[1]: https://github.com/odoo/odoo/commit/f260e3c1441b380d0c9f5294d7cadcaad9c90662
[2]: https://github.com/odoo/odoo/commit/028efcbffe1cbaa00fe6a262151c75fda922008d
[3]: https://github.com/odoo/odoo/commit/b0a2a41d78292cb8b9e53788d40c6dc5915a466d
task-3129034
X-original-commit: bfb6d7820c35f3eba3bb760810866350092a16d9
Part-of: odoo/odoo#111289
The page properties and optimize seo menu items were not explicitly
marked as not shown for non-designers. An unrelated bug currently hides
those items by chance... but as that bug will be solved in a further
commit of this same PR, it had now to be explicitly hidden in that case.
Note that after this a related bug remains: the "This page" title on
top of those sub menus is left visible if no sub menu is shown and
clicking on it actually crashes. That bug will be solved in another PR.
Also note that it might make sense to show the optimize seo dialog for
restricted editor users when they have the correct rights... but this
would be an improvement to consider in master.
Related to task-3129034
X-original-commit: 26c46ba70bac227c2b6a28a941e5c4f13bfe9029
Part-of: odoo/odoo#111289
Before 16.0 and the website-in-backend refactoring made at [1], the
publish button of the frontend had this behavior:
- The record is unpublished
- Click on the publish button -> a rpc to publish is sent but the
switch visual state is not updated (the internal checkbox is still
unchecked)
- The rpc comes back with the response -> the switch visual state is
updated (red -> green)
This is actually the behavior since the bug fix made at [2]. The main
point of this commit was to prevent toggling the checkbox while its
javascript behavior was not initialized yet.
From 16.0, that loading problem is not an issue anymore, as the publish
button is instantiated client side and thus only appears when it is
possible to use. We can thus update the visual switch state as soon as
the user click on it for a better UX. However, that was flawed:
1. If the publish action actually failed, the switch was kept
checked/unchecked while it should be reverted to unchecked/checked.
2. If you clicked very fast multiple times on the button, many RPC were
sent and their result order was not guaranteed.
3. There is no possibility for tours to wait for the actual publish
action to be done... and that will be needed in a further commit of
this PR.
This commit fixes all those flaws:
1. If the RPC fails, we now revert to the status before the user clicked
on it. Inspired by [2], the internal checkbox is now disabled, which
leaves its status entirely up to OWL instead of browser behaviors.
2. The switch now stops listening to clicks while a RPC is being
performed.
3. While a RPC is being performed a "data-processing" attribute is added
to the whole switch area.
Note: in master, the whole switch system should be reviewed. The publish
button one's structure actually makes no sense: a <div> which contains a
<a> which contains a <label> (already invalid DOM), with the <div> being
the event handler of the switch status changes...
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[2]: https://github.com/odoo/odoo/commit/2e751d80dd4b23abf374d5aa488827faaa593e62
Related to task-3129034
X-original-commit: 36a8fe44d6ec609a9bad8d960768766a44d4074e
Part-of: odoo/odoo#111289
Harmonize _get_display_price between event_sale &
event_booth_sale.
Do not rely on contextual stuff when information is
available without using contextual data.
closesodoo/odoo#110833
Related: odoo/upgrade#4256
Related: odoo/enterprise#36210
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Harmonize currency conversion of unit prices:
* Make sure no rounding is applied during the conversion
(it'll be managed by the price_unit decimal precision
and the currency rounding will only be applied by the
monetary fields later in the computations).
* consistent parameters for the conversion (date,
company, currency).
* code simplification
* consistent behavior when the SO has no currency specified
...
Part-of: odoo/odoo#110833
This commit makes the data entry of numeric fields
easier by selecting all the content of the input on focus.
task 3132899
closesodoo/odoo#110181
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit hides name of user from many2many avatar user of
activity view similar as kanban view so it'll display many2many
tags properly in activity view.
task-3132890
closesodoo/odoo#109855
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Migration of the js code of `product_pricelist_report` to OWL.
Task - 3058360
closesodoo/odoo#105341
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: Xavier (xlu-odoo) <xlu@odoo.com>
Seems unnecessary, most of the information already lives in
`sys.modules`. We can just check that.
There are a few changes in behaviour, but they seem minor:
- if post_load fails, subsequent attempts to load the module will
"succeed"
- since we didn't remove/reload the module, a failure because of an
incorrect post_load wasn't fixable, however it was possible to
update the manifest
Still seems like a wonky state to be in, and one we should ignore.
Also remove the logging of the error: since we're re-raising as-is,
the parent logs it with a traceback, so this is unnecessary and
redundant.
closesodoo/odoo#103933
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Yannick Tivisse