- data creation is faster when done through a CSV file than an XML file, hence doing it through a CSV
- also, created account_tax_template_data.xml file and moved account.account.tag and account.tax.template data in that file from l10n_syscohada_chart_data.xml file
was task# 1909961
closesodoo/odoo#28875
data creation is faster when done through a CSV file compared to an XML file. Hence doing it through a CSV
This commit is related to task_id : 1909961.
closesodoo/odoo#28871
We want to avoid that a `setTimeout` started in one test has an impact on other
tests. This is especially true with the status update loop. Since mail_service
is used in multiple tests, the safest solution is to patch timeouts everytime
we make a call to getMailServices.
There is no need for an unpatch, the patch become the default behaviour until
the page is refresh at the end of tests.
It is possible to manually add the patch after calling `getMailServices`
```
this.services = mailTestUtils.getMailServices(this);
this.timeoutMock = mailTestUtils.patchMailTimeouts();
```
This can be usefull if we want to get the timeoutMock to simulate time changes.
Task: 1856205
When on leave, the im_status can be either leave_online or leave_offline.
This will allow to display a specific icon and a default message when the user
is not at the office.
The leave can have an out of office message. This message will be displayed
in the chat window instead of the user ooo message, and the end date of the leave will be displayed too.
Technical details.
Right now the im_status access leaves directly to know if a user is on leave or not.
An index has been added to optimise this request (thanks to rco).
A solution to optimise this would be to compute part of the information in a cron.
Task: 1856205
When dropping a snippet into a page, it is dropped in the drop-zone
which is the nearest of the user cursor. When moving a snippet, that
condition did not apply and the user was required to put the cursor at
the exact location of the drop-zone.
Also, for both drag and drop features, the drop zones which appeared
were not displayed correctly for full width columns, which made dropping
sometimes impossible when multiple col-*-12 were below each other.
task-1937758
closesodoo/odoo#30899
If fleet.vehicle_state_active is not found in the system then the method
will raise an error, hence it won't allow creating any fleet.vehicle
closesodoo/odoo#30925
Task 1906794
Description of the issue/feature this PR addresses:
Current behavior before PR:
accounting settings are messy, with invoice & accounting settings mixed up
Desired behavior after PR is merged:
> restructure with Invoicing options first, then Accounting stuff
> move default sending options into "Customer Invoices" section, as first option
> new common section for vendor bill options
closesodoo/odoo#29170
When a scrap move is created, not with the scrap button but with a
scraped operation, the move stay visible in movelines, by opposition of
scrap moves created with the scrap button.
Also, when you create a scrap from a delivery order, it'll try to
prefill the location field with the location where the reserved product
is stored.
Task #1940511closesodoo/odoo#31500
See https://blog.getbootstrap.com/2019/02/11/bootstrap-4-3-0/
and https://blog.getbootstrap.com/2019/02/13/bootstrap-4-3-1-and-3-4-1/
Again, some fixes were added in this version and not in a 4.2.x version
so there is no clean way to backport them in 12.0 / saas-12.2.
If needed, the file bootstrap_review.scss is there for that.
Among the new features, two notable ones:
- The '.modal-dialog-scrollable' class which does what odoo already
implemented for all its modals. So we could remove our custom code in
a next update.
- Responsive font sizes ! Plan was to develop something similar for the
website, so this comes at the right time. The behavior is opt-in, we
will enable it in a next update.
task-1944790
closesodoo/odoo#31401
* web, im_livechat, survey, web_editor, website_forum, account,
auth_signup, payment, portal, project, sale, sale_management,
web_unsplash, website_mail, website_rating, website_sale,
website_blog, website_crm_partner_assign, website_event_track,
website_links, website_slides, website_mail_channel,
website_mass_mailing, website_sale_comparison, website_sale_delivery,
website_sale_wishlist, website_event, website_form,
website_sale_stock, website_twitter
When website is installed, the JavaScript code has access to utilities
to define improved widgets which are automatically attached to existing
DOM elements on page load. Those mechanics are more and more needed in
portal which does not depend on website (as it is website which depends
on portal). This moves part of website JS to web, so that it can be used by all
'frontend' apps whose only common dependency is web (portal, survey, ...).
See sub-commits for details.
task-1932066
closesodoo/odoo#29442
Bootstrap 4.3.1 introduced tooltip sanitization. Odoo should normally
use tooltips for secure content anyway, so this commit disables this
sanitization. A proper analyse of our tooltip should however be done
to know if sanitizing is needed (it can also be enabled case by case).
See https://blog.getbootstrap.com/2019/02/11/bootstrap-4-3-0/
and https://blog.getbootstrap.com/2019/02/13/bootstrap-4-3-1-and-3-4-1/
Again, some fixes were added in this version and not in a 4.2.x version
so there is no clean way to backport them in 12.0 / saas-12.2.
If needed, the file bootstrap_review.scss is there for that.
Among the new features, two notable ones:
- The '.modal-dialog-scrollable' class which does what odoo already
implemented for all its modals. So we could remove our custom code in
a next update.
- Responsive font sizes ! Plan was to develop something similar for the
website, so this comes at the right time. The behavior is opt-in, we
will enable it in a next update.
Part of https://github.com/odoo/odoo/pull/31401
task-1944790
* portal, sale, website, website_blog, website_crm, website_event,
website_event_sale, website_forum, website_hr_recruitment,
website_sale, website_sale_wishlist
At last, that ugly JS module can be removed. Before this current PR, it
was still used to wait for "page ready", to initialize widgets on page
loading. Now, all can be done thanks to public root and public widgets.
web_editor.base was also still used in tours, which should not be
necessary anymore for the same reason, especially since the tour manager
waits for the public root naturally.
Part of https://github.com/odoo/odoo/pull/29442
task-1932066
* web, website_blog, website_sale, website_twitter
Before this PR, all website widgets were named 'Animation'. Now that
they are 'Public Widgets', we can at last stop using the confusing
'animation' name.
Part of https://github.com/odoo/odoo/pull/29442
task-1932066
* website_blog, website_crm_partner_assign, website_event,
website_event_track, website_form, website_forum, website_links,
website_mail, website_mail_channel, website_mass_mailing,
website_sale, website_sale_comparison, website_sale_delivery,
website_sale_stock, website_sale_wishlist, website_slides,
website_twitter
While using the 'Animation' class of website instead of the frontend
'Widget' class leads to the same behaviors, this refactoring is done for
two reasons:
- Stop using the confusing 'Animation' name for non-animated behaviors
- Instantiation of 'Widget' is slightly faster than 'Animation'
Part of https://github.com/odoo/odoo/pull/29442
task-1932066
* portal, sale, web, website_blog, website_crm_partner_assign,
website_forum, website_event_track, website_links, website_mail,
website_slides, website_mail_channel, website_mass_mailing,
website_sale, website_sale_comparison, website_sale_delivery,
website_sale_wishlist
The `editableMode` option and its related options in public widget
should only be part of website, this commit moves them there. This is
also the occasion to implement something that is long overdue: stop
creating 'animations' / public widgets in edit mode by default. Indeed,
lots of 'animations' were defined by beginning with 'if not edit mode'.
Now, if a public widget should be considered in edit mode, it must be
defined explicitely through a property at *definition* of the widget.
Part of https://github.com/odoo/odoo/pull/29442
task-1932066
* account, auth_signup, payment, portal, project, sale, sale_management,
web_unsplash, website, website_mail, website_rating, website_sale
This commit does probably not do what is stated for all non-website apps
but it is a first step. It also uses the system in apps which could have
already used it but did not.
Part of https://github.com/odoo/odoo/pull/29442
task-1932066
* im_livechat, survey, website_forum
When website is installed, the JavaScript code has access to utilities
to define improved widgets which are automatically attached to existing
DOM elements on page load. Those mechanics are more and more needed in
portal which does not depend on website (as it is website which depends
on portal). This commit moves part of website JS to web, so that it can
be used by all 'frontend' apps whose only common dependency is web
(portal, survey, auth_signup, ...).
This PR also questioned several other similar issues which will be
handled later like:
- website should maybe not depends on portal but only on http_routing
- part of portal should be moved to http_routing and http_routing
should be renamed (especially for frontend layouts, etc) so that apps
like survey can reuse some common code
Part of https://github.com/odoo/odoo/pull/29442
task-1932066
In preparation to future commits, the WebsiteRoot instantiation is moved
in an other file than its definition.
Part of https://github.com/odoo/odoo/pull/29442
task-1932066
User might be confused by the help: they think the vendor cannot sell
the product below this quantity, which is not what the field depicts.
Improve the label and the help of the `min_qty` field to avoid
confusion.
opw-1943511
closesodoo/odoo#31414
When users create an automated action to trigger when a record is updated,
they assume each update is 'atomic' in some sense.
It is not the case, as one write may trigger many write, some in recompute.
As a result, any update may trigger a dozen actions (or more).
We add a field wich allows us to specify which field we want to watch.
For instance, you could select the field 'state on quotation',
and thus only action would be triggered on confirming the quotation.
The link_field_id is a field that allows to link a record of the source model
to a new record of the target model, through a many2one.
However many target records can be created, so every one of them
(except the last) ends up orphan.
We allow for one2many and many2many fields to be used,
and in these cases we add the newly created record to the list.
opw 1910671
Hetashree Chauhan