When a company's annual inventory day is selected which is higher
than the number of days in that month, there are already safeguards in
the feature to ensure the latest day possible for that month is
selected. Unfortunately the related test forgot to take this into
account for leap years, so this commit modifies it to test for this
expected safeguard.
closesodoo/odoo#155987
X-original-commit: 91a6b994455b288e20c688c4e88d7d2aa5cb6f0b
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Commit 14abe7acb11 (PR #123816) introduced default tax closing accounts
for localizations that were so far missing them. However, the mechanism
for specifying the default tax closing accounts changed in 16.2: they
must now be specified on the tax groups. This was not correctly done
in the fw-port, so we fix this in this commit.
closesodoo/odoo#155911
Taskid: 3524378
X-original-commit: f522550e083af22e63d219124273b47e0fcb7bbd
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com>
This commits removes the state validation for `l10n_in_edi`
for overseas partner and now state will be only required
for e-invoicing for partner having country `India`
closesodoo/odoo#155940
X-original-commit: 209829ed6724d73c5550b911cb4225071bb7c1a3
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
Signed-off-by: Harsh Modi (hamo) <hamo@odoo.com>
Not a guaranteed fix (not reproducible 1500 attempts), but applying
standard fix for `step` failing to use the new step helper.
runbot-54560
closesodoo/odoo#155925
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
In case of exception of type KeyError during the formatting with Babel
instead to raise a Traceback, we first retry with the en_US locale.
Babel fixes each week new bug of formatting like the one in the test,
but we cannot bump our default babel version since it is not in the
stable Ubuntu 22 so it is a best effort fix that will not hide all bugs
but is better that nothing.
https://github.com/python-babel/babel/pull/827closesodoo/odoo#155909
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Since the PR [1] changed the rendering engine of qweb, the default
"selected" value set on selects field on the form snippet were lost once
the page is saved.
This commit builds upon the changes made in [this commit] by reinstating
the default "selected" value.
Steps to replicate:
- Go to Website -> Edit.
- Drop a Form snippet onto the page.
- Click on the 'Company' field.
- In Field > Type, opt for "Selection".
- Choose option 3 from the options list to establish it as the default.
- Save the modifications.
Issue: The expected default value for the selection field is not
retained after saving.
[1]: https://github.com/odoo/odoo/pull/130467
[this commit]: https://github.com/odoo/odoo/commit/b42e9cc686e7d3ccf82cd091a5dc24028fff8a2b
task-3767819
closesodoo/odoo#155838
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
When a crawler (eg Googlebot) come to visit your website, it grants you
a limited amount of time and ressources, it's called "Crawler budget".
If you have millions of URLs, it won't go through each one of them in a
single go.
The best you can help those crawler, the better. The sitemap `lastmod`
attribute, despite not being fully respected and trusted by crawlers, is
one of the way you can still try to help them.
For website.pages, it's already done. But for controllers, it's not an
easy thing to do as we have no way to automatically figure what are the
relevant records/fields to look at to know the last update date.
For instance, on the event pages, some pages content are mostly stored
inside an `ir.ui.view`, but the title, hours etc are part of the event
itself.
We can't just say "we take the last write_date of the record", it's
wrong in 2 ways:
- The first one I just explained where we wouldn't be able to easily get
all the elements part of the page rendering and would miss a possible
element write_date, leaving an outdated date in `lastmod`.
- Then, there is another issue (which is more problematic in stable):
the `write_date` is often updated for non website related purposes.
For instance, on /partners/<partner>, we wouldn't be able to use the
write date on odoo.com as the partners shown there (having a grade)
are update every weeks in average, because of many fields, for
instance: commission_plan_id, partner_weight, grade_id, ...
Still, there is a quick win possible in stable about forum posts which
are not impacted by the 2 issues explained above:
- The `write_date` doesn't seem to be updated too frequently for
(sitemap) irrelevant reasons. We can ensure to show a date which is
only modified when the forum.post page really gets a modification.
- All the forum.post information displayed on the page are stored inside
the forum.post itself.
This commit is thus adding the `lastmod` on forum.post URLs in the
sitemap in hope of not making Google waste time on (very) old posts.
Note: we don't use the `last_activity_date` as it wouldn't be updated in
case of the post `content` or `name` being modified for instance,
which would be wrong.
Some metrics: On odoo.com, out of the 83499 forum posts having a
`last_activity_date < 2023-10-01`, only 2335 have a `write_date`
after `2023-10-01`. It means that those two fields are actually
giving almost the same results.
Using `write_date` is thus the best choice: not impacted by the
issues mentioned above and cover all relevant record change, as
opposed to `last_activity_date`.
Note: the `lastmod` has to be trustworthy and correct, if you set wrong
or outdated info inside it, Google won't trust you/it anymore.
closesodoo/odoo#155197
Signed-off-by: Jérémy Kersten <jke@odoo.com>
The live chat should always be on top of other elements: some sites
that embeds it use z-index for various purposes. Currently, the live
chat does not uses z-index, thus is it can be hidden by other
elements.
This PR sets the z-index to the largest value handled by the browser.
opw-3732033
closesodoo/odoo#155903
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
On the analytic widget, when putting an Analytic Account, a floppy disk appear
on top of the wizard.
This button is used to create a new analytic distribution template. It is
confusing for users that thinks that the purpose of the button is to save the
analytic distribution.
This PR will replace the button to be a link called "New model".
Also, this pr will fill some field (partner_id, account_prefix and product_id)
if there are populated.
closesodoo/odoo#155611
Task: 3736786
X-original-commit: c44367a2f67f305052d28a3b9e313ad63ff46907
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Signed-off-by: Maximilien La Barre (malb) <malb@odoo.com>
How to reproduce:
- Install CRM with demo data
- Configure one activity type to keep done activities
- Go to CRM and chose a kanban column with a green status (only planned
activities for that state)
- On a lead of that column, add an activity of the type chosen above with a
deadline in the past
- When going back to the kanban view, that column has the overdue status (red)
- Mark that activity as done
- Reload the kanban view
The kanban column has still the status overdue (red) while there are no more
overdue activity in that state.
With this fix, after reloading the kanban view, the header displays the correct
status summary. In the example above, the kanban column header is green.
While adding test, we have noticed that the 2 methods _read_group_groupby and
_search_activity_state were computing the activity state differently leading to
inconsistency. Actually, the newly added test was failing because the
read_group was returning 2 overdue records while only one was. We correct this
here as well by using the same computation in the 2 methods.
Technical note: archived activities were returned when grouping by
activity_state because that part was done in SQL and not taking into account
the recently added active field. While adding it in the "_read_group_groupby"
method, we also add it in "_search_activity_state" to avoid the same problem
when searching on activity_state.
Task-3732333
closesodoo/odoo#153274
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, if a SelectionField was used in a kanban view
alongside the HandleField (enabling re-sequencing, i.e. drag&drop),
the "select" element couldn't be edited. This is because the d&d
feature calls preventDefault on almost all "pointerdown" events
occuring in the card, and the "pointerdown" event is the one that
opens the select.
There's no usecase in 17.0, but there's one in master, in the
product document kanban view.
We fix this in 17.0 which is the version that introduced the kanban
version of the SelectionField.
closesodoo/odoo#155827
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Before this commit, using context key `force_price_include=False` had
different interpretations in different methods
In `compute_all` its semantic was forcing the "price_include" of taxes
to be False
In `_compute_amount` it was ignored (as only value "True" was overriding
anything)
To add to this incoherence, compute_all does use
`force_price_include=False` when calling `_compute_amount`.
This commits brings semantical coherence to the `account_tax` methods by
keeping both interpretations of the context key the same: an override of
price_include, whether its value True or False.
This fixes a ticket in which the client uses that override to inverse
the computation of `price_unit` from a tax-excluded counterpart.
owp-3770871
closesodoo/odoo#155813
X-original-commit: 9b852b29e94bf0522f1b041caf12fa648ceb13c6
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Steps
-----
1. Create a loyalty card program awarding 1 point per $ spent;
2. make sure "Show points Unit" is enabled;
3. give yourself a loyalty card with 267.39 points on it;
4. create a product with a price of $0.89;
5. go to website and add it to your shopping car;
6. go to checkout.
Issue
-----
> You have 268.28000000000003 Loyalty point(s)
Cause
-----
The number comes from the `_get_real_points_for_coupon` method, which
uses `float_round` by way of `res.currency`.
The `float_round` function isn't suited for raw number display, as it
can make tiny rounding errors due to floating point arithmetic.
Solution
--------
Add a `_format_points` method to `loyalty.card` which will return a
string using the same format the `points_display` field uses.
opw-3705546
closesodoo/odoo#155652
X-original-commit: 767405a6fe8cea0407632acb57aae8bf25d8c001
Signed-off-by: Levi Siuzdak <sile@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: Victor Feyens <vfe@odoo.com>
Versions
--------
- 17.0+
Steps
-----
1. Use iOS app;
2. click on red dot on top;
3. click check in.
Issue
-----
Nothing happens.
Cause
-----
The iOS app cannot request the user's location.
Commit 1acd0b6c5d attempted to fix this by
first checking whether `navigator.geolocation` exists, but the cause
is likely with its `getCurrentPosition` method instead of its existence.
Solution
--------
Instead of checking for `navigator.geolocation`, use `isIosApp` to skip
the geolocation part when using the iOS app.
opw-3734385
closesodoo/odoo#155588
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Add a hook to prepare attachment values needed for attachments creation
during the pdf report generation
closesodoo/odoo#155518
X-original-commit: 9dd56a625f2b613a68746a80ee552bffbeb87455
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Steps to reproduce:
1. Install l10n_mx
2. Go to Accounting > Reporting > Trial balance.
3. Click the COA SAT(XML) export button.
4. Warnings are raised.
Problem: the report should work out-of-the-box on new databases.
Cause:
1. Some tags are missing on auto-generated accounts.
2. Some data were not correct and had the wrong tag. 102 accounts in particular should be debit and not credit.
This PR migrate the incorrect data and add a default naive computation of the tag on newly created accounts.
opw-3283746
closesodoo/odoo#155762
Enterprise: https://github.com/odoo/enterprise/pull/57531
X-original-commit: c7b971d5540f86f987fdaeada9481d6f46d41c49
Related: odoo/enterprise#57732
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Steps to reproduce the issue:
- have an employee with an allocation with an end date
- remove the employee's calendar
- go on his dashboard
- his remaining leaves amount is 0
This commit implements a new method on the resource mixin to fetch a calendar
for the record even though it might not have one. The default behaviour is
to fall back on the company's calendar to ensure a value.
This is overrided in the `hr_contract` module so that the calendar of the
contract is prioritized.
task-3609738
closesodoo/odoo#155753
X-original-commit: ff58269600da857e46f83d9be94049e3f8a84294
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
In case where display_name is null, the widget contact crash
- AttributeError: 'bool' object has no attribute 'split'
On odoo.com we have around 3K of partner that have name with null value.
So calling so widget Contact on linked res.users will crash since the
display name is False
closesodoo/odoo#155735
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Current behaviour
- when we access the daterange picker it was observed that the apply button
appeared flatter and was not vertically centered.
Expected behaviour
- add h-100 on buttons container to ensure they are vertically centered and no
longer appear flatter
- add close button in which action is similar to pressing ESC or clicking
outside the popover
Task-3624556
closesodoo/odoo#148812
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
*: base_import, gamification, hr_skills, mass_mailing, portal,
portal_rating, survey, web, web_editor, website, website_sale,
website_slides
The goal of this commit is to improve the accessibility of the website
pages. This has been made by implementing and correcting ARIA
(Accessible Rich Internet Applications) roles and attributes. More
precisely:
- An `aria-label` attribute has been added on progressbar elements to
avoid a warning of type `ARIA progressbar elements do not have
accessible names`. It has also been added on iframes to avoid a warning
of type `<frame> or <iframe> elements do not have a title`. Furthermore,
`aria-label` has been incorporated on some anchors to avoid a warning of
type `Links do not have a discernible name`. Finally, it has been added
on elements that have the `dialog` role to avoid a warning of type
`Elements with role="dialog" or role="alertdialog" do not have
accessible names` and on elements that have the `listbox` role to avoid
a warning of type `ARIA input fields do not have accessible names`.
- To avoid a warning of type `Some ARIA parent roles must contain
specific child roles to perform their intended accessibility functions`,
`role="menuitem"` has been added on children of menu elements. As
explained in [the menuitem role documentation], "The `menuitem` role
indicates the element is an option in a set of choices contained by a
`menu` or `menubar`". To avoid this warning, `role="presentation"` has
also been added on elements located between `tablist` and `tab` and
between `menu` and `menuitem`. Indeed, as explained in
[the presentation role documentation]; "The `presentation` role removes
an element's implicit ARIA semantics from being exposed to the
accessibility tree". The goal is to inform the assistive technologies
that the default semantics of the element should be ignored. Finally, to
avoid this same warning, the `option` role has been added on elements to
identify selections a user can make in a `listbox`.
- The `aria-label` of some elements has been adapted in order to avoid a
warning of type `Elements with visible text labels do not have matching
accessible names`.
- The value of `aria-disabled` has been corrected to `true` (instead of
`disabled`) (see [the aria-disabled documentation]).
Still to improve the accessibility of the website pages, an alternative
text (`alt`) attribute has been provided for images.
[the menuitem role documentation]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/menuitem_role
[the presentation role documentation]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/presentation_role
[the aria-disabled documentation]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-disabled#valuesclosesodoo/odoo#140453
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website_hr_recruitment
In order to improve the accessibility of the website pages, an
`aria-label` attribute has been added on some social media anchors to
avoid a warning of type `Links do not have a discernible name`. The
`options.js` file has also been adapted in order to correctly set the
`aria-label` attribute of added social media anchors.
Part-of: odoo/odoo#140453
Co-authored-by: qsm-odoo <qsm@odoo.com>
In order to improve the accessibility of the website pages, an
`aria-controls` attribute has been added on `tab` elements of the
"Accordion" snippet to avoid a warning of type `Elements with an ARIA
[role] that require children to contain a specific [role] are missing
some or all of those required children`. Indeed, as explained in
[the tab role documentation]; "An element with the `tab` role should
contain the `aria-controls` property identifying a corresponding
`tabpanel` (that has a `tabpanel` role) by that element's `id`". The
`_createIDs()` method has been adapted in order to handle the update of
the `aria-controls` attribute at the update of the `tabpanel` id.
[the tab role documentation]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/tab_role#description
Part-of: odoo/odoo#140453
The goal of this commit is to add a default meta description on website
homepage and "contact us" page in order to improve their SEO and avoid a
warning of type `Document does not have a meta description`. Of course,
it is still meant to be overridden.
Part-of: odoo/odoo#140453
The goal of this commit is to add an `aria-label` attribute on the
"extra item" anchor in order to improve the accessibility of the website
pages and avoid a warning of type `Links do not have a discernible
name`. However, as the logic responsible of the creation of this anchor
is in a non lazy loaded file, the translate function `_t()` (located in
a lazy loaded file) can not be used to translate the value of the
`aria-label` attribute. To solve the problem, this value has been put in
the `data-extra-items-toggle-aria-label` attribute on the header. The
translated value is then extracted and added in the `aria-label`
attribute at the extra items button creation.
Part-of: odoo/odoo#140453
Co-authored-by: qsm-odoo <qsm@odoo.com>
The tour isn't working if you run it on mobile mode, it gets stuck at
some points.
To fix this issue, a mobile step was added, and one trigger was edited
to work with mobile mode as well.
task-3709501
closesodoo/odoo#155789
X-original-commit: 224d3dfb9bbcc53bd2902407800b6fa88d9b8716
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Steps to reproduce:
- Go to activity view.
- Schedule an activity for one record. (Say 8 records are available)
- Schedule an activity for the second time. (Again 8 records are available)
- Try to schedule an activity for the 3rd time. (Only 2 records are available)
Issue:
Since 7682286, the existing props of activity model are being passed as params
while scheduling an activity. Currently, `["activity_ids", "!=", false]` is
being pushed to the domain of activity model in order to display only those
records on which activities have been set. As a result, after you schedule
activities more than once, `["activity_ids", "!=", false]` domain gets applied
and the list of records available for scheduling activity is restricted from
the third time onwards.
Fix:
This commit passes the props from searchModel as params to the 'load' method
while scheduling activity, instead of existing props, to ensure that the
existing params are applied as well as all records are accessible for
scheduling an activity, in `searchCreateDialog`
(i.e.["activity_ids", "!=", false] condition is not added as domain).
Task : 3721750
closesodoo/odoo#155700
X-original-commit: 339df084567206cff8a5487bbe9dec249671244a
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Khushi Patel (khpa) <khpa@odoo.com>
**Current behavior:**
Trying to access the mobile order menu for a pos restaurant
with some non-default landing page images as a non-admin user
will result in an access error.
**Expected behavior:**
The images should load on this page for anyone who has a valid
access token for the page route.
**Steps to reproduce:**
1. Make a restaurant in the POS application
2. Enable mobile ordering and set a database user with `user`
level access to the POS app to be the default user for
this newly created restaurant
3. Upload a splash image for the restaurant
3. On the POS dashboard, select the three vertical dot button
on the restaurant -> `Mobile Menu` to get the access error
**Cause of the issue:**
The default user on the restaurant POS will not necessarily
have access rights to the `ir.attachment` model/records.
**Fix:**
Get the images as sudo()- IMO there isn't a reason these should
be inaccessible to anybody considering they are intended to be
seen on the landing page by people trying to order.
opw-3748314
closesodoo/odoo#155589
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Steps to reproduce:
- Create an invoice and confirm it
- reset to draft
- change the account of an aml (product sales -> asset)
-> on the log note you will see the detail of the modification `Account: 400000 Product Sales -> 101000 Current Assets`
- connect with Demo
- go on the same invoice
Issue:
You will not see the details of the aml account change
This is problematic since Accountant and auditors should be able to see it.
Cause:
Sub-model tracking is not supported. Although we override this constraint in accounting (refer to https://github.com/odoo/odoo/blob/f56de22f10d09e6e34b25cbff04bbb6bf0823e54/addons/account/models/account_move.py#L5058-L5071), it remains inaccessible for users other than base.system. This is because we attempt to locate the account_id field on the model account.move defined in tracking.mail_message_id.
opw-3632295
closesodoo/odoo#155034
X-original-commit: 20f00a73cb280fd9a3636122c4a8a316abcee0d0
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Steps:
- In employee form
- Open studio
- Remove "Work Information" tab
Actual result:
- Traceback due to invalid xpath expression
- Invalid xpath due to duplicated name for a node
Expected result
- Tab is removed without traceback
opw-3754375
odoo/odoo@8e14972830closesodoo/odoo#154891
X-original-commit: 950e9f89ed9c37097c6d929638eb339e0467851c
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Signed-off-by: Gaetan Vanden Bergh (gavb) <gavb@odoo.com>
Steps to reproduce:
- Install Accounting and l10n_ar
- Create 2 companies located in Argentina (e.g. Company A & Company B)
- Switch to Company A
- Go to Accounting settings
- Set Fiscal Localization to Argentina
(e.g. Argentina - Argentine Generic Chart of Accounts for Excempt individuals)
- Switch to Company B
- Go to Accounting settings
- Set Fiscal Localization to the same Fiscal Localization than Company A
(i.e. Argentina - Argentine Generic Chart of Accounts for Excempt individuals)
- Try to install "l10n_ar_withholding" module
Issue:
A User Error is raised:
"Incompatible companies on records:
- 'account.tax.repartition.line,1230' belongs to company 'Company A' and 'Account' (account_id: '1.1.4.03.020 SUSS Withholding incurred') belongs to another company.
- 'account.tax.repartition.line,1232' belongs to company 'Company A' and 'Account' (account_id: '1.1.4.03.020 SUSS Withholding incurred') belongs to another company.
- 'account.tax.repartition.line,1234' belongs to company 'Company A' and 'Account' (account_id: '1.1.4.05.030 Withholdings of Profits incurred') belongs to another company.
- 'account.tax.repartition.line,1236' belongs to company 'Company A' and 'Account' (account_id: '1.1.4.05.030 Withholdings of Profits incurred') belongs to another company."
Cause:
When installing "l10n_ar_withholding" module, each Argentine company is updated
with some tax data.
These data are "generic" (not linked to any company) and used for each company,
but some treatment is performed on them by the first Argentine company, linking them
to the account ids of that company.
The following companies are then updated with data linked to the first company.
Solution:
Compute the data for each company.
opw-3709819
closesodoo/odoo#154219
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
This commit resolves the accessibility issue where the search field
located within the header was not navigable (see [1]) via keyboard
tabbing, rendering it inaccessible to users relying on keyboard
navigation.
This fix ensures that users can seamlessly navigate to the search field
in the header using the keyboard, thereby enhancing the overall
accessibility and usability of the website.
[1]: https://github.com/odoo/odoo/commit/ac5866a059c345480e246b558eeae1e94aead822
task-3607481
closesodoo/odoo#153197
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Steps to reproduce:
[account, iap credit]
- create a new invoice
- start to write "test" for the partner
Issue:
The partner autocomplete is not displayed
Cause:
in #150106 we add a condition for the quickCreate bypassing the possibility of having createEdit set to true
opw-3698400
closesodoo/odoo#155781
X-original-commit: 5f342b816c16fbbaefdb61d8bfac8376132dbfeb
Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
To reproduce:
============
- on Planning create new shift
- select a template
- change the end date
-> the end date is reset to the template value
Problem:
========
- `end_datetime` and `start_datetime` have the same compute method
- `template_id` depends on `start_datetime` and `end_datetime`
- so changing `end_datetime` triggers the compute method of `template_id`
that will read `start_datetime`
- reading `start_datetime` triggers the compute method of `end_datetime`,
that will check if `template_id` is set and if so, will take its values
-------
why the compute method of `end_datetime` is triggered ? :
-------
- `start_datetime` is not protected from recomputing, at this
line : https://github.com/odoo/odoo/blob/saas-16.3/odoo/models.py#L6746
we only protect the fields sent by frontend (only `end_datetime`)
- frontend doesn't send `start_datetime` as it was not changed
Solution
========
as ORM fix can't be made in stable, we send `start_datetime` in the `onchange`
query even if it's unchanged to make sure both fields are protected
opw-3693206
closesodoo/odoo#155705
X-original-commit: 7081372e721387da983621b3dd2986ae0872e4c8
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Abdelouahab Laaroussi (abla) <abla@odoo.com>
Before this PR, the `bus subscription is refreshed when channel is
left` test was sometimes failing. This actually reveals a real issue:
if a channel is joined a leave very quickly, the bus subscription is
not updated.
This occurs because we rely on the last subscription made and the one
that should be made to detect if channels differ. Since the
`updateBusSubscription` method is debounced, we can miss information.
This PR replaces the complicated `updateBusSubscription` method by a
`onAdd/onDelete`. This is much more reliable and more efficient since
there is no need to walk through every channel to detect changes.
This PR also remove a test that was redundant that the failing one.
fixes runbot-55292,57645,56232
closesodoo/odoo#155720
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
PURPOSE
Mail: add tests for MailTemplate send_mail
Several flows use MailTemplate.send_mail() in batch, notably event email
scheduler which sends emails to event attendee in batch. This commit adds
tests around 'send_mail' method of MailTemplate model
* add tests for batch: it is currently not supported hence using a loop but
batch is going to be added soon, allowing to test the batch version works
as intended;
* add query counters, notably for batch mode and when dynamic reports are
involved in templates;
Event: improve mail scheduler tests
Make them easier to improve and modify
* use a dedicated setup (allowing to add specific unit tests on test data);
* move initial asserts into its own unit test (to keep other tests shorter);
* use available mocks for freezetime and sql.now;
Then add tests for registration emails, to check what happens for communication
scheduled right at registration time.
LINKS
Part of Task-3764894: Event: Allow using cron triggers for communication
Part of Task-3764891: Mail: Batch-ize MailTemplate send_mail
Part of Task-3164278: Mail: Batch send: ensure limit, avoid force
Part of Task-3084943: Event: Improve communication scheduler scalability
closesodoo/odoo#155717
Related: odoo/enterprise#57731
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Make them easier to improve and modify
* use a dedicated setup (allowing to add specific unit tests on test data);
* move initial asserts into its own unit test (to keep other tests shorter);
* use available mocks for freezetime and sql.now;
Then add tests for registration emails, to check what happens for communication
scheduled right at registration time.
Task-3084943: Event: Improve communication scheduler scalability
Part-of: odoo/odoo#155717
Co-authored-by: Stéphane Debauche <std@odoo.com>
They fail at least in local as we don't patch env.cr.now. Forcing 'create_date'
is possible, but we now have a tool 'mock_datetime_and_now' mocking both
the cursor 'now' and use freeze_time for other datetime mock. It makes tests
more reproducible and less ORM-dependent when trying to manipulate creation
date.
Task-3084943: Event: Improve communication scheduler scalability
Part-of: odoo/odoo#155717
Co-authored-by: Stéphane Debauche <std@odoo.com>
Several flows use MailTemplate.send_mail() in batch, notably event email
scheduler which sends emails to event attendee in batch. This commit adds
tests around 'send_mail' method of MailTemplate model
* add tests for batch: it is currently not supported hence using a loop but
batch is going to be added soon, allowing to test the batch version works
as intended;
* add query counters, notably for batch mode and when dynamic reports are
involved in templates;
Task-3764891: Mail: Batch-ize MailTemplate send_mail
Part of Task-3084943: Event: Improve communication scheduler scalability
Part-of: odoo/odoo#155717
Co-authored-by: Stéphane Debauche <std@odoo.com>
Before this commit, if a tax had multiple distribution lines, the
base amount was calculated for each line. This resulted in the base
amount being multiplied by the number of distribution lines. This issue
has been resolved by ensuring the base amount is counted only once for
each tax and line.
opw-3696800
closesodoo/odoo#155690
X-original-commit: f8842269cee1df62ff4378473dc59da6fca7eec5
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1”:
- Tracked by “SN”
- Update the qty to 1 in “WH/stock” with “SN1”
- Create an internal transfer:
- Location: wh/Stock
- Dest location: wh2/stock
- Mark as todo
- Try to select SN1 in the `stock.move`
Problem:
A warning is triggered:
`Existing Serial numbers. Please correct the serial numbers encoded:
(001) exists in location WH/Stock`
We do a search to find all the quants in every location to verify if
the same serial number is not being used, but we do not exclude the
source location.
opw-3734300
closesodoo/odoo#155651
X-original-commit: c6e5b2b4c98f702f9108e75bdc669397ae5e0081
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Before this commit, it was possible to capture an order twice due to
the rounding difference in quantity, especially when users use a scale.
With this commit, it uses a more relaxed condition and remove the
quantity from the orderline comparison. Given that the system checks
the payments and with the same product and price units, it's unlikely
that two orders will have the same payment amount.
opw-3735436
closesodoo/odoo#155612
X-original-commit: 9f1f8fcd272005eb2cba4bf6feee0ea0b2f2609f
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
How to reproduce:
- Install hr with demo data
- Create a user without access to hr and turn it into an employee
- Create a user for Abigail
- Assign Abigail as manager of the new user
- Click on "onboarding plan" in the chatter of the new user
- Then in the dialog, click on "Schedule" button
You get the error "Assigned user test has no access to the document and is not
able to handle this activity." because the new user has no access to the record
employee on which those activities are scheduled.
As activities for which the user has no access to the underlying record are now
displayed in the systray (with no access to the record), we remove the check
that prevent assigning an activity to a user on a record he has no access to.
Technical note: before odoo/odoo#149965, activities scheduled manually were
created with the flag "automated" set to True and when this flag is set the
check that ensures that the user has access to the record is skipped. With
odoo/odoo#149965, as the "automated" flag is set to False when scheduling
activities manually, an error is trigerred if the user has no access to the
underlying record. Here we always skip that test and mark the method as
deprecated because the user can see the activity no matter the access he has on
the underlying record.
Task-3598836
closesodoo/odoo#155576
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit makes the CIUS-RO e-invoice emitted by a Romanian company
without VAT number compliant with the CIUS-RO requirements.
The validator for CIUS-RO (which extends the validations from the BIS3
Schematron) asserts a rule `[BR-CO-09]` where:
if the PartyTaxScheme/TaxScheme/ID == 'VAT',
CompanyID must start with a country code prefix.
In Romania however, there are multiple types of "Tax IDs", and it is perfectly
valid in Romania to have a Tax ID without RO (country code prefix) in front of
them. They are not a subject to paying VAT, and it should still be possible to
generate CIUS-RO XML with their tax identifications.
We have to handle their cases by changing the TaxScheme/ID to 'something other
than VAT', preventing the trigger of the rule and allow Romanian companies
without prefixed VAT to use CIUS-RO.
```xml
<rule context="//cac:PartyTaxScheme[cac:TaxScheme/normalize-space(upper-case(cbc:ID))='VAT']">
<assert id="BR-CO-09" flag="fatal" test="( contains( ' 1A AD AE AF AG AI AL AM AO AQ AR AS AT AU AW AX AZ BA BB BD BE BF BG BH BI BJ BL BM BN BO BQ BR BS BT BV BW BY BZ CA CC CD CF CG CH CI CK CL CM CN CO CR CU CV CW CX CY CZ DE DJ DK DM DO DZ EC EE EG EH EL ER ES ET FI FJ FK FM FO FR GA GB GD GE GF GG GH GI GL GM GN GP GQ GR GS GT GU GW GY HK HM HN HR HT HU ID IE IL IM IN IO IQ IR IS IT JE JM JO JP KE KG KH KI KM KN KP KR KW KY KZ LA LB LC LI LK LR LS LT LU LV LY MA MC MD ME MF MG MH MK ML MM MN MO MP MQ MR MS MT MU MV MW MX MY MZ NA NC NE NF NG NI NL NO NP NR NU NZ OM PA PE PF PG PH PK PL PM PN PR PS PT PW PY QA RE RO RS RU RW SA SB SC SD SE SG SH SI SJ SK SL SM SN SO SR SS ST SV SX SY SZ TC TD TF TG TH TJ TK TL TM TN TO TR TT TV TW TZ UA UG UM US UY UZ VA VC VE VG VI VN VU WF WS XI YE YT ZA ZM ZW ',substring(cbc:CompanyID,1,2) ) )">[BR-CO-09]-The Seller VAT identifier (BT-31), the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48) shall have a prefix in accordance with ISO code ISO 3166-1 alpha-2 by which the country of issue may be identified. Nevertheless, Greece may use the prefix ‘EL’.</assert>
</rule>
```
This commit also fixes and clean some of the irrelevant constraints and tests
previously written in `l10n_ro_edi`.
closesodoo/odoo#155252
Task-id: 3649426
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Before this commit, in a grouped kanban view with progressbars
and an aggregate field, after clicking on a bar to filter
records, the aggregate value was always 0 (at least when grouped
by a many2one or date(time) field).
This was due to a mismatch when trying to find the value of the
aggregate in the web_read_group result, as when grouped by a date
or datetime field, the key is `fieldname:granularity`, and we were
looking for the fieldname only. And for the many2one case, we were
comparing a pair [id, display_name] with an id.
This commit fixes the issue. It also fixes the mocked version of
read_progress_bar in the MockServer, s.t. we can correctly
reproduce the scenario in tests, as in the previous version, keys
in the returned object weren't computed the same way as in the real
read_progress_bar (e.g., "14,Mitchel", instead of "Mitchel"). A
similar fix has been done in [1]. This allows us to introduce a
test when grouped by many2one, which doesn't work as of 17.0.
[1] fd759f18d056844c486a68d0c394df5a03e789f0
closesodoo/odoo#155701
X-original-commit: 69b1809ed763d03560983bb0e4c996946dd694c5
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
PURPOSE
=======
The survey addon assets contain some global rules for print mode, that
are present in the global backend stack.
In Odoo 15.2, we put these rules in `survey_templates_results.scss`.
Then, in later versions of Odoo we updated it wih more 'print mode'
global rules.
As these rules are specific to the survey addon, we don't want them to
affect the (whole) Odoo backend.
HOW TO FIX
==========
It seems rules defined in `survey_templates_results.scss` are not
used in survey backend views, but specific to frontend views.
`survey_templates_results.scss` is also part of the
`survey.survey_assets` bundle. This bundle is loaded only for the
following frontend views:
- Survey: main page (take survey)
- Survey: custom 403 page
- Survey: void content
- Survey: login required
- Survey: expired
- Survey: Access Code page
- Survey: print page
- Survey: result statistics page
Among them, views that are not intended to be printed are not
negatively impacted by the css rules for print mode.
A solution would therefore be to remove
`survey_templates_results.scss` from the backend stack.
see 0364161
see #135683
see #146812
task-3666858
closesodoo/odoo#155126
X-original-commit: aba4b503b60b42c91191436491205a0c7575ecbd
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Tiffany Chang (tic)