On the website,
when registering for an event with ticket,
the placeholder `Attendee #` could not be translated,
as `t-att` attributes are not translated.
An alternative is to put the string to translate
in a `t-set` node, which can be translated, and
to use the variable assigned in this `t-set`
in the `t-att` attribute.
opw-678758
By default, werkzeug doesn't preserve the order
of the parameters sent to routes.
As stated in the werkzeug documentation:
```
parameter_storage_class
the class to use for args and form.
The default is an ImmutableMultiDict which supports multiple values per key.
alternatively it makes sense to use an ImmutableOrderedMultiDict
which preserves order or a ImmutableDict which is the fastest
but only remembers the last key.
It is also possible to use mutable structures, but this is not recommended.
New in version 0.6.
```
For some of our use cases, it makes sense to keep the order
of the route parameters.
e.g. In the website builder, when building a form
with a bunch of inputs values that will be concatened
in a lead note, the user expects the answer to be displayed
in the same order than the form inputs.
This change is seen as a bit risky as it could lead to
performances issues in the http routes processing, and this
is the reason we do not merge this in stable 9.0 at the moment.
If needed, it could be back ported later to 9.0, after
several weeks/months of testing in this release(saas-10 atm).
opw-677508
Since dce2a309 submenus where hidden by using the class `o_hidden` but
this was not taken into account when showing them (so opening submenu
was not possible).
[NEW] point_of_sale: new tour
[IMP] hr_expense: main employee is created by default, so that you can
use the email gateway and record expenses, without configuration
required
[IMP] all tours: applying JWR propositions: americanization of tips
[IMP] crm tour: add invite people steps
Merge branch 'master-expense-tip-fp'
Usability: remove the Settings tour and include the addition of users
back at the end of others tour. The reasons:
- When someone starts with Project, we don't want to invite him going on
the settings tour (Don't make me think/choose)
- If the user starts with Settings (e.g. out of curisity), he will not
have a great on boarding experience.
- We expect the user to follow the steps in this order 1/ discover
project tasks and, only after, 2/ invite users (he will probably not
invite users before discovering the application)
The drawback is that we have to add "Invite Users" steps on others tour,
but only those for which it has a sense:
- Website, Accounting, eCommerce are typically single-users apps (we
don't need to make him invite people)
- CRM, Project are multi-users apps
There's really no reason to limit group_operator to numeric fields and Postgres's flexible aggregate make the ability to aggregate on non-numeric fields (and/or non-numerically)
* moves group_operator to Field
* adds a default value of `sum` on integer, float and monetary fields
* in read_group, filters on fields with a group operator rather than by
type (also allow id fields, since Id doesn't have a group_operator by
default it will be ignored anyway) (sequence is still specifically
excluded for now because they're usually regular Integer fields)
Closes#12372
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
The field bom_count appeared twice in product.template form view and
then the smart button for "Bill of Materials" always displayed 0 as
number of BoMs.
opw:681830
It might happen that a transaction produces more than one message in the
chatter. In this case, the messages are created with the exact same
date, and they might appear in the wrong order in the chatter.
We therefore sort the messages by id, and not by date. Note that the
messages are already sorted when received from the server, but the web
client has its own management of the messages' order. Relying on the
server order might imply to change other parts of the code on client
side, which is something we want to avoid on a stable version.
opw-681049
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.
Commit d349584 solved the state change tracking of pickings, and
moreover prevents unnecessary state changes to be recorded. However,
this also prevents the state "Done" to be recorded in the chatter.
Saving properly the state change for the picking might be quite tricky,
since the stock processes sometimes imply unreservation/rereservation of
quants, and therefore lead to several state changes inside the same
process.
opw-680343
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
Denis Ledoux