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#28898
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#28897
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#28896
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#28894
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#28893
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#28892
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#28890
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#28889
purpose of this task:
Create all account.account.template from csv file.
after this commit:
all account.account.template of country 'Belgium' will be created from csv file, instead of xml.
This commit is related to task_id : 1909961.
closesodoo/odoo#28879
- 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).