In 79038055 amount_to_text was refactored and improved, but there is a
drawback.
ie. if we have .29 cents with two decimals, `Twenty-Eight` was displayed
because `int(0.29 * 100) == 28` due to floating-point representation.
This commit keeps the improvements and fix this issue by using string
formatting of float as was done before.
opw-1829924
closes#24161
It used to be possible to run test transactions against mercurypay.com
using a regular swiper device, test credentials and test cards
provided by Mercury.
Mercury has recently disabled this saying this feature did not adhere
to certain PCI regulations.
It means that currently on the regular mercurypay.com network only
real cards (and thus real money) can be used.
Because we require a way to test without spending money this commit
allows to switch to the test network (mercurycert.net). It uses a
system parameter because we cannot introduce a Boolean on
pos_mercury.configuration in a stable release. It also changes the
test credentials to some that work on mercurycert.net.
Note that the regular 'production' swiper devices can not be used on
this test environment. This results in:
Error 004118: Failed to decrypt
The swiper contains embedded cryptographic keys specific to
mercury*pay*.net. Instead a specific 'development' swiper device with
embedded keys for mercurycert.net is required.
opw-1832156 (this is necessary to test that issue)
Before this commit, error handling would not work for non s2s payment acquirer
since it would always check for `o_payment_add_token_acq_[id]` in the DOM but
this is only present for s2s acquirer.
Non s2s acquirer got `o_payment_form_acq_[id]` in the DOM.
Now, we retrieve the correct DOM element depending if s2s is enabled for this
payment acquirer or not.
task-1825701
- Create a SO of 56.16
- Send the payment link to the customer
At payment, the transaction is refused by Authorize because of an
invalid amount.
When looking closely, the data sent to Authorize contains the amount
56.160000000001. This is due to the float representation. To avoid this,
we use `float_repr` instead of `str`.
opw-1832468
The expand arrow hides the last characters of the first line, which many
people (and me in particular) find annoying. We put it at the bottom
instead.
opw-1830762
- Install stock_calendar
- Create a stockable product
- Add the route "Buy"
- Add a vendor with a delivery lead time of 30 days
- Create a reordering rule for x units
- Run the schedulers
A PO is created, but the scheduled date is set as today, not today + 30
days.
What happens is the following:
1. Since no `calendar_id` is defined on the orderpoint, `_get_group`
returns `[(now, None)]`
2. `now` is used in the `procurement_values` of the `res_groups` by
`_procurement_from_orderpoint_get_groups`
3. The `res_groups` values are used in `_procure_orderpoint_confirm`
when calling `_prepare_procurement_values`.
4. `_prepare_procurement_values` is overridden by `stock_calendar` to
set a value for `next_delivery_date`. At this point, the `now` value
is used.
5. Finally, when creating the PO line, `_prepare_purchase_order_line` is
overridden by `stock_calendar` to set the `next_delivery_date` as
`date_planned`.
So, `date_planned` becomes `now`.
There should not be any date set when no `calendar_id` is defined.
opw-1828371
In order to improve the speed of landed cost validation, we defer the
creation of AML at the very end of the process. This way, we don't
suffer from various performance issues caused by:
- cache invalidation (use of `with_context`)
- recomputations
opw-1824661
In FIFO, the stock move cost related to the picking of the POS
Order must be used to compute the price.
Fine tuning of this commit: a36ff26ce0
opw:1829801
When the user set a decimal accuracy on the product quantity, the point_of_sale
(POS) frontend would display the correct rounding of the quantity according to
both the decimal accuracy and the rounding set on the unit of measure.
However the quantity used to compute the price was only using the rouding on the
unit of measure. This led to an inconsistency in what is encoded in the backend,
and thus made it impossible to close the session as the price paid by customers
did not match what is encoded.
The problem comes from the fact that there is a variable this.quantity and
another one to display this.quantityStr. Unsurprisingly, this.quantityStr
was not computed directly from this.quantity, leading to the inconsistency.
opw 1826092
The preprocess method checked if the project_id value
was given to determine if it was a timesheet or a normal
analytic line (since a timesheet is an AAL with project_id).
The problem came in the write, when changing only the project
value, the preprocess use the timesheet case, but since the
employee field was not changed, no value was passed, and it
compute the default one. So changing the project of an existing
timesheet reset the employee to the current one.
Before this commit, the first thumbnail from the multi image carousel was
always disabled since there are no atribute data-slide-to.
Now we force a '0' string instead of 0 falsy value to have explicitely
data-slide-to="0" after the qweb rendering.
Steps to reproduce the bug:
-Let's consider a multicompany environment with company A and B
-Let's consider a shared product P for A and B
-P has a deferred revenue type D set on it
-D is defined in A
-Let's consider a user U in company B
-U creates a SO with P and try to generate the invoice
Bug:
A access error was raised because U is not allowed to see D and
D is needed to genrate the invoice.
opw:1825944
When validating a statement with old posted moves, the lock date
was checked by function, _check_lock_date and then it was impossible
to validate the statement even if all the moves were already posted.
Backport of this commit: 86a0d31251
opw:1830804
When a user click on an action button, we need to check if the record
match with the domain to remove it from the view if this action change
the record value.
Special case: we filter by active field equal true, if the active field
is available in the data (field present in the kanban view).
opw-1832879
Co-authored-by: Nicolas Martinelli <nim@odoo.com>
Install a database in some other language than en_US
In debug mode and in the app list viewer,
you'll see that the apps field are translated into your language
Then do an "Update App List"
Reload your page
Before this commit, the Apps' field lost their translation
This was because when checking for any updated data for known modules,
the ORM fetched the translation automatically, and compared the old (translated)
value with the new (English) value from the manifest
After this commit, This operation doesn't make the translations to be lost,
because only english values are compared
OPW 1832796
closes#23910closes#24091
Since 3d04e4488, several pages have to be denoted by:
`<div class="article" />`
And not as previously:
`<div class="page" />`
This was not taken into account in the "Location BarCode" report so we
had only one page of barcode (so 4 barcodes since there is 4 barcode by
page) displayed.
fixes#19698
opw-1817574
closes#24098
This commit format the display_name of sale.order.line,
without context key.
The webclient trigger the name_search with context
key, but display the field without it.
So on task form view, when searching an SO line, user
will see 'SO0001 - my product' in its dropdown, but the
complete SO line description when saving.
This commit proposes, in aggreement with AL and FP, to
a global (and non conditionnal) format, since it seems
task form view is the only one place requiring the SO
line name_get.
The id of the record may be a real database id or a string containing a virtual
id (e.g. "42-20380119031417").
The id is always stored as a string but must be converted to int when sent to
the ORM (to avoid self.browse('42'))
The calendar modules do handle correctly virtual ids in its unlink method but it
is not the case of the other modules that are expecting integers.
Convert to int if we are working with real ids
Replace and closes#22115
self is a rml_parse instance, not a BaseModel
create new environment to call ORM methods
prevent crash when calling formatLang on a RML report
Closes#24068
When not draft, the partner_id field is readonly and cannot be modified
anyway, but it makes the form invalid, so form buttons cannot be used,
e.g. to access the journal items, etc.
When the `partner_id` is not set (it is not required at the model
level), we can still compute the default destination account based on
the company chart of account configuration.
This is necessary to allow creating "customer" or "supplier" payments without
selecting a specific partner.
Commit d39856db prevents crawler to crawl and index blog tag URL which could
lead to possibly millions of URLs combinaison.
Still, it would crawl (but not index) second level of tags combinaison.
This commit ensure that crawling is prevented when already one tag on the URL.
Before this commit, when some records were created from an `onchange`,
we have the following weird behaviour:
Suppose that this record has some required fields that are empty.
When we click on this record, then somewhere else, the record
disappears from the list.
This is because the records contains invalid fields, and it is wrongfully
assuming that the record to be discarded comes from "Add an item".
A previous commit [1] fixed a bit this issue with `default_get`, but since
it relied on a fragile heuristic, we decide to apply the correct fix with
this commit.
[1] https://github.com/odoo/odoo/commit/b09f0c99be2b13d33986414485556d87da186d65
Before this commit:
If a blog had multiple tags on the page, the crawler would click on every one
of them one after another until every tags combination got crawled.
With a lot of tags, this could result in million of URLs.
Now, we prevent URLs with more than one tag to be crawled.
Eg: With tags 'A', 'B', C':
/A
/A/B
/A/C
/A/B/C
/A/C/B
/B
/B/A
/B/C
/B/A/C
/B/C/A
/C
/C/A
/C/B
/C/A/B
/C/B/A
Nicolas Lempereur