*: website_crm, website_event, website_event_track
Before this commit, when accessing the visitor views without having any
event rights, an error was triggered.
This commit restricts the display of the `event_registration_count`
field on the `website_visitor_view_form` restricted to the
`event.group_event_user` group so that its invisible condition does not
fail. Similarly it restricts a visibility condition on
`event_track_wishlisted_count` to the `event.group_event_manager` group.
To avoid encountering the same issue with further extensions of
`_compute_email_phone` on the `website.visitor` model, we make its
fields `compute_sudo=True`, and revert the specific `sudo` that had
been added in [1].
Steps to reproduce:
- install `website_event`
- set Demo user to have no Events right, but be an "Editor and Designer"
for Website
- register to an event as an anonymous user
- access the Visitors page as Demo user
=> An error was produced.
Steps to reproduce (2):
- install `website_event_track`
- set Demo user to have no Events right, but be an "Editor and Designer"
- access the Visitors page as Demo user
=> An error was produced.
[1]: https://github.com/odoo/odoo/commit/5ba09c2cb2bb180cfb1363c352f35bd8cf3b132b
opw-3537849
closesodoo/odoo#139271
X-original-commit: 4cb18fab5e8d14dd9a2dfb5cb3e65b43fab02846
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Address form forced the input of phone fields.
1) It only makes sense for shipping addresses by default, for delivery purposes
2) It was not properly handled in global checks, so you could do the whole
checkout flow without having a phone set on your address, but if you went to
the address page, you wouldn't be able to save as your phone would be invalid.
Side-change: do not check shipping address validity for orders without delivery
(only services).
closesodoo/odoo#138026
Related: odoo/upgrade#5248
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
* Avoid posting crappy forms when a redirection does the job
* use a dedicated route /shop/cart/update_address for address changes
* clean code from recent PR on invoicing address
* Public user shouldn't be able to create billing addresses
* Logged customer should always see his own partner as billing/shipping
address choices.
Part-of: odoo/odoo#138026
When importing a pivot with a date field in week format, the date was
formatted as "W2023 40" instead of "W40 2023".
closesodoo/odoo#137682
Task: 3539629
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
The new Libros Registro de IVA export from l10n_es_reports is very similar to l10n_es_edi_sii
We want to reuse things in l10n_es_edi_sii but it will require l10n_es_reports to depend on it first, which is not a good thing since the Libros export are used mainly by SME that does not have l10n_es_edi_sii installed yet
This commit refactor some part from l10n_es_edi_sii to l10n_es so that l10n_es_reports can reuse things from l10n_es_edi_sii while not depending on it
closesodoo/odoo#136983
Community-pr: https://github.com/odoo/odoo/pull/136983
Enterprise-pr: https://github.com/odoo/enterprise/pull/47578
Task-id: 3394451
Related: odoo/enterprise#47578
Related: odoo/upgrade#5304
Signed-off-by: Josse Colpaert <jco@odoo.com>
*: mass_mailing
This commit introduces options for the flex column layout and the
horizontal resizing to be used on mobile and be independent from
the desktop layout.
This makes it possible to:
- Have different number of columns on mobile and on desktop.
- Use different column widths and offsets for mobile and desktop.
- Reorder columns independently.
The behavior expected from the columns is:
- In the editor panel, Cols indicate the number of columns per row on
both mobile and desktop. The option is conditional of your environment:
you edit the number for the screen size of your current resolution.
- When columns have different sizes (either because it is the default
behavior of the snippet, or because the user resized some), the counter
should read "Custom". Same when the user changed some offsets.
- If manual modifications were made on width and offset, they are reset
on the current display if the number of elements is updated. This was
decided because an old, specific layout with custom offsets / width
doesn't work well with a different number of elements. (This is also the
default behavior before this PR with desktop-only modifications.)
The expected behavior when reordering is:
- On mobile, it should only affect the mobile layout.
- On desktop, it should affect both layouts.
In order to have a coherent feature on both mobile and desktop as well
as correct some non-ideal but non-blocking behaviors, the commit also
changes the following behaviors:
- When setting a columns count lower than the current number of items in
the `.row` container, extra items are now wrapped on the next flex-rows
(still within the container) instead of being deleted.
- When going from e.g. 3 to 5 columns (and as many items), the change
happens all at once instead of each item being visibly added one by one
on the next row, then brought back to the first row.
- The columns count automatically updates when resizing an item, instead
of updating only after you click somewhere else on the snippet.
This commit also adds a test to validate the new behavior.
task-3097045
closesodoo/odoo#117562
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The logic done in the `_computeWidgetVisibility()` method of the main
`SnippetOptionWidget` should have been placed in the `SnippetMove`
sub-widget as an override method.
This commit moves the logic at its right place and removes an unneeded
condition.
task-3097045
Part-of: odoo/odoo#117562
This commit implements two generic utility functions with similar
behavior that check whether the view is mobile or desktop:
- For web_editor: depending on the view of the targeted element
- For website: depending on the context
task-3097045
Part-of: odoo/odoo#117562
The Belgian localization has been updated to reflect the official Charts
of Accounts.
Users now have the choice between the official CoA for Companies or the
one for Associations and Foundations.
All related terms and translations have been reviewed and corrected in
the 3 official languages (nl, fr, de).
Non-official languages have been removed, since they both don't make
sense and they did not work because of targeting an ancient version of
Odoo.
Finally, the 580000 account has been set as the default Internal
Transfers account, avoiding a second 58 account to be created.
task-3086473
task-3258014
closesodoo/odoo#117480
Related: odoo/enterprise#35771
Related: odoo/upgrade#5291
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Currently we require the account lines `code` field to be unique across
all reports in a database. Since Reportalypse, this is not required
anymore, since we search by default only in the current report unless
we specify a `cross_report` subformula. Then it will take the first one
it finds.
In this commit, we relax the condition to have unique `code` fields per
report, instead of globally.
Furthermore, we add a test utility to check lines with the same code to
have the same properties. This is useful for localizations that have
multiple versions of the same reports, containing identical lines in
multiple report. This way we can ensure they are always calculated the
same way across reports.
task-3086473
Part-of: odoo/odoo#117480
Reproduction for creation:
1. Create a link using /link
2. Click after the link, press enter
3. The link and cursor disappear.
Reproduction for cancellation:
1. Create a link using /link, don’t save it but cancel it
2. Click after the link, press enter
3. The link and cursor disappear.
Fix: After clicking the save button of the link dialog, the next history
step is not correctly set up as the history step is not unpaused. This
causes the mutation list of the current step to have all the mutations
before starting the link insert. Thus after the link creation, whenever
the historyRollback is executed, it’s rolled back to the very start
The cancellation has two cases, clicking the discard button or clicking
the close button. Unfortunately, they have to be handled differently.
For clicking the discard button we need to bind the button with a
function doing the historystep then close. For the close window button,
we have to rewrite the close function by overwriting
this.env.dialogData.close. The overwrite method is specified in this
commit: https://github.com/odoo/odoo/commit/dc1191f6939c4bbf5cfcc865884813610f4f8f2c
task-3446357
closesodoo/odoo#139325
X-original-commit: 60089e7e100039670d98f2f41b4f56fafdb8f830
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Steps to reproduce
==================
- Go to budget analysis
- Switch to the pivot view
- Unselect the first three measures
- Save the current search and set it as default
- In the measures dropdown, there is only two measures remaining
Cause of the issue
==================
- When `context.pivot_measures` is used, the measures are computed from
it and those that comes from the metaData are missing.
opw-3544823
closesodoo/odoo#139315
X-original-commit: b11266cc377fa4753a0ee609258d9919f1ba5496
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Step to reproduce:
- Create company specific sequences for purchase agreements.
- Create a purchase agreement for Chicago company
- Select both comapanies for current user and switch to San francisco
- Confirm the call for tender
Bug:
sequence from San francisco is applied since ir.sequence takes current
company by default
Fix:
for company specific purchase agreements apply their own companies sequence
opw-3505571
closesodoo/odoo#139310
X-original-commit: 1e7625bb132909b892311a0da3bac9585217bd8c
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Before, the product reminder in mobile never disappeared, it displayed
the last product selected and it was impossible to remove it, even when
changing page and returning to the product list.
Now, it's displayed when the product is clicked, and when you click on
something other than a product, it disappears. When you change page and
return to the product list, it's only displayed the next time you click
on another product.
closesodoo/odoo#139307
X-original-commit: 3fd36f9a3deecdf6677f4a4dbbb60e14141811c1
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
Signed-off-by: David Monnom (moda) <moda@odoo.com>
We're removing the default pin code on demo data to not restrict access
to other apps that depend on it such as the new shop floor app
closesodoo/odoo#139304
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Problem
---------
Directly after setting up peppol, the fetch button on the purchase
journal (in the dashboard) is not showing.
Objective
---------
Make sure the button is shown directly after the journal is set up.
Solution
---------
When setting up peppol, the compute function that computes the peppol
purchase account is triggered. However, this function would not set up
the journal's `is_peppol_journal` to true. Thus, no button was showing.
Adding that line solves the issue.
task-#######
closesodoo/odoo#139293
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
Reproduction traceback:
1. Navigate to POS/Sessions
2. Open Studio
3. Navigate to Reports
4. Open Sale Details report
After this commit, if the report is open without any session or config
the currency used is the one from the company.
closesodoo/odoo#139254
X-original-commit: 79be7208116f6c2749871c0af1d548da58b1b7fa
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
When `_resetFromClient` returns an error, `_historySyncFinished` should not be
set to true since the history was not updated from the requested snapshot.
Also await the result of `get_client_avatar` and `get_client_name` during
`rtc_data_channel_open` so that no error is produced during tests after calling
`removePeers` without properly awaiting those promises.
Export collaborative test utils for usage in Knowledge.
task-3551505
closesodoo/odoo#139040
X-original-commit: fb389213078e96c97b7187248dfdf79ad331db9f
Related: odoo/enterprise#49170
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Damien Abeloos (abd) <abd@odoo.com>
There's no need to recompute the table structure
every time. The pivot model is never mutated, we can safely
store the table.
closesodoo/odoo#138594
Related: odoo/enterprise#48910
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Allows to "See records" or "Set matching filter" on ODOO.PIVOT.TABLE
cell results.
(from the context menu in "spreadsheet mode" or by clicking on cells
in dashboard mode)
Task: 3318865
Part-of: odoo/odoo#138594
This commit introduces a new pivot function:
ODOO.PIVOT.TABLE(<pivot_id>, [row_count], [include_total], [include_column_headers])
Purpose
-------
It answers several current limitations:
- The pivot in spreadsheet not being "dynamic" (growing as new groups/records
are created) is a *very* frequent feedback
- sorted pivots are very cumbersome (# syntax) and takes a lot of cells
- cannot easily compute arbitrary aggregates (max, avg). You only get the
total. ... as soon as new groups appears that are not reflected in the
spreadsheet, you can't guess data is missing and that it's not taken into
account.
Specification
-------------
Add a single and simple function =ODOO.PIVOT.TABLE(<pivot_id>) that would
display the entire table (dynamic, as more groups and records are added).
We can achieve almost everything we want:
- by combining with other functions (INDEX, CHOOSECOLS, CHOOSEROWS, XLOOKUP,
...) if we want to target a specific row or column.
- by using infinite ranges (e.g. =MAX(B2:B)) to account for a growing table
- we could remove all the positional PIVOT version of the function
(=ODOO.PIVOT.HEADER(7,"#country_id",1)). The implementation is a mess
(lots of ifs everywhere to account for the #). Just replace it by a single
function SORT(ODOO.PIVOT.TABLE(1), 1) (or with NSORT, or sorted from the
pivot view directly)
For some situations though, there would be the "Totals" in the way:
if you want =MAX(ODOO.PIVOT.TABLE(1)), you don't want to have totals in the
way (with infinite ranges). We add an optional parameter 'include_total'
(default to true)
For dashboards, we want to have custom header names, we don't want to use
the headers from the pivot. To only have data and not the headers:
new parameter 'include_column_headers' (default to true)
All in all: here is what it looks like:
ODOO.PIVOT.TABLE(<pivot_id>, [row_count], [include_total], [include_column_headers])
Task: 3318865
Part-of: odoo/odoo#138594
Co-authored-by: Lucas Lefèvre <lul@odoo.com>
Everytime `getFirstPivotFunction` is used, the returned
args are evaluated.
This commit adds a getter which factorizes this behavior
that was repeated several times.
This getter is also more robust to EMPTY args AST.
Part-of: odoo/odoo#138594
The aim is to harmonize the analytic search view between `hr_timesheet` and `account` by creating an inheritance from `analytic`.
This allows the accountant to have access to all the fields and filters defined in other modules.
task-3463639
closesodoo/odoo#138542
Related: odoo/enterprise#48870
Related: odoo/upgrade#5271
Signed-off-by: William André (wan) <wan@odoo.com>
This reverts commit 4dcf11a71d.
The reason is that it broke the inheritance with `analytic`, and thus with `account`.
This in turn made it impossible to harmonize the search view between modules.
Part-of: odoo/odoo#138542
Problem
---------
The tax restriction after usage creates issues in the chart template
tests. Indeed, some of those test would re-create the repartition
lines that were created by default after the tax is used which is not
permitted anymore.
Objective
---------
Adapt the tests to not recreate repartition lines.
Solution
---------
Remove the Command create that would recreate the lines. Also, one test
made use of line tags which are not present by default anymore. This
test now manually sets the tag to teh line without re-creating it.
task-3450002
closesodoo/odoo#130403
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Problem
---------
All fields in the tax definition are currently modifiable even after the
tax has been used. This raises some issues in tax reports and make
investigations difficult when things go wrong in tax report.
Objective
---------
Once an account tax has been used:
- Some fields in the account tax should not be modifiable anymore to
avoid tax report issues;
- Other fields should be logged when modified to ease debugging and
investigations.
Solution
---------
1. Add a logger to the tax form to track the modification of some fields
2. Track whether the task is being used in transactions or not. This is
done thanks to a compute field. In order to be flexible, the compute
function uses a hook function that other modules can override to easily
add transactions to computation of the field.
3. Make the fields that should not be modified anymore readonly when the
tax is being used.
4. In order to track the repartition line values, a tracked computed
field that stores the relevant value in a string is used.
Task-3450002
Part-of: odoo/odoo#130403
Steps to reproduce:
- Create a MO that uses a component without quantity in stock
- Make an outgoing transfer that move some quantity of that component
out of stock and validate it
- Go back to the MO and open the Overview
Issue:
The status will display a '-x Ready', which doesn't make sense.
Now properly checks if there is quantity in stock.
closesodoo/odoo#114536
Related: odoo/enterprise#40930
Related: odoo/upgrade#5210
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
When more than available quantities are already consumed for a product,
a negative quantity will be displayed as `free to use` quantity, which
doesn't make much sense.
Part-of: odoo/odoo#114536
The point of the MO Overview is to be a single place where you can
quickly get all info for a single Manufacturing Order.
Since we have all data the cost_analysis is already fetching, we add
those data in the report when the production is done.
Also use the Stock Valuation Layers when available for component costs
to better reflect the real cost of production.
Task-3251506
Part-of: odoo/odoo#114536
Steps to reproduce:
- Enable subcontracting & multi-step routes
- Inventory -> Routes -> Unarchive MTO
- Create a subcontracted bom for a product S by vendor V
- Set V as supplier for product S and set route Buy & MTO
- Create a MO that uses S as a component and confirm it
- Go to the related RFQ and confirm it
- Go back to the MO and open the Overview
Issue:
The component S has its receipt marked as "Available", even though the
product isn't received yet.
When checking the previous moves in the chain, the move from
production -> subcontracting (end move of the subcontracted MO) will be
read and check its `reserved_availability`, which isn't right.
Task-3251506
Part-of: odoo/odoo#114536
Steps to reproduce:
- Enable a second currency (e.g. EUR)
- Create a product P with a supplier using EUR as currency
- Create a MO with this product P as component and confirm it
- Open the Overview
Issue:
In the MO Cost column, the cost will be displayed in the company
currency but without converting its value.
Task-3251506
Part-of: odoo/odoo#114536
If a component wasn't consumed at all during the manufacturing process,
we don't want to see it on the final Overview.
Task-3251506
Part-of: odoo/odoo#114536
When the Manufacturing order is done, a lot of data is not shown
anymore. This means we don't need to check each replenishment
resupply_rules if they're not being used anyway.
Part of task-3251506
Part-of: odoo/odoo#114536
Have the "MO Cost" column mean the expected costs following *this*
Manufacturing Order.
Rename "Product Cost" into "Real Cost" and have it represent what where
the actual registred costs for this MO.
This allows for a quick comparison against what was expected and what it
really cost.
Part of task-3251506
Part-of: odoo/odoo#114536
When displaying the MO Overview of a MTO product, "In Transit" lines
would be displayed for MTO components until the component was consumed.
Now checks whether the component is ready to be consumed (i.e. its
reservation is the MO itself, not a picking before) to know if it should
display the transit line or not.
Part of task-3251506
Part-of: odoo/odoo#114536
Steps to reproduce:
- Enable multi-warehouse
- Add different quantities for a component on two different warehouse
- Create a MO on each warehouse using that component
- Open Overview for each MO
Issue:
Both Overview display the sum of both warehouses quantities in "Free to
use / On Hand" column, which is incorrect.
By forcing the context to contain the warehouse_id, the quantities
fetched on the products will correspond to the quantities in each
warehouses.
Note: It's necessary to update the context of the fetched production as
most computation is done from this record, and its own context isn't
modified by the addition of `warehouse` to the context of `self`.
Task-3251506
Part-of: odoo/odoo#114536
As the content of the replenishments in the MO Overview is computed
through the forecast report data, as soon as a product is in stock,
the line about it disappears, since it is no longer linked to a
reception (PO/MO) in the forecast report.
But for MTO strong links, it makes sense to keep trace of what was used
to manufacture the products. So we inject the data back as if it was
regular forecast lines.
Part of task-3251506
Part-of: odoo/odoo#114536
Adds the `By-Products` section in the MO Overview as done in the BoM
Overview. This allows to correctly factor in the cost share of the
production's byproducts.
Part of task-3251506
Part-of: odoo/odoo#114536
Significantly improves the usability and the result of the populate for
base models and channel/member/message.
- make populate of base models re-entrant
- adapt size to values that make sense:
- small shows something relevant, and can be quickly ran several times
- medium is fast enough to be usuable but big enough to highlight
performance issues
- large is... still not to be attempted
- avoid conflicting conditions that either make no sense or can lead to
crashes when populating the data or running the database
- better spread of data in channel/member/messages
closesodoo/odoo#139269
X-original-commit: 73a5e322f6e250569ee1942d678f8a4f87616bd7
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This reverts commit b1427153f8.
It seems that salesman likes to change payment terms on SO after the confirmation.
task-3562396
closesodoo/odoo#139258
X-original-commit: f83afeffeb30496ad55f901a529144db47942787
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This commit is part of a serie of commits which aims at simplifying and
reorganizing js files in the web addon
closesodoo/odoo#139156
Task-id: 3508223
Related: odoo/enterprise#49212
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the domain term was using = or != as an operator
with an array as a right expression. This creates a warning in the log
when normalizing the leaf of the domain.
Now, the operations = or != are replaced by in or not in.
closesodoo/odoo#139032
Related: odoo/enterprise#49115
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Since the new milk theme, the clickbot for click everywhere, didn't set
the filters on the views.
Now, the clickbot set all the filters on the views. This commit also add
a test suit, to avoid future downgrades. This commit transform the
clickbot to a module ES6.
task-id 3535596
X-original-commit: e2f531ec47e4f946cc37afee6b65531a637b5dfe
Part-of: odoo/odoo#139032
This commit allows to share kiosk orders with all pos_configs. A new pos_session
boolean attribute is added to check if there is a kiosk config in the company.
In point_of_sale and pos_restaurant, if the company they belong to contains
a kiosk config, the ticket_screen will retrieve the kiosk draft orders.
closesodoo/odoo#138264
Related: odoo/enterprise#49294
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
This commit introduce the possibility for users
to set time off type allowing negative amounts in the
computation of remaining leaves on allocations.
This is for example useful in cases where the user wants
to take some leaves in advance with accruals not
having accrued the time off yet.
task-3465561
closesodoo/odoo#138118
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit implements a dialog for content generation using ChatGPT,
which can be opened via the Powerbox or via a button in the toolbar.
If text is selected, the dialog opens in "alternatives" mode. In this
mode, five alternative versions of the selected text are generated. The
user can choose one and it will be inserted in lieu of the selection.
Five buttons can be used to guide the AI to make the content longer,
shorter, more professional, more friendly, or more persuasive. Clicking
any of these buttons will restart the generation process with the new
parameters.
If no text is selected, the dialog opens in "prompt" mode. In this mode,
the dialog contains a textarea in which the user can input a prompt
which is then used to generate content. The user can then exchange with
the AI back and forth until the content is satisfactory. Any of the AI's
responses can be inserted into the document by clicking its "Insert"
button.
When content is inserted into the document, a green frame is shown
around it for two seconds, to make it clear to the user that something
has been inserted and where.
If an error occurs, it is inserted in the dialog like other responses
but in red and it can't be inserted into the document.
Please find the PR of the IAP part (Odoo Language Generator) here :
https://github.com/odoo/iap-apps/pull/703
task-3383324
closesodoo/odoo#137064
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Co-authored-by: Antoine Guenet (age) <age@odoo.com>
Co-authored-by: Lou (loha) <loha@odoo.com>
The PR https://github.com/odoo/odoo/pull/104741 have recently modify how the modifiers required, readonly,
invisible, and column_invisible are defined. They are now given by Python
expressions instead of domains. In this PR we introduce two main new
components ExpressionEditor and ExpressionEditorDialog that allow to
edit/view a Python expression in a way similar to what is done in the
DomainSelector/DomainSelectorDialog. For this we have extracted the main
logic found in DomainSelector and moved it to a new component TreeEditor
that is used by both ExpressionEditor and DomainSelector. For this we had
to add a new type of leaf we call "complex condition" that allows us to
represent indecomposable (sub)expressions, i.e. expressions we cannot
(or don't want) to express as conditions of the form (path, operator, value).
The main mappings allowing to transform trees, domains, expressions into
one another (when possible) are to be found in
@web/core/tree_editor/condition_tree.js.
closesodoo/odoo#136258
Related: odoo/enterprise#48512
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
Co-authored-by: Julien Carion <juca@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: Pierre Pulinckx <pipu@odoo.com>
Julien Alardot (jual)