Setting a binary field stored in attachment may trigger recomputations on the
main record before all fields are set on that record. This may cause access
errors if the record does not satisfy some access rule because of the fields
that are not set yet.
Rev. 56cec604e6 modifies
the auto-commit behavior of the mail queue scheduler,
to allow using it within tests.
The condition was wrong and always True as soon as
the registry was loaded, permanently disabling
auto-commit, both during tests and outside tests.
This broke the duplicate emails protection.
Improved usability & code cleaning:
- Support for blanket orders, in addition of purchase tenders
("Purchase Agreements")
- Create a RfQ in one click, no wizard anymore
- Control of quantities really purchased
- Better control of side-effects thanks to purchase requisition types
- JS code removed (not necessary)
- Workflow removed
Closes#11666
When traversing relational fields as superuser, you end up with a recordset for
which only a subset is accessible to the current user. An earlier fix to this
issue completely dropped the `related_sudo` feature; change its implementation
to keep the feature.
Before this rev., if the user clicked, in the autocomplete dropdown, on an
already opened DM, nothing happened. Now, it redirects to that DM.
Also clear the input once a partner is selected.
When opening a new DM from the Discuss sidebar or from a chat window, and
when inviting people to a channel, first search for a match in the prefetched
partners (basically, the employees), and only perform the im_search RPC
(extending the research to all users) if there is no match.
Also sort the results by name.
There used to be some acceptance tests but they have not actually been
run since 8.0.
These acceptance tests are very useful for the POS because the POS is a
somewhat unusual module and it happens occasionally that a change in
another module unintentionally breaks the POS.
Another reason these tests are nice to have is because the POS
duplicates a lot of calculations in JS because it's meant to be able to
work offline (eg. calculation of taxes, orderline totals etc.). Subtle
differences (eg. rounding) between the frontend JS calculations and the
backend calculations make up the most common category of bugs in the
POS. These frontend tests will make it easy to write tests for these
scenario's. When phantom_js finishes we look through all the received
pos.order records and see that all of them are paid. If there would be a
difference between frontend and backend calculations the order would not
have the paid status because the payment on the order would be different
from the total. An example test for a previous bug has been included.
This will also come in handy for testing the upcoming pricelist
functionality that will be implemented in the POS.
Since the crm refactoring in V9, the stages doesn't make sense anymore on a lead,
as this step is only to validate an opportunity. We should remove this view as it
is confusing in this case : If I create a stage on the opportunity form view,
it appears also on the lead kanban view. Other side effects can also be encountered.
When invoicing several SO with same partner and with different invoice address,
different invoices have to be created with each invoice address.
Used case:
-create a customer with two invoice addresses
-create a SO for this customer with the first address
-create a SO for this customer with the second address
-select the two SO in the SO tree view
-click on "Invoice Order"
-click on "Create and view invoices"
Results:
Before the fix: The two SO are merged in one invoice with the second
address.
After the fix: Two invoices are created, one for the first address and
one for the second address.
opw:675961
The picking type is not defined on the stock move when a picking is
created manually. This can cause errors, for example in manufacturing: a
product sold in kit will not be replaced by its components.
opw-673741
The Automated File Upload (AFU) Ogone API requires a transaction code to be set,
either:
- ATR for automated transactions
- MTR for maintenance operations
The default is ATR and is used for submitting transactions in batch.
However, the server-to-server mode of payment_ogone only uses the AFU
API to create new credit card aliases, and not to process transactions.
Using the ATR transaction code requires the ATR feature to be available
in the Ogone Merchant account - a paying option that is otherwise
unused. Using MTR as the transaction code is sufficient for adding
aliases, and the corresponding feature (MTR) is available at no cost
in most Ogone Merchant Accounts.
References:
- Ogone Advanced Batch:
https://payment-services.ingenico.com/int/en/ogone/support/guides/integration%20guides/batch
- Ogone Alias Management:
https://payment-services.ingenico.com/int/en/ogone/support/guides/integration%20guides/alias/bulk-alias-management-via-batch
This is possible to create bank statements
forcing the amount in the foreign currency,
along with the bank account currency, and therefore
to force the foreign currency rate.
In such a case, when reconciling the journal items,
the currency rate conversion must not be done
against the currency rates written in database,
in the rates records, at that date, but with
the rate that was forced in the bank statement.
opw-676048
The current behavior was allowing going on the previous row if the
user is at the start of an editable element and on the next row if the
user is at the end of an editable element. The problem was, we did not
want this behavior when the editable element is a select or m2o (as
the up and down input should open the select/m2o dropdown instead).
When a user is subscribed to a channel with many messages,
the discuss initial rpc /mail/client_action can become very
slow (in production, the rpc took > 20s when subscribed to
the Community mailing list). This is due to the query in
_get_message_unread, counting the number of unread messages.
This commit adds an index on the relation mail_channel_partner,
this allows postgres to perform only index lookups, and speeds
up the query by 2 order of magnitudes.
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.
Raphael Collet