When using the inheritance spec `position="replace"`,
the framework will now support a text node exactly
equal to `$0` and will replace it with the node
that was matched by the inheritance locator.
Given an original view equal to this:
```
<div class="foo">
<p class="bar">the paragraph</p>
</div>
```
And an inherited view with the following inheritance spec:
```
<p class="bar" position="replace">
<div class="panel">
<div class="panel-header">The Title</div>
<div class="panel-body">
$0
</div>
</div>
</p>
```
The finalt result after inheritance would become:
```
<div class="foo">
<div class="panel">
<div class="panel-header">The Title</div>
<div class="panel-body">
<p class="bar">the paragraph</p>
</div>
</div>
</div>
```
Also updated doc and tests accordingly.
- remove unused helpers
- add command in case of deeper refactoring one day ...
- better variable naming
- use contants for Google services urls
- add docstrings
With a recent change in web client, the point of sale could not load
anymore, because the web_client code tried to call this.menu.reflow(),
but point of sale overrided the show_application, and this.menu is not
even instantiated.
Since the point of sale actually want a barebone web client, instead of
using the full web client, removing some of its features, and then
fixing the problems each time a change in web_client breaks it, this commit
ensure that the point of sale is started with just what it needs
By putting the shortcuts lowercase, it is easier to remember and to user.
Instead of Alt + Shift + letter, we have Alt + letter for Windows and Linus users
Instead of Control + Alt + Shift + letter, we have Control + Alt + letter for mac users
The combinations Alt + d and Alt + e are reserved to the browsers, so other letters are chosen
for these actions
From v4.1.0 of the documentation (2015-06-29), the HMAC SHA-1 key is
deprecated. Indeed, it should be considered as a legacy option to
guarantee compatibility with older skins.
The HMAC SHA-256 key should be used instead, and moreover, it seems that
any new skin created does not support SHA-1 at all, even if the option
is available.
The merchant signature code is inspired from the documentation example.
Source: https://docs.adyen.com/developers/hpp-manualFixes#9786
opw-676081
- Merge debug mode in dev mode.
- Allow to select dev feature ony by one
--dev=all will active all dev tool
--dev=
xml will read template in xml file and not in db
if not updated meanwhile
reload Add a watcher to reload the server if python code is modified
qweb Allow to add t-debug in template qweb
werkzeug Active the werkeug debugger console when an exception is raised
(i)p(u)db Allow to break before that the error is raised (old --debug mode)
To NEVER uses in production, since it give a console access in frontend.
2dcbdd0778 forward-ported
534ff9dd8c from 9. In master however I
have recently decided (bbaf956328) to
remove this field and use the standard active field instead.
In 8.0, the amount currency field was displayed
in the journal items list view
when choosing, thanks to the `quick add` widget,
a journal with a currency set.
Otherwise, if the journal had no currency set,
the column was not displayed.
It was done thanks to the key
"currency" passed in the context.
From 9.0, the `quick add` is no longer used,
and, due to that, the amount currency field
was no longer displayed in the journal items
list view at all, despite if the journal
had a currency set or not.
In technical words, `currency` was
no longer passed in the context,
making the invisibility property
set with
`invisible="not context.get('currency',False)"`
useless.
As this widget is no longer used, there
is no other choice than either
always display the column, either never.
We choose to display it only if you have
the multi-currency group (as this is the case
in the journal item form view)
We also take the opportunity to move the column
next to the debit & credit column, this is more
meaningful.
opw-676059
When creating assets from invoice lines, the system must check
that assets have not already been created for the related invoice.
If assets already exist then these assets have to be removed.
Used case:
- In the purchase journal, tick "allow canceling entries"
- On a supplier invoice line, set an asset category
- validate the invoice
- cancel the invoice
- set to draft
- validate the invoice
Before the fix: the asset is created twice.
After the fix: the asset is created once.
opw:674674
Note: This is a cherry-pick of commits 9d14230 and 58a5b5e
In v8.0, when a procurement is cancelled and the quantity remaining on
the PO line is zero, the line is deleted. It was not the case anymore
after the Purchase refactoring.
opw-675493
When creating a partner with company_type='person' and with an invoice
adress, the created partner must stay a person.
Now a partner which is not a comany can have an invoice address.
Fixes#11730
opw:675322
If the feedback of a form is too slow, people might be tempted to
click a second time, trigerring a second request. If, after that,
the result has not been received yet, the user might be tempted
to click a lot of time because he is angry at such slowness. This
behavior would trigger a record creation each time the user clicked
the submit button. This fix disables the button once it has been
clicked once, and re-enable it if the record could not be created,
which means that there was an error in the input and the user needs
to change the values and try again.
The button has been changed to a span to avoid the default browser
behavior to post the form when no function is bound on the send button.
If the feedback of a form is too slow, people might be tempted to
click a second time, trigerring a second request. If, after that,
the result has not been received yet, the user might be tempted
to click a lot of time because he is angry at such slowness. This
behavior would trigger a record creation each time the user clicked
the submit button. This fix disables the button once it has been
clicked once, and re-enable it if the record could not be created,
which means that there was an error in the input and the user needs
to change the values and try again.
The button has been changed to a span to avoid the default browser
behavior to post the form when no function is bound on the send button.
When creating assets from invoice lines, the system must check
that assets have not already been created for the related invoice.
If assets already exist then these assets have to be removed.
Used case:
- In the purchase journal, tick "allow canceling entries"
- On a supplier invoice line, set an asset category
- validate the invoice
- cancel the invoice
- set to draft
- validate the invoice
Before the fix: the asset is created twice.
After the fix: the asset is created once.
opw:674674
When creating assets from invoice lines, the system must check
that assets have not already been created for the related invoice.
If assets already exist then these assets have to be removed.
Used case:
- In the purchase journal, tick "allow canceling entries"
- On a supplier invoice line, set an asset category
- validate the invoice
- cancel the invoice
- set to draft
- validate the invoice
Before the fix: the asset is created twice.
After the fix: the asset is created once.
opw:674674
The pricelist field is not a mandatory field on the partner. A default
value is usually defined for any new partner created. However, if the
pricelist is manually removed from the partner, errors (tracebacks) will
occur in the eCommerce when no pricelist is found.
We cannot make the field mandatory, as it could potentially break the
workflow of some users which are not using eCommerce. Therefore, we
simply log an error message to help debugging.
opw-673453
The "Resumes and Letters" action simply displays ir_attachments
linked to hr_applicant objects; but there is no default_res_model
in the context so no ir_attachment you create is actually
displayed in the kanban view.
Since the goal of this action is simply to display attachments
linked to applicants, it makes more sense to disable the create button
and to force people to upload resumes and cover letters through
the applicant record.
Avoid raising an access denied error for messages that
the user has indeed be notified about.
The issue arose when a message posted on a document inaccessible
to the user was notified to one of the channels the user
is subscribed to.
The access control logic on messages relies on 2 heuristics
to grant read access to a message:
a. either the user was notified about the messages, by being
a follower of the document, or a subscriber of a channel
following the document (in that case the user can see the
message but not the document)
b. or the user has read access to the document on which the
message is posted (in that case the user can see both
the message and the document)
Case `a.` sometimes fail to match when a message got notified
to several channels including one the user was not subscribed
to. Depending on the order of the returned rows in the SQL
query, the "foreign" channels could shadow the channels of
the user, making `a.` a non-match.
If case `b.` did not match either, the user would have the
`read` access denied, even though the message was visible by
the `search()` method.
The fix explicitly makes case `a.` match if the user was
notified in *at least* one channel.
This was not done through a change of the SQL query ORDER,
for readability reasons.
From 9.0, a sales order to invoice is no longer a
sales order in the state `manual`, but with the
Invoice Status "to invoice".
Before this revision, the sales order to invoice
were simply not counted at all, and this
count always displayed 0.
opw-675919
Lines have to be wrapped manually as nor the ESC/POS protocol, nor the
hw_escpos module will do it for us. Before this long product names where
truncated to 24 characters by hw_escpos.
This wraps the product names using available spaces in the product
name. A product name with > 24 continuous characters will still be
truncated.
Jeremy Kersten