Since the JS is lazy loaded, the iframes in the page are already loaded
once the javascript is executed. So, waiting for the "load" event at
that moment is useless as it will never happen as it already did.
Part of https://github.com/odoo/odoo/pull/32181
task-1961045
Use the system in website_sale where a case where this is needed could
be found. More cases can be found later during testing.
Part of https://github.com/odoo/odoo/pull/32181
task-1961045
* web, survey
This commit takes advantage of the other commits of this PR to enable
lazy loading for most frontend javascript:
1) Extract the minimum part of the assets common:
- promises library and polyfill
- boot.js
2) Create "assets_common_lazy" which is "assets_common" - "minimum"
3) Include the "minimum" assets in frontend layouts using "defer"
loading and "assets_common_lazy" using "lazy" loading
4) Create a script to do the actual lazy loading in a "minimum" frontend
assets
5) Lazy load the current frontend / website editor assets
Part of https://github.com/odoo/odoo/pull/32181
task-1961045
* payment, im_livechat
Inline scripts using `odoo.define` cannot work anymore as the boot.js
file loading will be deferred.
Most of features which used an inline script should probably be entirely
refactored. This commit focuses on removing the inline scripts
with a minimal diff (or at least tried to).
Note: for the website livechat, the inline script was kept as it seems
to be a longer refactoring to get rid of it (even though it is clearly
possible). The inline script was however adapted to make sure it works
with lazy loaded JS in the frontend.
Part of https://github.com/odoo/odoo/pull/32181
task-1961045
Thanks to this commit, when using the `t-call-assets` command, we can
use the "defer_load" attribute or the "lazy_load" attribute which will
respectively add the "defer" HTML attribute on the script tags and
replace the "src" attribute of the script tags with a "data-src" one.
In the lazy case, it is up to a custom page script to replace the
"data-src" attribute with the "src" attribute at the appropriate time.
This will be done in a future commit of this PR.
Part of https://github.com/odoo/odoo/pull/32181
task-1961045
This is a first step towards lazy loading the majority of the JS: the
boot JS code should not depend on any libraries (underscore.js and
jQuery).
Even without lazy loading in mind, this would be a nice-to-have.
Part of https://github.com/odoo/odoo/pull/32181
task-1961045
Before this commit, if an assets was named 'assets_hello_world' and
another one was named 'assets_hello' and that the first one was included
in the DOM before the second one, trying to load the first one would
result in a 404.
Indeed, this is what would have happened:
1) Render the `t-call-assets="assets_hello_world"` directive ->
compute the assets bundle then return a script with an url reaching
that bundle. Do this after having deleted the previous bundle
computation if any.
2) Render the `t-call-assets="assets_hello"` directive ->
compute the assets bundle then return a script with an url reaching
that bundle. Do this after having deleted the previous bundle
computation if any.
The problem is about "deleting the previous bundle computation" which
was done... by deleting all attachments starting by the bundle name.
This commit solves that by deleting the exact matches.
Part of https://github.com/odoo/odoo/pull/32181
task-1961045
This commit removes some groups that are now useless since their
only purpose was to allow the user to hide or show some fields
depending on its value, but those fields are optional now.
Task-1902765
closesodoo/odoo#31944
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit adds a new parameter on fields for list view and one2many.
The parameter name is "optional" and its values are "hide" or "show".
Columns of the list view which have the optional parameter set are
listed in a dropdown that can be toggled from the last cell of the
table header. The ones with optional set to "hide" are hidden by
default.
User choice is stored in local storage. If no saved parameter can be
found in local storage then the default value from the view is used.
Due to the overflow behavior of the responsive table, we were forced
to wrap the table-responsive div in yet another div. We changed the
o_list_view class on the table to o_list_table in order to reuse
the more generic o_list_view class on the top-most div. CSS rules
and selectors had to be updated according to this change.
Task-1902765
Since the company is not stored anymore on the user and is in the
environement, some parts of the code that was based on the current user
company cannot work anymore.
We've adapted the code to take the company from the relevent documents
to avoid having inconsistencies through the different documents
generated in the point of sale.
TASK-ID: 1997613
closesodoo/odoo#33556
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
* http_routing, portal, rating, survey, website, website_survey,
website_slides_survey
Before this commit, the final base layout of website was a fully
overridden layout of the one in portal, which was somehow a duplicated
one of the login one in web, which... so lots of duplicated code.
This commit is a first step towards a better organization:
1) The web app defines a frontend layout (to include base frontend
assets), with a base company logo as header.
2) The portal app modifies that layout in place to include the base
header, footer, ... It also uses a primary extension of it for
portal pages.
The survey app simply uses the above layout instead of defining its
own (by primary extension to include its own assets for its own
pages)
Same goes for the rating app and pages.
3) The website app modifies that layout in place to include the UI
assets, to add website UI, ... This allows to create frontend apps
which do not depend on website, with a non duplicated layout that
will be automatically adapted if website is ever installed (this
therefore allows to get rid of website_survey definitely)
This commit also fixes the session info system and the translation URL
on the frontend side to not require to redefine the whole session_info
for portal, website, ... Now the frontend session_info is defined in web
and http_routing extends it to add translation informations, then
website extends it again to add its own elements (not to redefine them
all as before). Note: before, http_routing defined the translation route
but only portal was adding it in its layout...
This is an adaptation of the work that was done with commit
https://github.com/odoo/odoo/commit/99821fdcf89aa66ac9561a972c6823135ebf65c0
Note 1: Many frontend but non-website apps (not only survey / rating)
could probably use this too but this would be the topic of another task.
Note 2: survey currently depends on http_routing but does not add itself
in the list of frontend apps to translate, it probably should.
Note 3: web_editor does currently not depend on http_routing but does
add itself in the list of frontend apps to translate, it thus uses a
function it does not really depend on... to check after its work-in-
progress refactoring.
task-1961045
closesodoo/odoo#33825
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
There is currently a stock location that is set on the pos config which
is by default the the default source of the picking type. This field is
not really usefull and we prefer that the configuration of the source
location where the POS will take products come from a dedicated
picking type that will have the correct default source location.
So we have removed the stock_location_id from the pos_config and changed
the related set on orders, by the location of the picking set on the
pos order, as it was not really consistent that if the pos_config was
changed the location of all existing orders was changed too.
TASK-ID: 1970513
closesodoo/odoo#32870
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
When you are selling goods through point of sale, pinkings are created
to remove what have been sold from the stock. This picking is created by
using the picking_type set on pos_config.
For now, the there is only one picking type POS Order existing by
default, which is located on the first warehouse in data. It means that
if you create another warehouse and/or company, you will have to
manually create picking type if you want to be able to link pos config
to the new warehouse.
So now, each warehouse will have its own picking_type for POS, which
will ease the link between the pos config and the warehouse.
We've also set a default value on pos config to take the first picking
type, and added a domain that will show only the outgoing types.
TASK-ID: 1970513
When you are looking at a point of sale session, the detail of what is
sales have been done during this session is stored in the POS Orders
linked to it. So we've added button on the session form that will show
all related sales done during this session.
TASK-ID: 1970513
The comparison of two datetimes is never exactly perfect. This commit adds
one second tolerance in the tests between two dates to ensure any false
positive result is avoided
closesodoo/odoo#33817
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
In order to be consistent with Lead Generation, we need to use Industry tags instead of technology tags.
In addition, we reduce the number of tags to keep only the relevant ones.
Task ID: 1941555
closesodoo/odoo#33434
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
The demo data inventory didn't call the right method (`action_start`
instead of `_action_start`), so, if user tried to re-install stock
module, the `ensure_once` check will fail when reinstall the demo data.
closesodoo/odoo#33811
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
1. hr_holidays: Clean manager form refs
Purpose:
Ease modification/addition of views and actions (in particular
when inheriting actions in hr_holidays_gantt)
Specification:
Use `form_view_ref` in the action context
instead of the form xml id in all views.
+ Add tree view from "Time Off / My Team"
2. hr_contract: Remove social secretariat field
Social secretariat is a Belgian concept. It does not make
sense to have this in the standard contract app.
Will be reintroduced in l10n_be_hr_payroll (or internal)
if really needed.
Move `job_id` in the right group to easily add fields
on the right with view inheritance.
3. hr_holidays: Display leaves in calendar
Purpose:
When a leave is created and approved, it can also create
a meeting in the calendar. In the leave type configuration
a particular meeting type can be chosen.
The purpose is to simplify this.
Specification:
Remove the choice of meeting type.
The choice should be:
Display Leaves in calendar: Yes/No (checkox)
4. hr: Direclty create user's employee
5. hr_holidays_gantt: Improve gantt views
6. hr_contract_salary: Make applicant's certificate required
Purpose:
Currently, on the salary configurator frontend, the certificate
is a radio button, with a default value selected.
Some applicants don't change the default value, even if it
is not their certificate.
Applicant should always explicitely set their certificate.
Specification:
Make the certificate a required field without a default value.
To reuse the existing validation logic of the salary JS, the input
is now a `select` instead of a `radio`.
7. hr_payroll: Sort payslips by date
Currently, payslips and payslip batches are sorted
by creation date, oldest first.
It's better to sort them according to their dates, more
recent firsts.
8. hr_holidays_gantt: Rename Leave into Time Off
9. hr_payroll: Adapt view inheritance social secretariat field
The field `reported_to_secretariat` of `hr.contract`
has been removed in Community: #4284
This commit adapts view inheritance after this change.
10. hr_payroll: Move schedule_pay from contract to structure
Schedule pay depends on the salary structure, not the contract.
e.g. for the same contract, the regular pay is every month,
but the 13th month is every year.
Hence the field is moved to `hr.payroll.structure` and made
a related field on `hr.contract`.
Note: the field schedule_pay is currently unused.
It could probably be removed completly remove on the contract.
11. hr_payroll: Add stat button on structure type
12. hr_payroll: Merge hr_payroll_gantt into hr_payroll
Since hr_payroll is now an enterprise module, an additional module
is no longer needed to add gantt views.
After this commit, `hr_payroll_gantt` module is deleted and everything
is moved to `hr_payroll`.
13. hr_payroll: Improve payroll menus
Employees
- Employees
-Contracts
Work Entries
- Work Entries
- Conficts
Payslips
- To Pay (show only draft payslips)
- All Payslips (newest first)
- Batches (newest first)
Reporting
- Payroll
- Meal Voucher (l10n_be_hr_payroll)
Configuration
- Settings
- Work Entries
* Work Entry Types
- Salary
* Structure Types
* Structures
* Rules
* Other Input Type (debug mode)
14. hr_payroll: Rename demo data
The renamed demo structure is the main
structure. It should have a general name
instead of a name linked to a particular
employee.
15. l10n_be_hr_payroll: Set default 38h calendar for BE
Set the default calendar of Belgian companies to 38 hours/week
TaskID: 1972536
closesodoo/odoo#33233
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
Ease modification/addition of views and actions (in particular
when inheriting actions in hr_holidays_gantt)
Specification
=============
Use `form_view_ref` in the action context
instead of the form xml id in all views.
+ Add tree view from "Time Off / My Team"
Social secretariat is a Belgian concept. It does not make
sense to have this in the standard contract app.
Will be reintroduced in l10n_be_hr_payroll (or internal)
if really needed.
Move `job_id` in the right group to easily add fields
on the right with view inheritance.
Purpose
=======
When a leave is created and approved, it can also create
a meeting in the calendar. In the leave type configuration
a particular meeting type can be chosen.
The purpose is to simplify this.
Specification
=============
Remove the choice of meeting type.
The choice should be:
Display Leaves in calendar: Yes/No (checkox)
Purpose
=======
1/ Robustness & security: right now it is not easy to understand and do something
clean in term of security (hr people vs employees, private info vs public). A
HR officer doesn't know if he can write something on the chatter. Currently, a
note will be visible for all the employees who have access to the employee form
view for example.
2/ In term of business, it makes sense to let a hr manages payroll stuff (contract,
employees private information, ... and other employee see public information
(résumé and work information)
Specification
=============
Introduce 2 new models:
- hr.employee.base (AbstractModel): This represents the basic skeleton
model on which the shared fields and methods between the public and
the private employees models.
- hr.employee.public (_auto=False): This is a sql view based on the
employee values, readable for an internal user (i.e. an employee).
The model hr.employee is not readable anymore for an employee.
There are now 3 ways to access the employee data:
1/ From the hr.employee views. HR officer access rights are required
2/ From the public profile. The public data for an employee are accessible
but can't be modified.
3/ From the 'My Profile' menu. A classic employee can access its own
data from there, and can modify them.
TaskID: 1961151
closesodoo/odoo#33725
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Modify purchase report in order to make it consistent with
sales report.
For the RFQ it will show the Order Date and for the Purchase order
menu it will display the Confirmation Date.
Also rewrite a bit the SQL view in order to compute every purchase
order in the company currency.
Technicaly rewrite the SQL alias in order to have a report more
readable in the future.
Task ID : 1857130.
closesodoo/odoo#28248
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Purpose
=======
1/ Robustness & security: right now it is not easy to understand and do something
clean in term of security (hr people vs employees, private info vs public). A
HR officer doesn't know if he can write something on the chatter. Currently, a
note will be visible for all the employees who have access to the employee form
view for example.
2/ In term of business, it makes sense to let a hr manages payroll stuff (contract,
employees private information, ... and other employee see public information
(résumé and work information)
Specification
=============
Introduce 2 new models:
- hr.employee.base (AbstractModel): This represents the basic skeleton
model on which the shared fields and methods between the public and
the private employees models.
- hr.employee.public (_auto=False): This is a sql view based on the
employee values, readable for an internal user (i.e. an employee).
The model hr.employee is not readable anymore for an employee.
There are now 3 ways to access the employee data:
1/ From the hr.employee views. HR officer access rights are required
2/ From the public profile. The public data for an employee are accessible
but can't be modified.
3/ From the 'My Profile' menu. A classic employee can access its own
data from there, and can modify them.
In List View, the Import button is placed after the Create button.
Before this commit, in a list editable in edit mode, the Create button
is hidden and the Save & Discard buttons are displayed.
But as the Create button was placed before the Save button, the Import
button will appear at the first position.
With this commit, the Create button is now placed after the Discard
button. In this way the Import button will be always the last button and
its position will not change when we switch between edit and read modes.
closesodoo/odoo#32613
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Before this commit, we had two form views for production lot: one more
complete and one simplier.
The complete one was displayed when we come from the prod lot list view,
and the simplier one in any other case.
But actually, we need to display the simplier one only with "Create and
Edit" and display the complete one in any other case, but it's
impossible to do with only two distinguish views.
So, we keep only one view with all elements and we display or hide some
fields or button in function of the context or if the record is new.
Task #1935921
Creation of a js_class: singleton_list.
It's used in the quant list view and its purpose is to avoid duplicate
line in list editable.
When user creates a new record, if the server responses with a ID
corresponding to a record already present in the view, it'll update the
old one instead of create a duplicate line.
Task #1935921
Change the use of Inventory Adjustment, notable changes are:
- Removed filter field: When user creates a new inventory
adjustment, he can set one or multiple locations and/or products.
An inventory adjustment will worry only about defined
locations/products, but if neither product or location was set,
it'll manage all stock.
- Inventory Adjustment Lines have their own view instead of be
listed on the Inventory Adjustment form view.
Inventory adjustment lines have new color legend:
- Red: The quantity is outdated.
- Blue: There is difference between the on hand quantity and the
counted quantity.
New inventory lines created by the user are written in bold.
- User can't modify already existing inventory lines, except for the
counted quantity.
- When an inventory line is outdated, the user has the possibility
to select and update it, that'll recompute the on hand quantity.
- When an inventory adjustment is validated, it will take in account
only the difference between the theoretical quantity ('On Hand
Quantity') and the counted quantity to adjust the quants.
- When an inventory adjustment is canceled, it will keep its
inventory lines and won't regenerate them when re-started.
- When an Inventory Adjustment generates Account Moves, user can now
find them in a stat button in the Inventory Adjustment form view.
Also, made some changes in demo data to match new requirement.
Task #1935921
Made some changes in stock.quant model to allow user to modify product
quantity easier.
To allow the edition of quant without opening more permissions on the
model, we switch to sudo in create mode and write if the conditions are
met (special key in context + access rights on the current user + write
on a specific field).
Also, we have two list views for the quant:
- The old list view who still readonly.
- A new list view where user can create new quant or edit quantity
of existing ones
We display the second one if user is a stock manager.
For existing quants, user can modify counted quantity (which will modify
product quantity). User can also create new quant, in this case:
- The quant is really a new one (ex.: new product/location
association) so will simply create a new quant.
- A corresponding quant already exist, so will modify the existing
quant instead of create a new one.
When an user creates a new quant, the model will check each time a
non-quantity field (product, location, SN/LN, package or owner) is
modified to see if corresponding quant exists. In this case, it'll get
the quant ID and will update reserved and on hand quantities.
If user didn't change the inventory quantity, it'll be updated too.
On product form view, the 'Update quantity' button was removed as user
can now simply modify quant with 'On Hand' stat button.
Task #1935921
Co-authored-by: sle-odoo <sle@odoo.com>
Purpose of this merge is to clean and improve performances of post and
notification mechanism contained in mail application.
In this merge we provide
* centralization of notification code inside mail.thread instead of being
dispatched in mail.thread, mail.message and res.partner;
* simplification of call chain, removal of unnecessary methods;
* better propagation of messages value through the various calls in order
to use given value and avoid browse and cache miss adding queries;
* optimization of attachments management in post;
* cleaning of message_post now limited to records and simplified in its
management of parameter;
* cleaning and simplification of recipients grouping for email notification;
* cleaning of message_notify;
* various code cleaning and tweaking in order to reduce query count;
Performance tests indicate number of queries did fall, especially in
use cases involving management of followers and attachments. See sub
commits for more details. This merge is linked to task ID 1943901.
closesodoo/odoo#32404
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Since ORM changes, the ids a many2many are new (virtual) ones in a
onchange, so we have to point to origin which are the real records to
check that the many2one is in as it has a real id.
closesodoo/odoo#33763
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
qsm-odoo