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
This commit ameliorates the tooltips and the legend
of the graph view in its different modes (bar, line, and pie).
Related task id: 1917940
Co-authored-by: Mohammed Shekha <msh@openerp.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
closesodoo/odoo#29747
PutAwayStrategy model was deleted and FixedPutAwayStrategy model was
renamed into PutAwayRule.
Now, each location can contain multiple putaway rules, each rule
applying either on product or on product category.
The purpose is to:
- Add more visibility on putaway settings (with a stat
button on product, product category and location views, and a
submenu item in Product configuration menu).
- Change putaway model to avoid redundancy.
Task #1935169closesodoo/odoo#30889
Before this commit, when UoM was displayed, it wasn't specify if cost
referred to 'Unit of Measure' or 'Purchase Unit of Measure'.
To avoid ambiguity, it's now specified.
This apply when 'Units of Measure' is ticked in settings.
Task #1937177closesodoo/odoo#31070
Let the database be in multi-company with unshared contact catalog.
Let F be a filter "('partner_id', 'not ilike', 'string')" on invoices.
If there is a contact which parent belongs to another company,
then this parent cannot be read.
Thus the name_get on partner can create an access error.
As a result applying the filter F would fail and return no results.
It generally doesn't make much sense to have a contact company X, which belongs
to the Odoo Company OC1, while its child contacts are in another Odoo company,
since many fields are directly computed from the parent.
However it is useful to have X belongs to no company, while it has child
contacts X>Yi belonging to company OCi.
In the first case it can create access errors interrupting the normal flow of
operations, while the latter should not.
To forbid the first case while allowing the second, we synchronize company_id,
but add a special case to ignore it if it set to False.
Note that PR#30997 should be used in case the name_get causes an error for
another reason that is deemed a legitimate use-case.
opw 1933862
closesodoo/odoo#31364
In small devices, onboarding bars are displayed vertial, which
takes too much screen space, and user has to scroll down
a lot to view actual content.
This commit improves the behavior by showing onboarding bars
horizontally (with scrolling) in small devices also, and thus
occupying minimal screen space.
task: 1929048
closesodoo/odoo#30823
Payment providers can be used without eCommerce. Therefore, we should be
able to access the payment transactions with only `sale` installed.
opw-1941591
closesodoo/odoo#31270
Before this commit: select more than two groupbys
in a graph view would have no impact at all if mode
'bar' or 'line' is selected.
This commit allows to correctly handle more than
two groupbys in all modes.
Task ID: 1917948
closesodoo/odoo#29673
Backport of d9fed5381a78c19ce14ddc8b9233f60d53c65453
Before this commit, when opening the calendar view with a specific locale
in the "week" view
the days were translated but the date format was wrong and fell back to english
This was because the translated terms were passed explicitly, but the locale did not
get passed
After this commit, we do what it takes to pass the locale to fullcalendar
and the dates are formatted with the right pattern
Also, there may be a bug in fullcalendar, because just passing the locale in the options
won't work, it should be instanciated first in fullcalendar's "locales cache"
OPW 1922092
OPW 1934127
closesodoo/odoo#30909
The onchange on serial number aims to track any duplicates. The issue
comes from the fact that `.mapped()` removes the duplicates when it
returns a recordset. We use a list comprehension instead.
Opw : 1910963
closesodoo/odoo#30913
Usecase to reproduce:
- Create a route with a warehouse_ids
- Uncheck warehouse_selectable on route
- Create a picking that use the route
It should fail since the route is not applicable.
It happens because _search_rule only check for route with warehouse_ids
but it do not check for warehouse_selectable. We can't fix _search_rule
since stock_warehouse.py creates multi step delivery and reception
routes without warehouse_selectable thus it would break existing configuration.
Instead create an onchange on warehouse_selectable that remove
warehouse_ids on route.
partial backport of commit a35df8d371closesodoo/odoo#30844
This commit is a refactoring of im_status management.
This commit also add im_status in two places, near the author in a mail thread and on each suggestion when using mentions.
A service to manage im_status will have multiple benefits here:
-centralise information, avoid to call the server multiple time for the same im_status
-update all im_status at once and keep consistency in display.
With this commit, the im_status updates are now done by rpc call.
Updates where previously made with the bus but this has some drawback,
since the bus will only give the information 50 seconds after the beginning of
the request, in the worst case, we van wait 2*50 seconds to get an update.
More than that, the im_status where only updates for pinned dm_chat. Dm chat
are synchronized cross tabs, making the use of the bus possible for this purpose.
Since we will need to display im_status not linked to dm_chat, the list to update
will be different from tab to tab making the use of bus difficult for this purpose.
Technical notes:
-im_search has been moved from bus to mail addons since it concerns mail.channel
-Update of an im_status should be reflected everywhere in the page.
Since im_status is a rendered template used in multiple widget, we should add
the correct logic to all concerened widget. The current solution is simple:
use a jquery selector to find every place where im_status is rendered.
-we add a new im_status: im_partner. This will indicate that that
the partner has no user linked to him, making it possible to avoid to ask
for status updates for this partner.
-The update will only be done when the tab is focused. (and will be done
asap once the tab get focus back)
In the e-comerce, when the user try to add a new card in this payment
methods.
Before this commit, to validate the card, besides of the creation of the
payment token, an amount of $1.5 id charged and refunded.
During the refunded an error was raised. This error arrives because:
payments made via Authorize.net are settled and allowed to be refunded
only on the next day.
https://account.authorize.net/help/Miscellaneous/FAQ/Frequently_Asked_Questions.htm#Refund
<quote>The original transaction that you wish to refund must have a status of Settled Successfully.
You cannot issue refunds against unsettled, voided, declined or errored transactions.</quote>
This means, we can't refund directly after the payment.
Now, we only create the payment token. As Authorize.net verify the card
during the creation of the token, a new verification is not needed.
OPW-1927754
closesodoo/odoo#30905
Before this commit, when creating a partner automatically when creating
a message with a template, the company on the partner was wrongly set
After this commit, we try to retrieve the company from the model on the template
OPW 1934392
closesodoo/odoo#30893
Make a return on a pos_order. A new pos_order is created.
On the latter, remove a pos_orde_line.
Before this commit, there was a traceback, due to a KeyError
It was introduced by 5f6a491265
which intended to optimize migration process
We keep the logic of that commit here, in a new helper method
while restoring the original onchange,
since it wasn't compliant with onchange specs
OPW 1934129
closesodoo/odoo#30897
Laurent Smet