- When creating a Stripe charge, we have the possibility to send the customer email.
This is then used by Stripe to send a payment notification (receipt) to the customer.
This was never done by Odoo, this commit introduce this feature.
OPW-1829945
- 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
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
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
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
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:
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
Create a hr.attendant in a stage where a mail template is present.
Fill the email field as: Name Surname <name@surname.com>
Before this commit:
- the created partner's email has been rendered as name@surname.com>
- the email failed to be sended because of this
This was because Jinja rendered that snippet escaping the special characters
Putting a 'pipe' safe in the snippet does the trick
After this commit:
both the partner and the email are created successfuly
OPW 1830739
closes#24059
category was changed to "Website" so it'd appear under the website
category in the store, but it needs to be "Theme" otherwise it doesn't
appear in the "Choose your theme" menu after installing website.
This is a backport of 10.0 https://github.com/odoo/odoo/commit/3d53a740
Without extra themes, the "Choose your theme" would be empty.
fixes#21898
opw-1802936
closes#24042
Before this commit, if you or a lib uses Glyphicons, the font was loaded from
/web/content/fonts/ (or /web/static/src/less/fonts/ in debug=assets)
It is because bootstrap is imported from /web/static/src/less/import_boostrap.less
not directly from /web/static/lib/bootstrap/less/bootstrap.less
Now, we use absolute path to load font, overriding the variable define in
variables.less from bootstrap.
When installed, marketing_campaign shows the root "Marketing" menu by
default but this menu is not an action and just contain a
"Configuration" submenu without action as well.
Thus in community we got on a page without content, and on enterprise we
got a JS error.
note: only happen in 9.0
fixes#21898
opw-1802936
closes#24026
When saving the settings, we perform a `write` on the groups and implied
groups. This will trigger a recomputation of the fields `share` on
`res.users` and `partner_share` on `res.partner`.
On a database with many users, this can lead to a non-negligible time
spent in these methods.
opw-1830145
On 'My attendance', do some check-in/out operations
while on the server side, everything was ok, the display had some issues:
On Chrome, that worked well whereas in Safari, it did not
since the Date() implementation only accepts ISO date strings
We take the opportunity of this fix to handle dates with moment.js, which accepts non-ISO formats
OPW 1831555
closes#23962
When creating sales/purchase receipt for a journal having a secondary currency, an error was raised as the amount_currency had the wrong sign (compared to the debit/credit).
Was Issue #1819396. Was PR #23768
With project_issue installed, and when deleting an analytic account, a search
is done to check if there is linked issues. When the current user has no access on
the project.issue model, an error is raised. This check should be done as an admin.
Before this commit, when accessing the payment page with arbitrary amount
(/website_payment/pay?reference=Testinvoice&amount=150.0¤cy_id=6&country_id=)
A traceback was thrown because the keys concerning the partner were not present in the dictionary
that prepares the values for the form that we send to Stripe
Considering that those info are not mandatory for stripe (although not very good practice -- the more info the better to verify an identity)
we ignore them if not present
After this commit, the public route works fine
OPW 1832164
closes#23948
Before this commit, the smart button on the SO was computed
with only the SO's name field
In a multicompany setting, it could give up invoices from other companies
After this commit, only the invoices of the same company as the order are accounted for
OPW 1831551
closes#23925
To be able to retrieve the base amount of cash basis taxes lines, additional journal items are created for the base as well in the journal entry generated by the payment.
However, these additional journal items debitting and creditting the same account are considered as pollution in reports.
This module and hook allow to move these additional lines to an another account, if needed.
-task: https://www.odoo.com/web#id=35605&view_type=form&model=project.task&action=333&active_id=967&menu_id=4720
Was PR #23349
Steps to reproduce the bug:
-Create a tax of 21% tax included but don't select the "affect base" checkbox.
-Create another tax of 5.2% (no tax include)
-Create a sale order with a line that has a unit price of 121 and both taxes.
Notice that the total amount is: 126.2 (100 base amount + 21 from 21% tax + 5.2 from 5.2 tax)
-Click on "Print the proforma invoice"
Bug:
The total amount was still 126.2 and base=100, however taxes were wrong, there were 21 for the 21% tax
and 6.29 instead of 5.2 for the 5.2 tax.
Back-port of this commit: f50a08bc3d
Forward up to saas-15
opw:1819882
- Set the number of digits of 'Product Unit of Measure' to 1
- Create a stockable product:
UOM: Dozens
Purchase UOM: Units
- Buy 17 Units, validate the picking
- Create a landed cost:
Amount: 100
Split Method: By Quantity
- Compute
The Valuation Adjustment line contains contains a line with a quantity
equal to 1.4, leading to a line of 98.60. It is impossible to validate
the landed cost because of the inconsistency.
The method `get_valuation_lines` retrieves the data from the
`stock.move` and copies the following values to the
`stock.valuation.adjustment.lines`:
- `product_qty` > `quantity`
- `weight` > `weight`
- `volume` > `volume`
Therefore, we must make sure that these fields are using the same digits
precision. We adapt the precisions accordingly.
opw-1817783
Commit b6d4cd5deb introduced the auto-reconciliation when reversing
an entry. However, we should make sure to only reconcile non-reconciled
entries. Such an entry can be generated from an exchange rate entry.
opw-1826024
When doing a sudo on top, the fields are accessed with user 1 but the set is
also made with user 1.
meeting.user_id.partner_id.id is correctly computed but
meeting.partner_color_id is not set for the current user (return 0)
All events were in the same color
Introduced at b669c71aa3
opw-1829793
Closes#23923
Commit cae188514f was largely incomplete
and inaccurate in fixing the issue at hand
The aim of this commit is to deactivate the form buttons when the Html field is not completely loaded
thus preventing the temporary value of the iframe to be saved
OPW 1824545
closes#23905
Steps to reproduce the bug:
- Create a bank statement with a blank name
- Reconcile any line statement with an invoice
- Review the payment that was made for this statement
Bug:
The payment had no name.
opw:182754
When you create a down payment invoice from an SO, the product that is used in the line is 'Down Payment'.
The description of this product, which is visible for the customer, was not translated to the language
of the customer in the SO and in the invoice. It was translated to the language of the user logged.
This fix is made to keep the same behavior for the description of an SO line and for the description
of the invoice line.
opw:1820081
The ZIP code is an optional field. When saving a payment method, this
generates a traceback since `partner.zip` is `False` while the field
expects a `string`.
opw-1829829
Toufik Benjaa