To compute the week number, the fullcalendar.js library uses the locale.
It depends on the day on which the week starts (usually Sunday in the Americas,
Monday in Europe), as well as which week is considered the first of the year.
In commit:
https://github.com/odoo/odoo/commit/717b472ef9ad6d2998cbefb4aafe2d1199e6235d
the starting day was explicitly added, however it was computed as isoWeekday.
The ISO first day of the week is always on Monday.
It resulted that if the locale used Sunday as first day of the week, the
calendar would consider it to be of the previous week, and thus displayed
(weeknumber - 1).
The fix does the same thing as was done in v10, taking the locale into account:
https://github.com/odoo/odoo/commit/df124080b624a8bdb86fec352fe690725ed36bac
opw 1853745
Let's consider a Sales user U with no access to Purhcase
Steps to reproduce the bug:
- Create a SO with one line with the drop shipping route
- Validate the SO
Bug:
A access error was raised because the user has no access right on
Purchase.
opw:1851301
Before this commit:
* Module A defines a field X of model M
* Module B inherits from model M without touching field X
* Module C inherits from model M and extends field X by giving an INDEX
/ NOT NULL constraint.
* Module B and C depend from Module A, but not each other
If all three modules are installed and Module B is updated, the INDEX /
NOT NULL constraint could be dropped.
This happens because Module B can be loaded before Module C is loaded,
if that's the case, then after the upgrade of Module B, during the
schema checking, we verify that the field object we have and the field
on the DB are the same, since Module B doesn't introduce the index then
this check is false and we drop the index. When we get to loading Module
C, we do not do any schema checking because the module is not marked as
`to upgrade`, therefore the index is lost forever.
To solve this, we re-init the models that belong to the set of the intersection
between upgraded and modified models and loaded and modified models.
Fixes#24958
When archiving a product template P with one SO linked to it,
- Going to P by Accounting > Configuration > Products > P shows 1 sale
in smart button
- Going to P by Accounting > Sellable products > P showed 0 sale in smart
button
Now it shows 1 sale in these two cases.
opw:1852948
Make one Payment
Reverse the entry of this payment.
Before this commit, only the lines in the receivable were reconciled.
The lines in the liquidity were'nt, leaving the two entries appearing
in some reports
After this commit, the four lines are reconciled two by two, even in the liquidity
account
OPW 1816641
closes#25026
- Create a picking, set as 'Carrier': 'Free delivery charges'
- Enter a 'Tracking Reference'
- Validate the picking
The tracking reference is removed.
opw-1849279
If the `web.base.url` contains a trailing `/`, the replacement of the
`/unsubscribe_from_list` link won't work since the string to replace
will be `my_url//unsubscribe_from_list` instead of
`my_url/unsubscribe_from_list`.
Fixes#24731
opw-1848572
In the portal module,
the `index` method from the `web` module controllers
is overriden to redirect `/`
to the portal `/my` for the portal users,
instead of the regular backend `/web`.
However, when `website` is installed,
this behavior should not happen,
as you would like the signed in portal users to
be able to see the website homepage,
and not to be redirected to `my` when
they try to access `/` root path of the website.
Because the override in the website module was done on the
`index` method coming from the `web` module instead of the `portal`,
according in which way the Python module were loaded,
it sometimes redirected to `/my`, sometimes it correctly
displayed the homepage. This is because the modules are not
loaded in a determinist order.
To summarize, on runbot, if you logged as portal/portal,
one time on two you were redirected to `/my`, and the other
time you saw the homepage correctly.
As `website` depends on `portal`,
we have the possibility to override the `index` method
of `portal` instead of the one of `web`,
to force the determinist order,
and therefore the determinist behavior of the homepage for
portal users.
When installing the `account` module, some of its master data is
installed as `l10n_generic_coa` data.
During the uninstallation of `account`, `l10n_generic_coa` is
uninstalled first since its a dependency of `account`, but some of its
master data cannot be uninstalled yet as its still being referenced in
some `account` et al tables.
When `account` is being reinstalled, the datas will be updated instead
of created since they were left intact in the database, this proves
troublesome as the code YAML interpreter adds some context variables
when creating records but not when updating records, these context
variables are necessary in order to trigger some onchanges and defaults
for fields that are required, since this does not happen we get a `NOT
NULL CONSTRAINT` error when re-installing the `account` module.
This patch solves this issue by adding an uninstall_hook that will
delete all ir_model_data that belongs to the module `l10n_generic_coa`
upon its uninstallation.
Fixes#25005
- Create the following BOM for Product A:
Comp 1: 1 Unit(s)
Comp 2: 5 Unit(s)
- Update on-hand quantity:
Comp 1: 10 Unit(s)
Comp 2: 30 Unit(s)
- Create a MO for 10 Unit(s) of A
- Check the Quantity on report 'Stock Level Forecast':
Comp 1: 0 Unit(s)
Comp 2: -20 Unit(s)
- 'Check Availability' on the MO
- Check the Quantity on report 'Stock Level Forecast':
Comp 1: 0 Unit(s)
Comp 2: 30 Unit(s)
The `partially_available` state has been added with Inventory
refactoring in v11, and needs to be taken into account.
opw-1849556
In 11.0, this change e9454e79 solved the use case of:
- opening the registration of a ticket
- discard
=> the page must be reloaded to register a ticket
A new report is that since 9.0, if we try to register 0 ticket we would
also have to reload the page.
This commit backports e9454e79 and solves the 0 ticket registration.
10.0 version of 9.0's #24966
opw-1851622
closes#24991
Before this commit, some values of res.config.settings were saved
(e.g case of website settings were some fields are related)
After this commit, they are not saved
OPW 1853230
closes#24972closes#25028
- Create a BOM for Product A, using Component B
1 Unit of a is built with 1 Unit of B
- Update on hand quantity for B to 3.0
- Create a MO for 5 Units of A
- Update the quantity to produce to 3.0
The button 'Check Availability' never disappears.
The core of the problem is that the move remains "Partially Available".
Indeed, if there is no product available (`available_quantity <= 0`),
the stock move is skipped and its availability status is not updated.
We slightly change the logic by first checking if we need any quantity.
If not, the move can be considered as assigned.
opw-1850499
The website_event_questions override EventRegistrationForm's method
on_click and expects the returns is a deferred.
This commit provides a deferred in all instances avoiding an error.
Also what was done in e9454e79 and enables back the Register Now
button if no ticket was selected.
opw-1850527
In 11.0, this change e9454e79 solved the use case of:
- opening the registration of a ticket
- discard
=> the page must be reloaded to register a ticket
A new report is that since 9.0, if we try to register 0 ticket we would
also have to reload the page.
This commit backports e9454e79 and solves the 0 ticket registration.
Also if website_event_questions was installed there was an error
preventing an error message to be displayed.
saas-15 version of 9.0's #24966
opw-1851622
closes#24967
formataddr (from the email python library) writes email_from as '"name" <email>'
in the email_from field of the mail.compose.message record.
When the mail is rendered, onchange_template_id is triggered.
This then overwrites the values of email_from among other fields.
What happens is that it uses the email_from field from the template to render
the email_from, bypassing what was put by formataddr before.
What happens in some cases is that it is rendered as 'name <email>'
(note the quotes have been stripped away).
If name contains arbitrary symbols, e.g. name = 'pépé [company] <pdg>, ohlala',
then getaddresses which is supposed to parse the (name, email) pairs gets thrown
off (in particular, <pdg> will be interpreted as an email address, and many
other problems with the various special symbols).
It then gives these wrong elements as email addresses, which will usually crash
when getting non-ascii symbols (i.e. these strings don't respect the relevant
RFC for email addresses).
Closes:
https://github.com/odoo/odoo/issues/23502https://github.com/odoo/odoo/pull/2311823118
opw 815202
opw 1824243
Before this commit:
* Module A defines a field X of model M
* Module B inherits from model M without touching field X
* Module C inherits from model M and extends field X by giving an INDEX
/ NOT NULL constraint.
* Module B and C depend from Module A, but not each other
If all three modules are installed and Module B is updated, the INDEX /
NOT NULL constraint could be dropped.
This happens because Module B can be loaded before Module C is loaded,
if that's the case, then after the upgrade of Module B, during the
schema checking, we verify that the field object we have and the field
on the DB are the same, since Module B doesn't introduce the index then
this check is false and we drop the index. When we get to loading Module
C, we do not do any schema checking because the module is not marked as
`to upgrade`, therefore the index is lost forever.
To solve this, we re-init the models that belong to the set of the intersection
between upgraded and modified models and loaded and modified models.
Fixes#24958
In 11.0, this change e9454e79 solved the use case of:
- opening the registration of a ticket
- discard
=> the page must be reloaded to register a ticket
A new report is that since 9.0, if we try to register 0 ticket we would
also have to reload the page.
This commit backports e9454e79 and solves the 0 ticket registration.
opw-1851622
closes#24966
When the carousel is activated, the following will load all variant ids
in the cache (cf. `_in_cache_without`):
```
<t t-set="variant_img" t-value="any(product.mapped('product_variant_ids.image_variant'))"/>
```
When accessing the `image` field at:
```
<div t-if="variant_img" class="..." itemprop="image" t-field="product.product_variant_id.image" t-options="..."/>
```
All variants in cache will have their image resized by the method
`_compute_images` on `product.product`. In case of a product with
hundreds of variants with images, this will take a major amount of time.
If we replace by `product[:1]`, the system uses another cache, and
doesn't fetch the image of all variants.
opw-1844783
Commit https://github.com/odoo/odoo/commit/2eb344f23b3a9daa8e7c7ddaead145a8b05b39bf changed the dependancies of l10n_fr_certification which is not acceptable on stable. Instead, the method to check is now moved in account module (to avoid duplicated) and it is called by l10n_fr_certification and account_lock module.
Module account_lock has been introduced by:
https://github.com/odoo/odoo/commit/2eb344f23b3a9daa8e7c7ddaead145a8b05b39bf
A new constrains appears on the lock dates: their must not be set
after the last day of the previous month.
Then, it breaks the test on closed period that set the lock date 'yesterday'.
Commit 5439e72a4e introduces the automatic creation of a journal
for a payment provider. However, the journal created doesn't have a
default payment method, to avoid showing it in the backend.
In the case of the eCommerce with automatic invoice creation, this
set-up returns a 500 error after an online payment. Solving the problem
is not obvious for the end-user.
The error comes from the fact that the 'Manual' payment method is not
available on the journal. We can remove this check.
opw-1853011
When adding a timesheet with a number of minute that has many
decimal (once converted into float), the planned_hours field
might be recomputed. So, it might be a rounding error during
this recomputation, making the field value change. Since this
field is tracked, a message is post in chatter (like Planned
Hours: 50 -> 50.0033333"), which is not useful ...
opw-1849693
Have a mrp.production that you cancel, and delete the finished products lines
Before this commit, the computation of the sale_name crashed because we did
an index selection on an empty recordset
After this commit, there is no crash
opw 1851217
closes#24923
(1) Before this commit, the input barcode was removed from the dom
after each scan but now we want to keep it focused to avoid to
automatically open the virtual keyboard in mobile.
This behavior will be useful in enterprise only.
Another commit will follow in this repository.
As the input is not removed anymore, we had to disable autocomplete
to hide previous entries as suggestions.
(2) We also add z-index property to avoid to click on the hidden input
located in the middle of the page.
Have a XMLReceipt with the line:
<barcode encoding="CODE39">123456789</barcode>
Print the receipt.
Before this commit, jibbrish characters were printed and also kinda 'broke'
the spacing between commands
e.g. If you add an EAN13 barcode below the code39 it would have failed to print correctly too
After this commit, everything prints correctly
OPW 1849284
ref: https://reference.epson-biz.com/modules/ref_escpos/index.php?content_id=128closes#24965
* order leave summary entries by date descending in order to ease HR
leave officers and managers daily job;
* reorder list view of summary entries and add the employee to have
more relevant information displayed;
Linked to task ID 1853352, feedback from internal use.
Because this is important. Otherwise people don't understand and begin
eating too much stuff, leading to the parking having holes because of
overweight. Also penguins. And crabs.
Linked to task ID 1853352, feedback from internal use.
In some cases, the calendar view sends a trivial domain, such as
["partner_id", "not in", []]
This is clearly not really useful, and it could hurt performances in
some cases (for example, if the partner_id field is a related on a large
table, and non stored).
This is clearly not a complete fix, but it is easy, safe and does not
hurt.
Christophe Simonis