Since subscriptions only accept tokenizable (credit-cards and such)
payment options, we must use the token_implemented field to filter out
non-tokenizable payment options (such as wire transfer) and because
token_implemented is a computed field, a search function had to be
created
`parent_id` fields are common in many models, and thus default values
for those fields are sometimes passed in the context.
Because mail.message also has `parent_id` field, it would automatically
use the default when an automatic message was being posted. While of
course, the parent_id value comes from a different model.
This "adoption" by a random "parent message" is unexpected,
not desired, and it can even cause a very surprising AccessError if the
parent message is not readable by the user.
Forcing the `parent_id` value during the creation of an automatic message
avoids this confusion.
One way to trigger the bug was to use the "subtask" stat button to create a
child subtask for a project task (it relies on the parent task ID
passed in the context)
PURPOSE
=======
As a "user"
I want to "know which fields I'm supposed to fill in to have a workable configuration"
In order to "avoid getting error messages later"
SPECIFICATION
=============
When I select "Perpetual" in Inventory Valuation on the product category, it should be great to put Stock input,output,valuation accounts fields required.
PURPOSE
=======
Add the possibility to filter on analytic accounting in the invoices report
SPECIFICATION
=============
Accounting > Reporting > Invoices (Business Intelligence)
- Add filter / group by analytic account
- If possible, filter/group by visible only if "Analytic Account" group enabled in configuration
PURPOSE
=======
Simplify the way to activate currencies
SPECIFICATION
=============
On res.company :
Currency_id: options={‘no_open’: True}
oe_edit_only on “Activate more currencies”
In the list view of the currencies, replace the checkbox active by a boolean_toogle widger
There is normally a default filter on the currencies list view to only show the active currencies : this filter should be kept except if you arrive on this screen by clicking on "Activate more currencies" from the res.company and from the settings. Only the menuitem Currencies should only show the active ones
Purpose
=======
Currently, it's not possible to activate a boolean on a non-editable list view without adding 2 buttons linked to a python method. These buttons aren't aligned and the result is not pretty.
This commit adds a new widget that allows to toggle a boolean record by record by clicking on the slider.
Purpose
=======
No way to fully set up a bank account from current form
Must go to journal form to simply apply bank sync, etc. Users cannot figure this out themselves, this is too much complicated
Also the meaning of Manual, Electronic, etc is not clear. What does it do? Field and options to rename or to explain very clearly in tooltip
Specification
=============
- Add some useful fields on the bank accounts form view to configure it completely
- Add tooltips on some selection fields to explain the meaning of each selection
- Reorganize fields in groups to be more structured
- Improve the field display for account journals that are used in pos
There is a bit of magic in the kanban with many2many: the widget many2many_tags
is automatically set on many2many fields.
Since the previous commit, the `color_field` needs to be explicitly stated
in the options for the tags to be colored.
In kanban views where tags were previously colored, we thus have specified the
widget and the color option.
Since the previous commit, the `color_field` needs to be explicitly stated
in the options for the tags to be colored.
The previous behaviour (always read the field `color`) was leading to server
warnings if the field was not present on the comodel.
Thìs commit set the `color_field´ for every many2many_tags on fields that have
a `color` field on the comodel.
Before this fix, the field 'color' was hardcoded in the m2m_tags widget,
which means that:
- one couldn't specify another field (problem for custom models, with x_...)
- if the related model didn't have the field 'color', a warning was raised
by the server
Now, the color attribute needs to be specified on the widget options if one
wants to display colored tags.
If the color is not specified, the tags will be displayed in grey.
Purpose
=======
When a new sales user is created, user is not in any team. The dashboard doesn't make any sense and he wouldn't know how to start working
Specification
=============
On salesman creation, the user should be assign to a Sales channel IF there is only one sales team of this type.
From Pillow 4.2, it is forbidden to save RGBA images as JPEG
( https://github.com/python-pillow/Pillow/commit/e4d6223c944cf44c468cc65a560b94dfcf351a62 )
A crash was occurring when loading demo JPGs as
image_resize_and_sharpen() was silently changing image mode to RGBA.
Now we ensure that we return the original image mode.
We also avoid crashes when converting from PNG to JPG
When xlsx is used, the worksheet name may be longer than 31 chars and
raise an exception.
This fix will troncate the name up to 31 chars and will remove invalid
chars.
Similar patch was already done at 0122c05eff for xlwt
xlsxwriter 0.9.8 has added a parameter worksheet_class=None so adding **kw to be
compatible with installs with the latest version (requirements.txt asks for
version 0.9.3)
Closes#18077
opw-751157
When an invisible x2many field is modified by an onchange, we had a
crash because the reset function did not return a deferred in that case.
This happens because the signature of _render in AbstractField allow for
an undefined return value, but the reset method should return a
deferred.
This was an issue for example in stock: editing the
pack_operation_product_ids one2many field in a stock.picking could
trigger an onchange on another invisible one2many (with no inline views).
This reverts commit 1e2e55872f.
In debug mode, there's a checkbox to reload the language and overwrite the existing terms. This previous commit makes that use case impossible.
PURPOSE
=======
When I install a language, I shouldn't have to refresh the page to see the newly installed language.
Example : I install a language, then click on my user (upper right corner) and try to select this language. The newly installed language is not available. I first need to reload my page.
There was a lost promise which made website_form loaded before the
languages informations (such as date format) was loaded.
The server expect the format of the client thus that could lead to wrong
or invalid dates.
opw-749544
closes#18074
This merge eases the signin / signup process by rellabelling / adding
options / cleaning support of auth tokens. It also improves customer
portal by cleaning the breadcrumb now using a simple bootstrap menu.
Finally people can now see their sale orders using an access token
without having to rely on website_quote.
Closes 17022.
We make the breadcrumbs of the portal uniform and remove them when we
access the document with an access token without being logged in
(for sales orders).
* allow new signup on invalid token
* relabel signup buttons
* send a welcome email upon signup with a signup token.
This way, should the token somehow be usurped by someone else,
the original partner's email address will be notified.
(before the usurper can change the email)
Mail now can handles a generic access_token in /mail/view route. Mail does
not do anything with it. Addons can override the controller and add their
specific management of this token according to some specific business
logic.
Sale order emails now contains the access token to grant access from the
notification email url without logging in. Sale portal now allow customers
to log in using an access token without having to use Online Quote. If
the user doesn't have an account yet and signup is allowed (B2C) an extra
parameter is added to the url to link the correct partner to the user upon
signup. If the user already has an account an extra parameter is added to
auto-fill the user's login if he wants to login from that session.
Account is also updated to prepare accepting access tokens. However the
complete implementation of accounting customer portal will be done in
another task coming soon.
In order to be able to identify what action to return based on the
access_user.
Typically portal users will need to be redirected to the front-end,
while internal users will need to be redirected to the back-end.
Invitu