Tomorrow never dies; however no need to add its working hours today.
Indeed rrule until parameter is inclusive. This means that in
current implementation next day is included in computation. This commit
fixes that.
Backport of 1f6ec2b8d6
When the quantity of a purchase order line is manually decreased and if
the purchase order line as been generated by more than one procurement.
If the new quantity is lower than the quantity of the smallest
procurement, it is impossible to validate the picking containg the
stock_moves created by the purchase order validation.
It is impossible to validate the picking, because it contains
stock_moves with 'product_qty' set to 0. Those stock_moves are generated
during the validation of a purchase order.
To fix this issue, we avoid the creation of stock moves with a
'product_qty' set to 0 which has no sense.
opw:708099
Resource module defines some demo data that are not used anywhere.
Moreover using resource module on its own does not give interesting
results as this is a tool module used in various addons like holidays
or project issue.
Those modules define their own demo data that will have an impact on
resource. It is therefore not necessary to define specific demo data
that does not help the user in any way.
Those fields are never used anywhere. Moreover attendance module can be
used to track employee log in / log out and compute its attendances.
Let us therefore remove those fields.
When you define recurring maintenance requests on an equipment, the
maintenance duration and the maintenance team is not set on the created
requests.
The problem comes from the creation method called by the cron that
doesn't use the duration and maintenance team to create new requests.
We now use these fields in the request creation
Before this commit, in the form view, if an attrs domain contained the
"id" field, it only worked if the "id" field was explicitely added to
this form view.
As the "id" is obviously known on a form view without the need to be
explicitely added, this commit allow using attrs domain containing "id"
in all form views.
Note: this seems to already work with list views.
The domain selector currently determined the list of available
operators according to field types (and used only a subset of
supported ones).
In some context, we might want to restrict this list of available
operators. Indeed, in client-evaluated domains, the "ilike" operator
cannot be used for example.
2 sequences are created when a pos.config is created:
- one for pos.order, stored in sequence_id field
- one for pos.order.line, link is lost, like dust in the wind ♫
When creating a pos.order.line from a new order, the default value was using the
first sequence if found using the code 'pos.order.line' (returning the latest
created).
The name of the line was always using the same sequence, whatever the config
used.
In master, the field has been stored at 645df676 but in stable version, the
following hack is done:
As the sequences are created in the same transaction as the pos.config, the
create_date will be the same to the microsecond.
The name of the config can not be used as too easily changed (e.g. duplicate)
and may not be unique.
Done in SQL to avoid ORM cleaning of microseconds, not working with a search.
opw-703092
The link between the pos.order.line sequence and the config was lost after
creation.
Using the default with next_by_code is incorrect as every pos.config has a
sequence with the same code.
With a sale order with:
- a stockable product
- the `Create Invoice` policy set to `Before Delivery`
After the quotation validation and the invoice validation,
if the user:
- cancelled the invoice,
- then validated it again,
- then hit `ignore exception` on the sale order
- then registered the payment on the invoice
The picking of the sale order was not created automatically,
and the sale order was therefore stuck.
Actually, it was just a write trigger that was missing:
The condition for the sale order workflow to go to the next state
is that the `invoiced` boolean is set to True.
It was, when the invoice of the sale order was paid
(after having registered the payment), but since
this is a computed field, not stored, no write operation
was actually performed on the sale order, and the workflow
wasn't "notified" that a change occured for the `invoiced` boolean.
A simple write on the sale order (e.g. in its notes) would
have unblock the situation, though.
This trigger ensures the worfklow to be notified when
the invoice of the sale order is paid, and therefore
when the `invoiced` boolean is set to `True`.
opw-706591
In saas-14, domain selector widgets are supposed to be instanciated
with a valid domain.
The problem is that some valid domains were wrongly evaluated. Indeed,
when receiving a domain which does not begin by an operator, the
"DomainTree" widget considered there is an implicit "&" operator that
should be used. This is not enough. Indeed, when evaluating the domain
["|", A, B, C], there is also an implicit "&" despite the fact the
domain starts with an operator ("|"). Because of that, previous
implementation interpreted this domain as ["|", A, "&", B, C] while
it should have been interpreted as ["&", "|", A, B, C].
Note: in master the parsing will be improved to handle wrong domains
and be decoupled of the DomainTree widget.
* The module was not loading the fiscal position templates before executing the template generation.
* Also, as reported in #15384, at the second installation it was crashing because of a missing xml id (which is not supported currently). This last bug was fixed by giving specific xml_ids instead of skipping the data.
This reverts commit 929d983575.
In some cases, the records have no xml_id like
in module l10n_jp, the way the account.fiscal.position.tax.template
are declared in account.fiscal.position.template.csv doesn't set
an xml_id for these records. So when using, the function create_record_with_xmlid
it raised an error if the record has no xml_id because it tried to concate
a string with a boolean with "str(company.id)+'_'+template_xmlid.name".
Fixes: #15384
opw:707704
When we add a SO line on a sale order with a product packaging, a
traceback is raised.
The problem comes from a default value and a domain set in the context
which reference a product template but since this rev: 796900feb7
the product packagings are linked to product_product and not
product_template anymore.
So we used the product_id field instead of product_tmpl_id. And remove
product_tmpl_id from the sale_order_line model which is not used anymore
This is a complement of previous commit.
As a portal user, access one of your invoices from the frontend
(download the PDF). The generation of the report crashes because of an
access error. The error arises when trying to access the company banking
information displayed in the report footer.
opw-708581
As a portal user, access one of your invoices from the frontend
(download the PDF). The generation of the report crashes because of an
access error. The error arises when trying to access the company contact
information (address, phone, fax...) displayed in the report footer.
This is due an API migration error (7eab8e26d3). Before the migration,
the partner was browsed in `_get_address_data` as:
`address = part_obj.read(cr, openerp.SUPERUSER_ID, ...`
After the migration, this is not browsed as superuser anymore.
Therefore, users with limited access rights won't be able to read it
anymore.
opw-708581
Only allows a manager to unlock a PO. Otherwise, when the option
'Confirmed purchase orders are not editable', any user can unlock a PO
and modify it.
opw-707035
When we select a variant on a product page on the eCommerce, this can
change the product image.
With this commit the change is also reverberated to the picture
displayed by the zooming feature.
opw-708089
When a message is not part of any channel, the message counter is
incremented while the message won't appear in any channel. This leads to
an inconsistency between the number of messages displayed in the status
bar and the actual messages in Discuss.
opw-706884
Commit b2cf955e made the lot_id always required in the
produce wizard of the manufacturing order (without work orders).
It should only be required when the finished product is tracked by lot.
The select DOM element which allows to select the template or
the LESS file to edit has been replaced by a select2 element
to improve usability.
- Add search bar
- Allow to add "customized", "unsaved changes" and level indentation
a better way (styled and icons)
- Add debug info (full less url / xml_id) only in debug, in small
The old "HTML" editor now handles LESS edition. The editor has now a
button to switch between XML and LESS edition. By default, it only
displays the odoo files which only appear in the assets_frontend bundle
and in debug mode, it allows to see all the files that influenced the
page design.
The new editor has a new set of options which allows to use it as a
xml editor only or a less editor only if needed.
Also: make the "include bundles" option appear only in debug mode.
Technical details:
- When saving a modified LESS file, an attachment is created with the
full modified content and an extension view xpaths the bundle where
the original file was added to link this attachment instead. This
relies on the fact that qweb, when generating assets bundle,
replaces missing files by the "datas" contents of the ir.attachment's
which have an "url" field equal to the urls it is searching.
- If a LESS error is introduced, the recent changes in assets bundle
generation (see c248674a5c) will not break
the design but only open a dialog on page loading, with the LESS error.
The user can then go to the LESS editor and reset its changes.
This feature code has been started with original work of @pga-odoo
Commit a2ae219d4e fixed the customize_template_get
function(s) which had been modified for the 10.0 web_studio release.
While the fix also reorganized the structure to make it more efficient
and understandable, it promised that the function would be refactored
in master. This is what this commit does.
The customize_template_get route of the website module was also removed
with commit 5a030db3eb as it was an useless
duplicate of the web_editor customize_template_get route.
The old route handled two totally different features of odoo: getting
all the page-related views to allow their edition with the HTML editor
and getting the "toggable views" which appear in the "Customize"
website menu. The parameter "full" allowed to determine which one the
route was supposed to do and was useless until website was installed to
add its feature (by extending the route behavior). In both cases, views
informations are returned, only the number of views differs. The
above-mentionned fix already did part of the refactoring by returning
the same info structure for each view in both cases.
Now, the function has been split. The web_editor customize_template_get
route is renamed as get_assets_editor_resources and returns the info the
HTML editor needs to work (the "assets" term is in prevision of the
new LESS editor).
A new website route "get_switchable_related_views" has been created to
return the info the "Customize" website menu needs.
Both use the renamed ir.ui.view function "get_related_views" (old
ir.ui.view customize_template_get function) which now returns a
recordset and not a list of dictionnaries.
If a bundle contains a file whose URL does not match any file in the
filesystem, its content is searched in the ir.attachment records.
The problem was that the content was base64-decoded but also had to
be utf-8 decoded to make its use work (like it would have been done
if the file was found in the filesystem).
Before this commit, when a LESS bundle compilation failed, web pages
were displayed without any style and the error appeared in the DOM
thanks to a custom ::before style which was ugly and not selectable.
Now the error is displayed like any other error in Odoo: in a dialog
with selectable content. The pages are also displayed with the last
style which was successfuly compiled.
If odoo dialog are not defined (a page without any javascript), a
fallback has been implemented to show the LESS error with a JS alert.