Since the revision
5e3de76f36
The `::text` is included within the `unaccent` call
The expession tests have never been changed according
to this change of behavior in the building of the unaccented
queries. This has never been detected by runbot because
you need to start the Odoo server with the option
`--unaccent`
and to create the database with the unaccent extension
`CREATE EXTENSION unaccent`
to be able to fail the former tests,
and this is not the case on runbot.
Before this commit:
website.page won't be rendered as translated items since it is not going though
a controller (route) enabling multilang. Website.page were not considered as
multilang items and no lang prefix were applied on link.
Now:
website.page will correcly handling translation.
In case of one route doesn't match a controller, it is now by default a route of
type multilang.
Add a new field auto_redirect_lang on website model to allow to deactive the
autoredirect of the lang optionnaly. The code will arrive after more tests.
Before this commit, the website.redirect records would never been called since
we switched call order from redirect>page to page>redirect.
It would always render a 404 and would never check redirect records.
Now, if there is no page found, it will check for redirects and if no redirect
found it will return 404.
Before this commit, an unpublished page present in menu would throw an error for
public user (group_portal & group_public) because of the security record rule
set on website.page model not allowing read access to unpublished pages:
<field name="domain_force">[('website_published', '=', True)]</field>
In this particular case, we try to retrieve the menu URL, but since the URL is
retrieved through its (m2o) website.page, it would cause an error.
Now, it the menu has a website.page unpublished, we will correctly retrieve its
URL (sudo) and it won't crash.
Don't add useless routes or route that will return 404.
Improve generate function from ModelConverter to have a better management of
query_string.
Now we have an helper sitemap_qs2dom that will analyse the current route and
check if query string is plausible and if yes, generate a domain, when the
query_string don't seems to match the route, we return a Falsy domain.
Before this commit, if qs was /product/ipad, enumerate_page check for each
modelconverter of the route a name ilike '/product/ipad'.
Now we check all routes that contains product and one converter that match ipad
or routes that contains ipad and one converter that match product.
This commit a new way to declare the sitemap for a route.
def sitemap_xx(env, rule, query_string):
yield {'loc': '/my_url'}
@http.route(..., sitemap=sitemap_xx)
In this case, only the loc returned by this function will be in the sitemap
for all rules.
You can pass sitempa=False, if you don't want that route are into the sitemap
The user could be able to add a move in an existing MO
as a correction (thus only in edit mode).
In order to do it we use the existing system of move
by overiding the default_get and set the state directly to
'done'.
Before, in case of non-tracked components, when everything foreseen had
already been consumed, it would not add the theoretical quantity on
producing through the produce wizard. This makes little sense as the
behaviour of the wizard is not the same anymore for all cases and this
can only confuse the user.
Make it possible to add an extra line in the produce wizard. This was
done for when we consume more than foreseen to be able to still add e.g.
the serial number.
We apply a lock/unlock mode for the mo as was done for the picking.
In locked mode, the user can do all the regular things, but not change
the quantities done given by the work order or produce wizard.
In unlocked mode, only allowed by the mrp manager, the user can change
those quantities.
We opted to remove the 4 lines and just use a check box to indicate
there are lots behind a line.
For the finished products tab, we opted to show the move lines instead
of the moves as this way, you don't need to click further. If nothing
has been produced yet, a message indicates to produce something first.
When processing moves with 0 initial demand,
it will set the initial demand = qty_done. Also, when updating the quantity of
an MO, don't take into account those with 0 quantity.
To confirm expense, you have to be expense manager,
which implied HR officer. This implied relation is
not required anymore.
For the HR apps to be independent, removing this
relation is better and does not impact normal
expense flow (submit - confirm - post).
This commit ensures that the prerequisites for the new tablet view
(introduced in Enterprise) are met. Aside from a few additional fields
and simple view modifications which allow simpler changes via
inheritance, the main change it introduces is the capability to take
into account consumed quantities of untracked components.
This revision allows the page number of a pdf file to be set via an
integer field. If the pdf widget is attached to the 'field' field, then
the page can be changed via the 'field_page' field.
This revision changes the BOM and routing of what was previously a
"computer desk". The aim is to provide a complete example which can be
used to showcase what can be accomplished with the new tablet view.
* fix breadcrumb for invoices in portal, when going into an invoice
the 'Invoices' part of the breadcrumb allowing to come back to the
invoices list was not a link;
* remove duplicate of invoice reference in page view;
On chrome only, the translate icon was over the <input/> element but
below the <input/> text... this commit fixes this by forcing
relative positioning on the icon so that it is always rendered after
the <input/> (which seems to solve the chrome bug).
Posting a message on a custom model (i.e. created with Studio) crashed.
If it's a custom model, its `_original_module` attribute is not correctly set so
trying to retrieve the icon based on this attribute does not work.
Before this rev., onchange specs where only computed up to level
2 (i.e. for fields inside x2many fields). So basically, if there
were a one2many list inside a one2many (e.g. which opens in a
form view), the fields of that inner one2many list weren't added
to the specs, and it could lead to unexpected responses from the
server (like erasing the changes made on the inner one2many
records).
Closes#19600
Denis Ledoux