This commit simply changes the title of the skills resume wizard for
clarity.
task-3660000
closesodoo/odoo#146294
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit:
Sometimes applying bulletlist does not produce the expected bullet list
formatting .This issue arises when the selection is on an emptyTextNode(""), and
the traversal of nodes using getTraverseNodes results in the same
emptyTextNode(""). In the toggleList function, we typically remove the
emptyTextNode(""), leaving no appropriate node for creating a bullet list.
After this commit:
Now it will create bullet list because we move the selection to its parent when
it is on an emptyTextNode(""), similar to what we have done with the "BR" element.
task-3547574
closesodoo/odoo#150854
X-original-commit: d5380742b05c64ced7eee92fcf520f208e33819e
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
We give preference to the bom in the stock moves for the sale order lines
If there are changes in BOMs between the stock moves creation and the
invoice validation a wrong price will be taken
closesodoo/odoo#150506
X-original-commit: 855727eccb4ba9a2af72350b6ab9cc40ba7e50d9
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
After
https://github.com/odoo/odoo/commit/54a6f1688fb8d15b662848b03cecbe8236292d07,
the `TestConfigureShops.test_should_not_affect_other_pos_config` and
`TestConfigureShops.test_is_header_or_footer_to_false` started to fail randomly
in runbot. This is because when res.config.settings form initializes, it may
start with `pos_config_id` that contains pricelists that are not compatible to
the currency of the pos_config that will be selected in the form.
This commit makes sure that when the `pos_config_id` is changed to something
that doesn't use pricelist, the `pos_available_pricelist_ids` field is updated
accordingly.
Runbot Errors: 31294, 31293
closesodoo/odoo#150454
X-original-commit: f271b0e373b29b7d708c4fab454318776e1bee91
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Before this commit, when no conversation was selected in the
Discuss app, folding a category such as "Channels" results in
a crash.
This happens because `store.discuss.thread` is `undefined`, so it
must be properly guarded in the template of discuss sidebar category.
closesodoo/odoo#150828
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
__Current behavior before commit:__
If `child` is not an `Element` (like a Text or a Comment node), the call
to `querySelectorAll` at the following line will crash.
__Description of the fix:__
End the current loop iteration if `child` is not an `Element` to avoid
calling `querySelectorAll` on it.
__Steps to reproduce the issue on runbot:__
In 15.0:
- Open Email Marketing > Mailings > Create > Second template
- Drag and drop a `Comparisons` block
- Display source code
- Write some text under the `<div class="card ...">`
- Save --> Traceback
In 16.0+:
- Open Email Marketing > Mailings > New > `Start From Scratch`
- Drag and drop an `Event` block
- Replace one of the image (a comment node will be added [here][1])
- Save --> Traceback
opw-3682469
opw-3689181
[1]: https://github.com/odoo/odoo/blob/df1b43a6de5ad15a8fee3713de7d8ec926c61f12/addons/web_editor/static/src/js/backend/convert_inline.js#L715closesodoo/odoo#150752
X-original-commit: 3d1c95d9d143df35320e97abf898f673f4bb1a68
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Signed-off-by: Julien Launois (jula) <jula@odoo.com>
Steps to reproduce:
- Setup easypost delivery
- Create a service product and publish it on the website
- Add that product alone to the cart and proceed to payment
Bug:
Error raised because total weight of the order is null
Fix:
no delivery will be created so we should skip the check if no deliverable
product is present on the order
note: on "_get_shop_payment_errors" switched the order to short circuit
"_get_delivery_methods"
opw-3647420
closesodoo/odoo#150735
X-original-commit: 3108339921dd7af65daacf60dc0104713116557b
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Problem:
In some places I think it is necessary to use sudo to avoid permission
errors when creating actions or something else from a other model.
For example, I have a picking created from PO attached to MO. When
receiving inventory in a smaller quantity than actual quantity, will
create activity schedule on MO. But if you don't have the rights, you
will get an error
closesodoo/odoo#150697
X-original-commit: ac1862ddc2dec0269a156d5470b940a7d85cc078
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
In https://github.com/odoo/odoo/pull/105119, new accounts were added
to represent employee-related expenses. Based on the non-official
document https://swissdec.ch/document/share/295/4cc46aca-8b47-49e9-882a-03c37eb8dea3
we used account codes 2990 and 2999 for accounts 'Indemnities' and
'Company Car Correction'.
However, these accounts have no place with the equity accounts in 29xx,
since they are not equity but rather expense accounts. Examples of CoAs
that include employee indemnity accounts place them under account group
5 with the other employee-related expenses.
(e.g. https://plancompta.com/plan-comptable-suisse-pcg-2021/)
As such, we move accounts 2990 Indemnities -> 5840
and 2999 Company Car Correction -> 5031.
Fixing this in stable will not cause any in-database corruption, since
the updated code is only executed when the CoA is loaded/reloaded.
However, users will need to reload the CoA in order to take advantage
of the fix.
This also ensures that the Swiss Balance Sheet is balanced.
taskid:3060790
closesodoo/odoo#150692
Related: odoo/enterprise#54941
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Bug
===
The decimal property crash when added in a list view, if some records
have False as a value.
Technical
=========
Since fe797a03285ec9c81d29ed631839c91e2b9957a4 , we use the wrong
Formatter in the Float field.
Task-3698415
closesodoo/odoo#150682
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Install mass_mailing with demo data, send a mailing using the "Thank
you for joining us" template. Inside your mail client, click on the
LOGIN button, this open your web browser on a link-tracker URL but the
page fails to load because "The page isn't redirecting properly".
Inside the template of that "Thank you for joining us" mail, the logging
button is basically defined as follow: `<a href="#">LOGIN</a>`, a URL
with a fragment that is empty, a redirection to the current page.
Upon rendering that template and send it to the recipients, all links
are wrapped inside a link-tracker for well tracking purpose, this
created a link `/r/xyz` targeting `#`. Upon accessing that `/r/xyz` URL
the client would be redirected to `#` which in that context is actually
`/r/xyz#`: the link-tracker itself. The browser detects that there is a
redirecting loop and show an error instead.
The problem is solved by saving an absolute link with the link-tracker
instead of a relative one.
Task-3603607
closesodoo/odoo#150678
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
It was technically possible to register a link that would loop on itself
by abusing the query and fragment parts of the URL. It was possible to
register a link targetting `#` and get the following HTTP exchange which
enter an infinite loop.
GET /r/bAd HTTP/1.0
HTTP/1.0 301 Redirect
Location: #
GET /r/bAd# HTTP/1.0
Prevent such links from being registered and highlight flaws inside the
`validate_url` method with unittests.
Part-of: odoo/odoo#150678
Steps to reproduce:
- Install Contacts app
- Go to General Settings and add another language
- Add a new contact to a parent.
- Don't add a specific contact name
- Assign a contact type (delivery address, invoice address, other address)
- Go to the list or kanban view of the contancts and change the language
- The type of the contact listed next to the parent name is not translated from English.
Investigation:
- When the contact name is not set, the `display_name` displayed in both kanban and list views is set by concatinating the parent name with the contact type.
- The line https://github.com/odoo/odoo/blob/03b7e17faef4075dbbb805bca4e7f40f7fbcc988/odoo/addons/base/models/res_partner.py#L345 in the function `_compute_display_name`, `with_context({})` in particular basically enforce to compute the name in english language regardless of the active language. That actually makes sense as the `display_name` field has `store=True` https://github.com/odoo/odoo/blob/03b7e17faef4075dbbb805bca4e7f40f7fbcc988/odoo/addons/base/models/res_partner.py#L199
Solution:
- add a computed field that is not stored that gets recomputed on changing the language.
opw-3569171
closesodoo/odoo#147650
X-original-commit: 60b3ae846de59b1f6e71df68e99e29758ba734fe
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Signed-off-by: Ali Hassan Youssef (alhy) <alhy@odoo.com>
This commit fixes a spacing issue with the count of messages sent in the
portal chatter being placed right next to the word `comment`, without a
space.
fixes#147801
task-3651084
closesodoo/odoo#147496
Related: odoo/enterprise#53383
Signed-off-by: Chrysanthe Gomrée (chgo) <chgo@odoo.com>
This commit fixes some layout issues from the portal redesign.
The aims of this commit is to :
1) fix some issues with the column layout, mainly in the quotation section.
2) fix some spacing issues by using the right classes and better units.
3) fix the typescale and the information architecture with the right
heading tag.
4) fix some layout issues within the column layout and fixing unconsistent
layouts shared between different items.
5) fix an issue about the first information of the sidebar often
being hidden when scrolling, due to the sticky position of the sidebar
task-3651084
Part-of: odoo/odoo#147496
Since [1] a margin is applied when another `o_we_user_value_widget`
follows a color palette. Unfortunately this is also applied when the two
elements are not on the same row. Because of this the "Slideout Effect"
option below the "Colors" option of "Footer" looks like it is indented
while it is unrelated to the color selection.
This commit restricts that margin to elements that belong to the a
`we-row`.
[1]: https://github.com/odoo/odoo/commit/2f81c6ae68751d5f93c30aef822730ee04ead391
task-3696870
closesodoo/odoo#150701
X-original-commit: 50c0a5479a11fef0b03bf319283817a94a32cea4
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Reproduce the bug:
1. Create a survey and share it with someone with a deadline
2. Complete the survey as that someone
3. Change the deadline of the answers to a date in the past
(simulates reviewing later on)
4. Go to the participation record and try "Print"
Issue: You are denied access to review the answers because
the deadline is in the past.
Fix: Do not check deadline for reviewing/printing answers. This
deadline is only a limit for answering the survey.
Task-3680802
closesodoo/odoo#150793
X-original-commit: 8f4c5c85c9bc194b4fec9698753db4cc84a08a90
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
This reverts commit 652edc38527b14995f017d514053a57825091813.
It creates a new issue with valuation change.
Steps to reproduce:
-Create a new product with a cost of 10 (std, manual)
-Create an inventory adjustment to set the quantity to -3
-Change the product's category to real-time
-Now the valuation for this product is -30€, but the accounting part has 30€, creating a difference of 60€."
A better solution to fix both issues has been tried but it was far from
optimal. Since it's an edge usecase we will not support it until master
closesodoo/odoo#150112
X-original-commit: a3bae79d8102f528c4947b2231ecabe8cf907bce
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Description:
Add missing index to speed up queries related to the P&L reports. As the
report queries per `account_type` it's beneficial to have it indexed.
The field is not write heavy, and has low count of distinct values (
since it's a selection field), so there is little downside of having it.
It is meant to support the changes done in the related enterprise PR.
Reference:
opw-3659497
closesodoo/odoo#150775
X-original-commit: 01ec86ded9128ae9fd11d27285e64d139a0ce31b
Related: odoo/enterprise#54986
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
When the IoT V23_11 checkout a Odoo DB 15.0, the newest module:
urllib3
PyPDF2
Werkzeug
Can't run this Odoo version.
So we fix the version of these module to match to Odoo 15 / 16 / 17
closesodoo/odoo#150708
Signed-off-by: Yaroslav Soroko (yaso) <yaso@odoo.com>
Steps to reproduce
==================
- Use a mobile viewport / device (small window)
- Go to Dashboard
- Double click on a chart
=> `this.env.openSidePanel is not a function`
Cause of the issue
==================
On mobile, the MobileFigureContainer is used instead of the Spreadsheet component.
The both use `useSubEnv` but the mobile one was missing the
openSidePanel function.
Solution
========
Add an empty `openSidePanel` function that does nothing.
opw-3677552
closesodoo/odoo#150702
X-original-commit: 990452ad985b1515ba565ff1fe8c6bbaa14fb031
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Steps to reproduce
==================
- Enable analytic accounting
- Go to customer invoices
- Open a record
- Open studio
- Click on the Invoice lines > Edit list view
- Set the analytic field as required
- Close studio
- Create a new record
- Add a new line
- Click on the analytic field
- Close the popup
- Save the record
=> Even though we didn't set a value for the field, it is saved
Cause of the issue
==================
The actual field value is an empty object.
The validity of a field is checked here [0].
An empty object is considered a truthy value.
When setting the required attribute directly on the python field
declaration, an empty object does not pass the check
Solution
========
Add a specific check for json fields. When the value is either false
(not set) or an empty object, the field is considered invalid.
---
[0]: https://github.com/odoo/odoo/blob/23f01c533512cbfb33e90509e22cd3c3c4f99d40/addons/web/static/src/views/basic_relational_model.js#L284
opw-3659763
closesodoo/odoo#150677
X-original-commit: 51b538b3f678298f27bbbf458de5696706c18349
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
In a previous commit we fixed Swiss localization's taxes data.
We changed two children taxes that had wrong tax_type_use since it depends
on their parents.
This could raise the python constraint `_check_children_scope()` which is preventing
some databases to correctly update their taxes.
See https://github.com/odoo/odoo/commit/7b07df873535446f97abc1de9176b9332de5cb07closesodoo/odoo#150669
X-original-commit: 90e064140b88b77d75686558106f79664da4af48
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
To reproduce on runbot:
- Log-in as admin
- Enable debug mode
- Go to Settings / General Settings
and ensure that there is a alias domain configured for the
current company
- Go to recruitment app
- on "Experienced Developer", open the option dropdown (meatball)
and click on "Trackers"
- observe there is no button "Generate Email"
The `has_domain` field serve to check if the mail alias domain is
correctly configured, before odoo/odoo@638e0f658, is was computed
only from the `mail.catchall.domain` ICP, now we only consider
the alias domain from the recruitment source alias.
But for new record there is no alias, so `has_domain` is always
falsy which prevent the `Generate Email` button to be show.
This commit fallback to the job's or user's current company mail alias
domain to check if mail alias is correctly configured when there is no
alias on the recruitment source.
closesodoo/odoo#150645
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
In one of the schematron rules for CIUS-RO, there is a rule for
DocumentTypeCode element in the XML that failed the validity test.
`
<rule context="cac:AdditionalDocumentReference">
<assert id="UBL-SR-43" flag="fatal" test="((cbc:DocumentTypeCode='130') or
((local-name(/*) = 'CreditNote') and (cbc:DocumentTypeCode='50')) or
(not(cbc:ID/@scheme) and not(cbc:DocumentTypeCode)))">
[UBL-SR-43]-Scheme identifier shall only be used for invoiced object
(document type code with value 130)
</assert>
</rule>
`
This commit fixes the current behavior by applying this behavior:
- DocumentTypeCode won't show up when exporting Invoice XML
- DocumentTypeCode will show up with the value '50' when exporting
CreditNote XML
closesodoo/odoo#150613
Task-id: 3649426
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Steps to reproduce (17.0+):
- Go to an event website page > go to “Site” > “This Page”.
- The menu item used to edit the page content menu “Edit Event Menu” is
duplicated.
After the event page refactoring in [1], a second template using the
same content menu ID was added to customize the UI for mobile.
And since the “Edit Menu” items generation is based on detecting current
sub menus from the DOM using the same ID (`data-content_menu_id`), we
get a new menu item in the nav bar for every menu template using it.
The goal of this commit is to fix this behavior by simply ignoring the
duplicated menu IDs (The same menu record will be edited anyway).
Remark: the behavior fixed by this commit was detected in 17.0, but we
target 16.0 to prevent any potential issue linked to duplicated menus in
the DOM, also, the duplicated data attribute will be removed in master
(one ID is enough for the content menu to be detected and edited.)
[1]: https://github.com/odoo/odoo/commit/9f2442d09b62fcb3f687ec39928ea0e3ac49557e
task-3645985
closesodoo/odoo#150568
X-original-commit: e8ebb33269cbb8d049ca3e4749c486b6d137e044
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Commit [1] (later refactored by [2]) hid the buttons which allow to
edit the main website menu and custom website menus (as the ones in
event pages), when using Odoo on a mobile device. Reading the code and
related commits, this seemed to have been done for no apparent reason.
After testing 16.0, it appears that menu edition from mobile devices was
actually not working: the re-ordering UI was strangely hidden.
After investigation, it appears that this was solved by chance, thanks
to the unrelated commit [3] in 16.2. That commit indeed removes legacy
CSS which was hiding all jQuery.ui.sortable UI elements by mistake.
In 17.0, this was further improved anyway by not using jQuery.ui anymore
(with [4]) and thus editing website menus from a mobile device works now
perfectly... except that the buttons to open the menus edition dialogs
were still hidden. This commit enables them. It was chosen to do it in
17.0 and not 16.2 as it is more an improvement than a fix in the end.
[1]: https://github.com/odoo/odoo/commit/78c59afd133de8308f4eeb6e1a2a930d870878e7
[2]: https://github.com/odoo/odoo/commit/2dc82504e08cc370b67cdf1d580f26705870a085
[3]: https://github.com/odoo/odoo/commit/ee3e28987eb1ec23b8bacc7c4043d9690aada144
[4]: https://github.com/odoo/odoo/commit/a4b1c268131ed771dd68616a26a9f1ce50a189f0
Related to task-3645985
closesodoo/odoo#150530
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
- Create a company A with a ebsite
- Create a company B without website
- Create user 1 in company B only
--> Issue when user 1 go to /shop --> error 403
Due to security restrictions, you are not allowed to access 'Companies' (res.company) records.
closesodoo/odoo#150529
X-original-commit: be5bf24234955a4f9ccc044482b71ab37a44b8b0
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Reproduction:
1. in Note, type ` abcd ` in an empty note
2. color the background of all the text, bold `abcd`
3. select from the end till the letter `b`, try to change the color,
traceback pops up
Fix: The main reason is we remove element in `splitElement`/
`splitAroundUntil`. In this special case, there are two selected nodes
which returns the same font element. The first font element will be
removed and replaced first. Because the first font element doesn’t exist
anymore, when recovering selection, the second element considered as
collapsed and the recovered selection is a caret. Thus the color picker
is gone after applying the color (preview)
The fix is then, we always make sure that the font we have is still
connected to the page (exist in the page), otherwise it’s problematic to
apply color to a non-existing element and recover cursor from it. If
there is font element(s) that is not connected, we simply get the fonts
again, because new font element is created for the second node, it won’t
split (remove) the first node’s font element again
Task-3476494
closesodoo/odoo#150500
X-original-commit: 06a8b930176093e2c5a853b78431316af90f3550
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
Signed-off-by: Jinjiu Liu (jili) <jili@odoo.com>
Co-authored-by: Goaman <nby@odoo.com>
Steps to reproduce:
-------------------
- install helpdesk_fsm and sale_timesheet;
- to be in a multi-company environment;
- create a new helpdesk team with "Timesheets", "Time Billing";
- the newly created project has no company;
- create a service product that creates a task with UoM in hours
in the newly created project for the helpdesk team;
- create a sale order with this product with a quantity of 100 hours and confirm it;
- in the helpdesk app (in the new team), create a ticket linked to the sale order line
of the product (the customer is necessary);
- on the ticket the "Remaining Hours on SO" is 100 hours;
- create a timesheet directly in the tree view;
- the remaining hours of the sale order are reduced;
- create a timesheet from the timer;
- the remaining hours of the sale order are not reduced;
Cause:
------
During the link between the newly created timesheet and the ticket,
we write to the `helpdesk_ticket_id` field (during the flush) in the `account.analytic.line` record.
As a result, we pass in the override of the `write` method, which calls `_timesheet_preprocess`.
Without a company on the project (or on the analytic account if there is one),
the value `{'product_uom_id': False}` will be added to the values to be written to the timesheet.
Without a unit of measurement, the timesheet will not be used to calculate the remaining hours.
Solution:
---------
Add a fallback on the current company if no company is found.
opw-3651830
closesodoo/odoo#149917
X-original-commit: 2e5c13b0dea40f349e96cadf9d02fdb3c1746c7e
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Some logic of the `payment.provider` and `provider.method` models was
not properly covered by unit tests.
closesodoo/odoo#149833
Related: odoo/enterprise#54930
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This commit improves the user experience with pdf quote builder by
- showing document for both product template and product variants
- providing pdf example for headers/footers
task-3543479
closesodoo/odoo#146183
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Currently, if you have a pivot grouped by a date field, aggregated by week
month or quarter, sorting all the pivot cells does not work as expected
when sorting based on the date header column.
"April 2023" would end up being before "March 2020" just because "A" is
before "M". Similarly, "W1 2023" is before "W2 2020" and "Q1 2023" is before
"Q2 2020"
With this commit, for months aggregates, the result of
`=ODOO.PIVOT.HEADER(1,"create_date:month","04/2023")` is currently the
string "April 2023".
The result now becomes a real date just like any other date value
in a spreadsheet. It's the number corresponding to the first day of the
month.
For week and quarter aggregates, we could move the year first ("W1 2023"
becomes "2023 W1"). However, we decided not to do it to keep consistency:
- with other places in odoo (pivot views)
- with the way we talk/think (quarter/week comes first)
closesodoo/odoo#139295
Task: 3570281
Related: odoo/enterprise#49300
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
This commit fixes 2 very similar issue.
See enterprise commit.
- Group a pivot by any date field, with the day aggregate
- insert it in spreadsheet
- autofill a pivot function
=> the autofill tooltip displays the day number instead
of the day formatted as a date.
- on the same pivot
- click on menu "Data > Insert pivot > insert pivot cell > [you pivot]"
=> in the dialog, numbers appears for the headers.
Task: 3570281
Part-of: odoo/odoo#139295
This commit factorizes how the format is computed for ODOO.PIVOT and
ODOO.PIVOT.HEADER functions. It was essentially duplicated.
Also move the date(time) format responsibilty to each time adapters,
instead of handling the different aggregate cases separatly.
This commit also prepares the next commit which fixes a formatting bug.
Task: 3570281
Part-of: odoo/odoo#139295
For the ODOO.PIVOT.HEADER functions, "special" values such as measure and
total were managed in different places (total management was also duplicated
see enterprise commit).
Now the measure and total are managed in one place, in the high level method.
There's also now a dedicated method to get a measure display name. The method
`getGroupByDisplayLabel` was perverted at that purpose (see enterprise commit)
Task: 3570281
Part-of: odoo/odoo#139295
Method names in the pivot data source/model are not particularly clear
and self-explanatory.
To commit renames some methods (and their argument names) with hopefully
more meaningful names.
I'm also moving `getDisplayedPivotHeaderValue` (now
`computeOdooPivotHeaderValue`) from the model to the data source. It's
a high level function, the implementation can be in the data source.
Task: 3570281
Part-of: odoo/odoo#139295
Before this commit:
When a user edits an article and selects the restore button to revert to a
previous version, the displayed time is incorrect because it shows universal
time instead of the user's timezone.
After this commit:
When a user edits an article and utilizes the restore button to revert to a
previous version, the timestamp will now reflect the time in the user's current
timezone.
task-3641579
closesodoo/odoo#149177
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Actually when we link a DB and the iot need checkout a
specific version of Odoo, the service odoo in the iot
is still active.
This can disrupt the checkout and make the box unusable.
So now we stop the odoo service before the checkout.
closesodoo/odoo#150190
X-original-commit: 3e6700c7be8e58f07791ab1ef2b7b77b7a0597e2
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Signed-off-by: Yaroslav Soroko (yaso) <yaso@odoo.com>
*website
Steps to reproduce:
- Drop a "Text-Image" snippet on the website.
- Click on a column and hide it on desktop.
- Click on the parent snippet and hide it on desktop.
-> The column is not a child of the parent in the invisible entry.
Since [1], invisible snippets are shown hierarchically in order to
better visualize the "parent-children" relation that could exist between
them. To do so, [1] based its logic on the `.o_snippet_invisible` to
find the invisible elements. However, since [2], a distinction has been
made between elements that are hidden only on desktop, only on mobile or
on both depending on some conditions. The goal of this commit is to take
the new `o_snippet_mobile_invisible` and `o_snippet_desktop_invisible`
classes into account at the creation of the invisible entry.
[1]: https://github.com/odoo/odoo/commit/922d3e63b597b1ef7fbbb5ebb4641a3ad8bdf4ed
[2]: https://github.com/odoo/odoo/commit/3103e0553011b5c1f4078972d7a88fa3fd4068b2
task-3679823
closesodoo/odoo#150512
X-original-commit: c8f247ee5fa178f012b2852cba3d0e9322a2c3a6
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
Current behavior:
You couldn't delete an iot_box if a pos_printer was linked to it.
You always get a validation error saying that "Proxy IP cannot be empty"
To fix this we first want to check that the device_id linked to the
printer still exists. To do this we need to move the constraint to the
pos_iot module (because the device_id field is defined there)
Steps to reproduce:
- Install pos_iot
- Activate preparation printer in POS
- Create a printer and link it to an iot_box device
- Try to delete the iot_box
opw-3597370
closesodoo/odoo#150502
X-original-commit: 7b41e51043c1f80971f6cc698876f8bda35f07ef
Related: odoo/enterprise#54874
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
vifo