1/ The tip should be on the textarea, not on the button.
2/ The access right field on the quick user creation form is confusing.
I propose to put it in "Technical Feature" so that it's not visible for normal users.
3/ dissociate les settings tour from project tour
Was removed at 2e4b82f4 (for good reasons) but an explicit empty value is better
for migration as it prevents needing to explicitly removed the domain.
It is not possible to take money out or put money in for a PoS since it
leads to a traceback.
The decorator `@api.one` returns a list, which is something we don't
want when the method returns a dictionary.
opw-681417
The sales team defined on the project issue is never used.
Furtermore, in the method 'stage_find' contains a parameter team_id BUT
a project_id is given when called.
That way, we can also remove the dependency to sales_team which doesn't make
sense anymore, and remove 2 useless ir.model.access rules
Author: User who logged the activity in the chatter ----> Created By
Responsible: User assigned on the lead ----> Salesperson
Salesperson filer = Author. --> Same label : Created By
fields ref, journal_id and date on account.move.line are all related fields on
the account.move.
Setting a value here is then useless and triggers write on the account.move
after the creation of the account.move.line (inverse values in write)
Function fields, old-api style, that are not stored do not have cache
invalidation mechanisms. This means that they are recomputed every time the
field is accessed.
Due to the way the cache behaves, the records that are present in the cache will
be included when the prefetching is done.
In the scenario of the a POS session being closed, this implies that the cache
will contains more and more account.move.line records and try to prefetch all
(hopefully max 1000) without ever relying on the computed result for the next
access. This makes the computation of fields `amount_total` and `price_subtotal`
very slow, even for orders with a very low number of lines.
Backport the new API migration of these computed field to benefit from depends
mechanism and keep the computed value into cache when needed.
In master these fields should be stored.
On the other routes (e.g. /my/, /my/contract/) payment information on the parent
contact are displayed but can not be access in the my payment route.
You get in a unconsistant situation where you can access the contract of the
company and its payment information but can not use this payment information.
opw-681491, opw-681502
- add a new checkbox on fiscal position: TaxCloud API
- when computing this fiscal position, it will:
- return an existing tax if one exists for the same tax
percentage, state, zip and TIC Category
- or create and return this tax if it does not exists yet
- Create a data fiscal position: country U.S., tax cloud API
- In l10n_us, add a settings in accounting: compute tax automatically using tax cloud.
NB:
- The signature of map_tax has been modified to optionally specify the product
and the partner on which the tax is applied
- The avoid the validationerrors that may occur while evaluation the tax with Taxcloud
when a public user is on the frontend shop (website_sale), we have to execute the
error silently by logging it.
This extension of the method `mapped` is a consistent extrapolation of mapping
a recordset through an optional sequence of relational fields. It removes the
necessity of special-casing the empty sequence, and also avoids an obscure
exception in that case.
An access error occurs when a the delivery address of a SO is set to a
different partner than the SO partner. In this case, the picking
created is associated to the partner of the delivery address. This is an
issue when the SO partner tries to view the picking from the front-end
("My Account"), since he is not allowed to access it.
opw-681341
The computation of the total_invoiced field did not work in batch mode.
When displaying a company in a form view (field invoice_total comptued), the
children of this company are present in the cache and the value of the field
invoice_total will be prefetched for these children as well (at least in 9.0).
Most of the time this is redudant information and the same value is computed
for each child while most of the invoices are on the parent.
Batching the computation per partner allows to make one global query for all
partners.
Add test to make sure the total increase correctly after a test invoice
confirmation.
When browsing a form with a one2many / many2many field
with several pages, the one2many pager page was not reset
when going to the previous/next record, while the next/previous
record could not have multiple pages on its one2many/many2many,
and the page on which the user was on the former record could
not exist in the newly displayed record.
Besides, even if the page does exist, there is no reason
to display this new record X2many value from its first page.
It's the case anyway when you edit/save, it comes back to the first page.
opw-679092
Bug introduced in 7eab8e2.
As `self.env.user` is browsed with `sudo`, the result of this call
will always return the admin's current company and not the user's current
company.
opw-681809
With the pricelist, it is possible to define a pricelist just for
a variant. But in the product.product.form, only the pricelist items
linked to the product template could be displayed.
The field item_ids has been created in product.product model to display
all the pricelist applied on a product.
opw:674700
Basicaly, do this RPC once, at webclient startup, to get the next notification.
Do the RPC again when the notification is displayed to get the next one.
When an event with alarm is created, edited or removed, trigger an event on the
bus for all involved users (the attendees) with an update of their next
calendar notification.
Before this commit, the list view, grouped by a selection field, displayed the
'technical' value of the field as group label. It was basically forced
to do that, because the result of the read_group only contains the
technical value.
This commit changes the list view in a way that it now requires a full field
get, so it can use it to find the correct string.
Let's take the following case:
- Enable lot tracking on a product
- Costing Method is "Real Price", Inventory Valuation is "Perpetual"
- Create a picking with 2 stock moves, each stock move is linked to the
same product
When the picking is validated, 4 account moves are created instead of 2.
This occurs because the list of stock moves and the list of reserved
quants is sent to the method `_move_quants_by_lot`, but there is no
check to which stock move is related a given quant.
For most cases, the issue doesn't show up since there isn't usually 2
stock moves with the same product in a given picking. There is at least
one use case where this happens: selling a pack of two identical
products. In this specific case, 2 stock moves of the same product are
created, but one pack operation will merge the 2 stock moves.
opw-680308
_('foo '+bar) does not work as `bar` is a variable with undefinied content
during translation export (and variable content during evaluation) so a match
will not be found.
Also trailing spaces are stripped during synchronisation with transifex.
The proper syntax would be
_.str.sprintf(_t("foo %s"), bar)
but to avoid breaking existing translations (need to reexport .pot)
use the syntax
_("foo ") + " " + bar
that is more stable friendly.
The 'No value found for the field...' string is not possible to be fixed without
breaking the translations should be split at least twice.
Write it the propre way directly.
These accounts are created automatically on the journals creation
e.g. On the creation of a Bank Journal, a Bank account is automatically
created, linked to this journal.
Before this revision, when installing the generic chart of account
(or l10n_us), you had two Bank accounts (101400, 101401),
and two Cash accounts (101500, 101501),
by default,
which is not right.
opw-676950
Search engines (or one at least) truncates the description at 160. The advised
size is between 150 and 160 so no need to force a smaller size. It's a good
idea to keep it at 155 but larger sizes should be allowed.
cf: https://moz.com/learn/seo/meta-description
We could fully remove the limit as there is corner cases where a longer size is
used (https://moz.com/blog/i-cant-drive-155-meta-descriptions-in-2015) but this
should be in addition with an indication for the user of the current size and
the advised size.
Yannick Tivisse