*: website_blog, website_event, website_forum, website_livechat,
website_sale, website_sale_slides, website_slides,
website_slides_forum
The goal of this commit is to add dialogs to create new website content
using a 'target:new' action on the form view and an overridable
"website" form controller.
See merge commit for more information.
task-2687506
*: website_event, website_forum, website_slides
As the first commit of the merge of this work at [1], this moves files
without modifying them to preserve code history and ease forward-ports.
This part is about moving static XML to non-static files where the
XML will be changed into view definitions (as some UI now become normal
backend views). This cannot be a standalone working move of course.
So it was not done in the first commit but here, just before the
relevant commits of the merge.
[1]: https://github.com/odoo/odoo/pull/89223
See merge commit for more information.
task-2687506
*: website_blog, website_customer, website_event_exhibitor,
website_event_track, website_hr_recruitment, website_sale,
website_slides
See merge commit for more information.
task-2687506
After OWL next was merged, an error popped up while patching the Navbar
currentAppSections getter, coming from the Enterprise NavBar render.
A setter was added on the Navbar component to allow for the patch.
See merge commit for more information.
task-2687506
This commit also suggests a way to conditionnaly display menus. Here the
website edit menu should only be visible when the website is displayed.
There may be a better way to filter out some menus. That feature will
be reviewed anyway as part of a `patch` the framework team would like to
avoid.
See merge commit for more information.
task-2687506
This commit adds a generic Dialog component, for the website.
It has a default footer with two buttons.
See merge commit for more information.
task-2687506
*: website_blog, website_event, website_forum, website_hr_recruitment,
website_livechat, website_sale, website_slides
The NewContentModal component is added. It displays tiles, which will
install a module if not already installed, or perform an action defined
by the module otherwise. So that modules can patch that component to
define an action when installed (for example, website_sale will handle
the logic of creating a new product), the elements to displayed and
their state (NOT_INSTALLED, INSTALLING, INSTALLED) are listed in the
state of the component.
A key 'isDisplayed' is added on the new content elements that should not
be displayed to the user, depended on his security groups.
By default, the new content elements are displayed to the system user.
See merge commit for more information.
task-2687506
After OWL next was merged, an error popped up while patching the Navbar
systrayItems getter, coming from the Enterprise NavBar render. A setter
was added on the NavBar component to allow the patch.
task-2687506
This commit adds a new website_systray registry, that the patched navbar
will use when the user is editing the website through the WebsitePreview
client action.
This patch is subject to debate with the framework team, it will be
discussed further post-merge.
See merge commit for more information.
task-2687506
Co-authored-by: Arthur Detroux <ard@odoo.com>
This commit adds an underlying iframe, below the main one used to
display the website.
This iframe, used as a fallback inbetween the events 'beforeunload' and
'load' of the main iframe, will host its replicated content to avoid
seeing white flashes.
These white flashes can happen on Chrome Linux and Windows - even on a
regular navigation - but are even more visible in the context of an
iframe.
See merge commit for more information.
task-2687506
*: auth_signup, portal, web, website_knowledge
When navigating in the iframe, only same origin redirections should be
open in the iframe contentWindow. External redirections should be done
in the top window.
Some internal pages had to be served with X-Frame-Options header set to
SAMEORIGIN, and Content-Security-Policy to "frame-ancestors 'self'" (see
[1]).
All the links that are redirecting to another host, and the client
actions, are opened in the top window.
Exemples that will be opened in the iframe's top window:
- Clicking on a link google.be that should not open in a new tab
- Clicking on the language selector and adding a new one, or
clicking on "logout".
[1]: https://github.com/odoo/odoo/pull/78298#discussion_r898853383
See merge commit for more information.
task-2687506
Co-authored-by: Arthur Detroux <ard@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
*: portal
The user dropdown (containing link to /my and a link to logout) now also
contains two other links (provided the user has the access rights):
- Link to the backend (app switcher for enterprise)
- Link to the website client action to configure the current page
See merge commit for more information.
task-2687506
The browser's url is replaced when navigating inside the website from
the client action's iframe.
Exemple:
"/web#action=website.website_preview&path=/shop" becomes "/shop".
See merge commit for more information.
task-2687506
This commit adds a new client action, that will display the frontend
website in an iframe, inside the backend.
Besides that iframe will be instantiated the edition components (the
snippets menu, or the translate menu).
This allows for a better integration with the other odoo apps, an easier
mobile edition. It also avoid reloading the edition components when
navigating inside the website.
See merge commit for more information.
task-2687506
*: web_editor, web_unsplash, website_event, website_blog,
website_event_meet, website_forum, website_links, website_livechat,
website_sale_slides, website_slides
With [1], many files will move as the website UI is moved in the
backend. This commit moves all the static files (JS/CSS/XML) to their
final destination without modifying them, in an attempt to preserve
some history and ease some forward-ports.
After this commit, everything works as before as the files are simply
renamed and the references to them adapted.
However, technically, many files will actually be split into multiple
files by the work made with [1]. While it is theoretically possible to
preserve history over multiples files, this would require inner merge
commits, which does not go well with robodoo. In those cases, the "main"
file of the split was chosen. Mainly, 4 worth-noticing splits were
detected (and so the history moved only to the first file):
move: addons/web_editor/static/src/js/wysiwyg/widgets/media.js
to: addons/web_editor/static/src/components/media_dialog/file_selector.js
- addons/web_editor/static/src/components/media_dialog/search_media.js
- addons/web_editor/static/src/components/media_dialog/image_selector.js
- addons/web_editor/static/src/components/media_dialog/document_selector.js
- addons/web_editor/static/src/components/media_dialog/icon_selector.js
- addons/web_editor/static/src/components/media_dialog/video_selector.js
move: addons/web_editor/static/src/js/wysiwyg/widgets/upload_progress_toast.js
to: addons/web_editor/static/src/components/upload_progress_toast/upload_progress_toast.js
- addons/web_editor/static/src/components/upload_progress_toast/upload_service.js
move: addons/website/static/src/js/menu/content.js
to: addons/website/static/src/components/dialog/edit_menu.js
- addons/website/static/src/components/dialog/page_properties.js
- addons/website/static/src/components/wysiwyg_adapter/page_options.js
- addons/website/static/src/js/website_page_list.js
move: addons/website/static/src/js/menu/edit.js
to: addons/website/static/src/components/wysiwyg_adapter/wysiwyg_adapter.js
- addons/website/static/src/systray_items/edit_website.js
- addons/website/static/src/components/editor/editor.js
Notice that as those moves were made post-work and the rest of the work
(80+ commits) rebased on top of it, some commits may remove more than
they should in a moved file to then reimplement some of what was
removed in a later commit... ideally this should have been avoided of
course but keep in mind that the final files are just entirely rewritten
and split as converted to OWL. It seemed however worth it to keep most
of the inner history of the work made here to see step by step what was
done. [1] will obviously be merged with a merge commit, binding the
whole work together.
[1]: https://github.com/odoo/odoo/pull/89223
task-2687506
The string concatenation would fail on False help_message.
Closes#93036closesodoo/odoo#94505
X-original-commit: 97e066b4cfda8ac34208f84753a40c10524ae989
Signed-off-by: Kevin Baptiste <kba@odoo.com>
The s_countdown snippet had 2 templates defined inside one file
(000.xml):
- One for showing a redirect message which is rendered in the
public widget flow.
- Another for showing an end message which is rendered and
appended to the snippet in the option flow.
The templates were loaded by the public widget, which means that even
if no end message was shown, the template would be downloaded for a
visitor.
This commit fixes that by splitting the file in 2, one for the options
and one for the public widget, ensuring that the option will load what
it needs.
(This is necessary for the task mentioned below, which moves the edition
to the backend, preventing the option from relying on a public widget
template.)
task-2687506
closesodoo/odoo#94118
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
* verify settings access for "Settings" user (`base.group_system`)
* Improve loading performance through the use of conditional groups inheritance
* Do not imply application administration groups for "Settings" users
* Fix wrong view inheritance (views hooked on content defined in siblings, not in parent(s))
Enterprise PR: https://github.com/odoo/enterprise/pull/27595
Task - 2858427
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#91909
Related: odoo/enterprise#27595
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Now that the settings user implies having internal user rights
(base.group_user), the access rules for users are applied and the test
test_system_user_should_be_able_to_reset_any_tokens failed.
This commit adds a generic ir rule giving all rights on gg calendar
credentials to "Settings" users, aka base.group_system group.
Part-of: odoo/odoo#91909
The field pos_employee_ids (pos_hr) links hr employees records to
settings records
but this model isn't readable for Pos Administrators by default.
This commit gives read rights on hr.employee model to settings users,
reusing a confusing existing ACL whose name targeted system users,
whereas the group effectively targeted was the internal users.
Since this rule didn't give any rights, we might as well correctly
replace
it so that the name can match its purpose.
Part-of: odoo/odoo#91909
Settings user is not able to access Bill of Material (mrp.bom) records
unless they have additional groups (account, inventory, manufacturing, ...)
This commit makes sure the operation is done in sudo so that any setting user
is able to save the settings.
Part-of: odoo/odoo#91909
Now that settings views are only loaded for the ones able to see their content,
the field group_cash_rounding might not be present if a pos manager without
account manager rights opens the settings.
Part-of: odoo/odoo#91909
Since #87636, delivery carrier model is referenced in the settings when
website_sale_picking is installed.
Because of that, users with only settings access are not able to
open the settings anymore.
This commit adds read rights on delivery carriers so that base settings
users are able to update settings.
Part-of: odoo/odoo#91909
It seems most accounting tests relied on the fact that the "accountman"
test user has both the user AND manager groups (but previously, the
manager group was given by the implied group relation "Settings" ->
"account manager")
Part-of: odoo/odoo#91909
For bugfix purposes, app administration groups have been given to
(implied by) the "Settings" group because without those rights,
opening/saving the settings crashed.
1) Do not load hidden view content
This commit uses the conditional inheritance of views
(depending on user groups) to avoid loading unnecessary view
& record content client-side.
This improves performance for admins without the specific application
admin rights, but also fixes the main bugfix problem,
caused by the webclient querying name_get for the records in relational
fields content.
Example:
sale_management adds a res.config.settings field to specify
the default sale.order.template for the current company.
If a 'Settings' user without 'sale.group_sale_manager' opens the
settings, he won't see this setting, but if a default template is
specified for the current company, the webclient will still request
the name_get of this template to the server, because the field
was present in the view, only hidden with a groups attribute.
With this commit change in sale, the field won't be in the view unless
you have the Sale manager group, avoiding the error/traceback/bug.
2) Remove implied application administration groups
Do not force the specific application groups on all 'Settings' user,
they globally do not need those rights, and if they need it, they
can add it to their account themselves.
3) Add a test to make sure settings user are able to manage settings.
4) Enforce 'settings' -> 'access rights' -> 'internal user' groups
As the previous test highlighted some 'false positives' because
it considered a settings user unable to read `crm.team`
and `stock.warehouse` records, we also took the opportunity to enforce
the fact that 'Settings' & 'Access rights' users must be internal users.
It makes no sense for a portal/public user to have access to the
settings, and didn't work anyway.
Part-of: odoo/odoo#91909
the div with id auth_signup_documents is specified in the view
`sale.res_config_settings_view_form`, which is not a parent of
`website.res_config_settings_view_form`.
This led to an error during view rendering because of the changes in
the following commit, where the sale settings view is modified to be
only loaded for sale managers.
Part-of: odoo/odoo#91909
Minor usability changes:
* Reorganize menu to be more consistent with other HR apps;
* Tweak several views;
* Don't expire contract when date is set to Today - they will be
automatically expired the next day;
* Show contract name on form view.
closesodoo/odoo#92604
Related: odoo/enterprise#27919
Taskid: 2856135
Signed-off-by: Kevin Baptiste <kba@odoo.com>
add the compare_list_price to /shop, if there is a compare_list_price and a
price_list price for a product, the fixed_price will be displayed
task-2813257
closesodoo/odoo#90195
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Rework and code cleanup of automatic invoice and auto-confirm order
flows.
task-2541188
closesodoo/odoo#72368
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Method: _find_mail_template()
Before this change, the method returned only the id of the template.
Now, it will return the template, as the method name suggests. Also, it
will simplify the method by avoiding complicated research into XML.
Code imported from #68965 that contained a new feature that was at last
abandoned.
Task-id: 2541188
Part-of: odoo/odoo#72368
Co-authored-by: Demesmaeker <edm@odoo.com>
Updating the scheduled date of a delivery doesn't update the quantity to
order of an orderpoint
To reproduce the issue:
(Need purchase)
1. Create a storable product P with a seller
2. Create and confirm a planned delivery D with 1 x P
3. Open the replenishment page
- There should be a line for P (Forecast: -1, To Order: 1)
4. Edit D and postpone the scheduled date
5. Go back to replenishment page
Error: The line is still present, its forecast qty is correct (0) but
the quantity to order is still 1 (instead of 0)
`qty_to_order` is a stored field, so when loading the replenishment
page, its compute method is not called. Moreover, even though
`qty_to_order` depends on `qty_forecast` and the compute method of
`qty_forecast` is called, it still won't trigger the compute:
when setting the value of `qty_forecast` from its compute method, it
will lead to:
https://github.com/odoo/odoo/blob/b54f78de307543efcea934206806f361eaac811a/odoo/fields.py#L1106-L1109
So, as shown and explained, we bypass the `write` of `BaseModel` and
skip the business logic and the recomputations
The compute of `qty_to_order` should actually be triggered earlier: when
we edit the scheduled date (step 4). That's the reason why this commit
adds a dependency to the compute of `qty_forecast`: it makes more sense
and becomes an implicit dependency of `qty_to_order` -> update the
scheduled date will trigger the compute of `qty_to_order`
OPW-2868167
closesodoo/odoo#94400
X-original-commit: 791b68fc02cbc4dc5b376e5fc5d37e725f88d0dc
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Follow-up of https://github.com/odoo/odoo/commit/0c30945d364a8b986f0b48db28e42c7b355471e3
Commit above changed the message formatter in python,
so that `attachment_ids` now always return a list of field commands.
This work fine in backend code of discuss, but in public livechat,
it still uses legacy code. The legacy code do not support field
commands, so instead it thinks the command is data of an attachment,
thus showing an "unamed" attachment.
Actually attachments are not supported in livechat. Code had some
handling of attachments just because this was shared with the
backend in the past.
This commit fixes the issues by simply enforcing showing no
attachment in any message in public livechat.
closesodoo/odoo#94394
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
This commit has as purpose to split the method `_is_add_to_cart_possible`
and put only the first part in another method so it can be overridden.
Issue:
The first part of the method _is_add_to_cart_possible check that the
product is active and can be sold.
The second part check if a combination is possible.
In sale_renting module, only the first part must be overridden since
second part is a common check to all product regardless if it
can or can't be sold or rent
opw-2879711
closesodoo/odoo#94373
X-original-commit: 99dc5a963002e887d5c4a9ad403e171b627d2e8a
Related: odoo/enterprise#28777
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
1. Activate anglo saxon accounting
2. Create product with automated inventory valuation and standard pricing
3. Set decimal accuracy to 6
4. Set product cost price to 0,01719
5. Create PO for 30.000 items -> price = 0,01782 -> total = 534,6
6. Receive goods -> stock journal entry = 515,7 (based on the cost, ok)
7. Create vendor bill
Price difference is incorrect if you have a tax rate in the vendor bill
`price_unit_val_dif` will be rounded to 0.02
Multiplied by a great quantity the result will be wrong (84.30)
Without using the tax rate the price difference amount is the expected one
This commit partially revert 643d91ef5ebfb29fde142294ced82c470d42c136
to improve the original fix.
opw-2849074
closesodoo/odoo#94346
X-original-commit: 315a18f12f9d67284bbd8b027ca652db17aae9d2
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
xO-Tx