If we create a survey and start a new session. When the session state is in
progress and If the survey creater deletes a question and participant tries to
answer the deleted question and submits it then participant will face the issue
of 'False is not in list'.
This commit will raise an usererror if the survey creater tries to delete the
question when the survey session is in progress.
sentry-4113791861
closesodoo/odoo#124769
X-original-commit: f636025fce4edda8a5f89b7161c4e9481460f03f
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Saurabh Mishra (sami) <sami@odoo.com>
Since [1] where the CSS / classes of the TourPointer was completely
redone, the pointer doesn't show up anymore in the default tip on the
configurator waiting screen.
This commit redisplays it as it appeared before.
Since [2], the classes `o_theme_install_loader` and derivatives have
been replaced. The commit thus also removes the file
`website.theme_install.scss` which is not needed anymore.
task-3358028
[1]: https://github.com/odoo/odoo/commit/3a79803
[2]: https://github.com/odoo/odoo/commit/1ff7f1eclosesodoo/odoo#124634
X-original-commit: 1569edb57e2e5adb242945557d9a64fac46fda96
Signed-off-by: Dieleman Guillaume (gdi) <gdi@odoo.com>
If applied, this commit will solve the 'NoneType' object is not iterable when
in _get_mail_attachment_from_doc function returns None.
Steps to reproduce the issue:
- Install Accounting and l10n_in_edi.
- Go to accounting -> Configuration -> Journals -> Customer Invoices
-> Advanced Settings -> Enable Electronic invoicing
- Switch company to IN Company
- Go to Account -> New invoice -> Add required fields -> Confirm -> Send & Print
sentry-4215675843
closesodoo/odoo#124346
X-original-commit: 84bcdcf6042a7d938803c95a6e0fe06f6e22aef9
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
THese are rarely intended for all users but often intended only for
employees.
account:
account.incoterms: only used within internal business models
account.journal.group: same as account.journal, add sudo in computed field
account_edi: need access to accounting objects
base_address_extended:
res.city: only employees should access address data
board: only employees uses this (old) module
crm:
crm.stage: internal users business object
hr_recruitment: employees can read
im_livechat: apply same as for the steps
l10n_ar: used on partner, not only invoices
l10n_ec: accessed only through account.move
l10n_latam: accessed on res.partner
mail:
publisher.warrenty.contract: no data, only static models
mail.channel: group_user has already his own rule
mail.group: group_user has already his own rule
mail.message.subtype: group_user has already his own rule
mail.message.all: remove, already has a portal and employee rule
partner_autocomplete: no interaction with public
project:
project.tags: only needed for project sharing
sale_management:
sale.order.option: same as sale.order
utm: employee already has write access
web_editor: test models that have nothing to do here
web_tour: only employees uses tours
website_sale:
product.ribbon: add sudo for access
base:
ir.default: only employees uses set (could probably be converted to group_system)
ir.ui.view.custom: same as ir.ui.view, add sudo when needed
report.*: portal users don't configure reports
res.users.log: create in sudo, no access needed (adapt test to use another model)
res.lang: still needed for public
closesodoo/odoo#118701
Related: odoo/enterprise#41285
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Steps:
1- Duplicate inventory operation - Delivery Order
2- Process new order with duplicate
3- Add products and try to save
Issue:
Traceback
Cause:
The ORM tries to insert a new record of stock.picking but triggers a constraint on unique(name, company_id). When creating a new transfer the name is computed from the sequence of the stock.picking.type but here when we duplicate a stock.picking.type it creates a new sequence which starts with id 1, if the there is already a transfer with uses it the constraints will be triggered. We just have to make the stock.picking.type which are duplicated use the same sequence
Solution:
Enable the copy of the sequence_id so that two ``stock.picking`` from duplicated operation types will never collide on their name.
opw-3331835
closesodoo/odoo#124666
X-original-commit: 52219871e8d8357044763375f6f5318622e9894e
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
The revision dd3f918cafebe26e5aa9dff1b2e484b7ed662140
introduced a regression:
it was no longer possible to set an icon in the import module,
and if no icon is provided,
the icon should fall back to the base module icon,
which wasn't the case either.
In this last case, it even leaded to a crash:
```
File "/home/odoo/src/14.0/odoo/odoo/addons/base/models/ir_module.py", line 251, in _get_icon_image
with tools.file_open(path, 'rb') as image_file:
File "/home/odoo/src/14.0/odoo/odoo/tools/misc.py", line 176, in file_open
return _fileopen(name, mode=mode, basedir=base, pathinfo=pathinfo, basename=basename, filter_ext=filter_ext)
File "/home/odoo/src/14.0/odoo/odoo/tools/misc.py", line 211, in _fileopen
raise ValueError("Unknown path: %s" % name)
Exception
ValueError: Unknown path: /base/static/description/icon.png
```
opw-3340652
closesodoo/odoo#124661
X-original-commit: 12ccfcf8d2ee936ec066de81c2dce2dd17348cb6
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Complement module to allow generate the PLE reports.
- Missing purchase tax groups and taxes added to complete the vendor
bills flow
- Demo data completed to has data to allow generate the PLE reports
- Document types for vendor bills completed in the data
- Method to improve the domain in document types for customer invoices
added
- Extend method to autocomplete the number on vendor bills with the
standard expected by the document type.
closesodoo/odoo#124595
X-original-commit: 821d313a5de857a4903bb35aaea49c3a35f8781e
Related: odoo/enterprise#42345
Signed-off-by: Josse Colpaert <jco@odoo.com>
currently it is only possible to define the end_date that
does not allow to prepare the program in advance.
Added the start_date property to the program model.
task-3305712
closesodoo/odoo#121193
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Current behaviour:
If you have a product with tax included, and you make a discount via
a pricelist, the `base_price` of the product in the /shop page is not
correct. (it's not the same as the one on the product page, which is
correct)
Expected behaviour:
The base price in the /shop page and on the product page should be
the same in general. Should the price with tax included before the
discount.
Steps to reproduce:
- Install eCommerce, Sales
- Settings > Display Product Prices > Tax Included
- Settings > Pricelists > Advanced price rules
- Check Settings > Comparison Price
- Create a tax of 21%
- Create a product, set it's Sale's Price to $61.98, with the tax
(tax incl = $75)
- Create a pricelist that apply to the product, give it a discount
of 20%, and apply the discount policy "Show public price &
discount to the customer".
- Go to the /shop page and search for your product, observe the
`base_price` of the product is not correct.
(refer to video in ticket for a walkthrough)
Reason for the problem:
Lack of adaptation of a fw-port in commit:
30ad33de9c320f19258974a8eb77df26480d653c
Fix:
Correct the fw-port and aggregate the conditions when applying taxes
on the base price.
Affected versions:
- saas-16.1
- saas-16.2
- saas-16.3
- master
opw-3194646
closesodoo/odoo#124649
X-original-commit: a4500d1535bbf5cff7014a29971fb2e7637e2acc
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Co-authored-by: Feyensv <vfe@odoo.com>
Before this commit, when inputting latin numbers (i.e. 0-9) with a
locale using a numbering system different than "latn" (e.g. "arab"),
the parsing failed resulting in an error.
The issue is that these locales often support both their numbering
system as well as the "latn" one. This commit makes the parsing fall
back to the "latn" system in case latin numbers are found in the input.
OPW-3316325
closesodoo/odoo#124635
X-original-commit: 12970754fc915eb181e040d3e45fc566fe310167
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Open a spreadsheet, add a data filter, filter some values,
File > Download
=> the filtered values are not exported.
Previously, we gave the exported data to the action_download_spreadsheet
action, and we created a new model based on the data. This was a problem
for data that was only exported for the xlsx in UI plugins, because this
wasn't in the exported data.
Fixed by giving the xlsx data to the action_download_spreadsheet action instead
of the data.
Odoo task 3231170
closesodoo/odoo#124617
X-original-commit: 8a7e2ecf60993c6862c8980b70e847c0e5aa2a50
Related: odoo/enterprise#42355
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Signed-off-by: Minne Adrien (adrm) <adrm@odoo.com>
Description of the issue/feature this PR addresses:
Before SII resolution 46 from 2022, the only documents for foreign vendors were 110 111, and 112.
After that, SII and accountants are indicated as a practice to issue purchase invoices (Factura
de compra 46) to foreign vendors in order to pay the vat taxes, mainly for digital services.
Current behavior before PR:
It is not allowed by validation restrictions to issue this document type to foreign vendors
Desired behavior after PR is merged:
the validation release the restriction for document type 46
closesodoo/odoo#124392
X-original-commit: ee2485fd4c4e0f1ababbc74a0e1f349d58380cff
Signed-off-by: Josse Colpaert <jco@odoo.com>
Co-authored-by: Daniel Blanco <daniel@blancomartin.cl>
Co-authored-by: José Moreno Hanshing <jose@blancomartin.cl>
Otherwise it makes whole chatter overflow on the right.
closesodoo/odoo#124618
X-original-commit: 61f47dfe74fa65fa55aa68c4a9676362511dc478
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
In [1] the order by `id ASC` has been removed from the
`_message_fetch` method. This is wrong since we want
to load the messages coming DIRECTLY after the given
id thus, this order is required.
In order to solve this issue, this commit ensures the
order of the messages returned by the `_message_fetch`
method is always in descending order as it was done
implicitly before [2].
[1]: https://github.com/odoo/odoo/pull/123664
[2]: https://github.com/odoo/odoo/pull/116666
task-3349175
closesodoo/odoo#124169
X-original-commit: 074a5fea5a7f08c7018620cb9b2b956b3a871344
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Didier Debondt (did) <did@odoo.com>
Before this commit the generic message error was shown in the payment form
instead of the server error message that did not allow the users to
understand the problem that caused it.
After this commit the server error is shown in the payment form.
closesodoo/odoo#124040
X-original-commit: dc1230648415dbeeb672c6fb9168472ac8c7d651
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Valeriya Chuprina (vchu) <vchu@odoo.com>
When the offline transaction failed, the error was raised that rollback
all the operations and the failed transaction was not traced anywhere.
With this commit the error is caught and the failed transaction can be
seen in chatter.
X-original-commit: 21e84624841690d36bd38b768e35cc61b3c6a17b
Part-of: odoo/odoo#124040
- Standard price (cost price) is there for variants and for product template when there are no
variant, as it has no sense the have one otherwise. Templates with variantS have a cost of 0.
- On the website, product shown are the product templates, but you select and then buy the product
product (variants).
- The pricelist can be set to make a discount based on the cost.
==> If such a pricelist is used, the product templates having more than 1 variant are shown with a
price of 0 until you can select the wanted variant
opw-3232621
closesodoo/odoo#124594
X-original-commit: 561eba8f2adece4c21ea46c1bd050779ea3dc676
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
Without this commit, the words in this template (below the images) won't
be colored as translated (green) / not translated (yellow).
This is because there is a block element inside an inline element and
the color is applied on the inline element which has no impact on
children blocks since inline elements don't take up available space.
See https://stackoverflow.com/a/7439861
Note that:
- `display: inline-block` is not an option either as it would be messing
with the `t-field` which receive this `data-oe-translation-state`
property too. Applying the `inline-block` style on those will break
the layout, typically on a product page.
- same for `display: contents`, it's not working as such elements don't
generate any box, properties like border / bg color etc are thus
ignored.
opw-3305117
closesodoo/odoo#124560
X-original-commit: ed89b0ffd7f4d6a04f71f474720ff4d82c9ecf9a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
TypeError: expected string or bytes-like object
This error occurs when the 'url_from' field is left empty during website rewrite
To reproduce this issue, follow these steps:
1. go to website -> configuration -> redirects
2. create a new record -> select 308 redirect / rewrite in action
3. keep 'url from' empty and put any value in 'url to' such as '/'
4. Click on the save button, and this error message will be displayed.
After applying this commit will fix this issue.
task-3346588
sentry-4229658026
closesodoo/odoo#124558
X-original-commit: 26fa923f6ab01298bf1a1e9f6a615c9aa9e2e5ed
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Currently, discardForm has some indeterministic problems during the nightly runs.
To avoid this and until the problem is solved, these tours now use the saveForm instead.
closesodoo/odoo#124544
X-original-commit: 29d6ba2716fe0067903f1b5ee480e2e03757e0f7
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
Have an employee with payment terms set in the contact form
Create an expense for $100 for the employee
Create the expense report > Submit to manager > Approve > Post journal
entries
Issue: The bill due date is manually set to the Accounting Date.
This is not consistent with the Payment terms applied on the
bill
opw-3298981
closesodoo/odoo#124542
X-original-commit: d363aa12429768e63d0f9def7006101983fd0adc
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Signed-off-by: Laurent Smet <las@odoo.com>
When user tries to import a module which does not consist of an icon and then
when user tries to access that module the error occurs.
Steps to reproduce:
1. Install web_studio.
2. Import a module(without icon) from apps > import module menu.
3. Now search that module in apps and click on module info.
4. The error will occur.
Applying this commit will fix this issue.
sentry-4206999375
closesodoo/odoo#124540
X-original-commit: 4b0221800ab75d5573e7066bf8beee14488062dd
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
With an EDI localization (MX)
Create 2+ invoices with edi attachments (xml)
In list view, select both and hit actions > send&print
Issue: EDI file will not be attached to the mail
opw-3330554
closesodoo/odoo#124446
X-original-commit: 9730a9753936f040a987505ed064cfd51acb50e0
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Signed-off-by: Laurent Smet <las@odoo.com>
This commit modifies the label of the alignment option for the
"magazine" and "hamburger-full" header. It changes the label from
"Mobile Alignment" to "Alignment" when the "hamburger type" option is
set to "off-canvas." This is because in this case, the alignment also
affects desktops.
The bug was introduced by this commit [1].
This commit also changes, for the same reason, the label of the
alignment option for the slogan header.
[1]: https://github.com/odoo/odoo/commit/3eaab4e81ea2598788c9d6757ef38bbbd6454f65
task-3254619
closesodoo/odoo#124277
X-original-commit: 5b854cb332d1cd65769427750bb2bef758176c2d
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Signed-off-by: Vray Benjamin (bvr) <bvr@odoo.com>
When you create a purchase agreement from the from view of a purchase order , it can have some invalid states which may lead to not having a vendor too.
Since choosing a purchase agreement makes the vendor read only on the PO form , then it may lead to having a PO form without a vendor and can't update it.
Steps to reproduce the error :
1- activate blanked orders
2- create a new purchase order directly from the PO form
opw-3335891
closesodoo/odoo#124528
X-original-commit: 100187e904b85306a7823c54adb78f493abacf78
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
Since commit [1], the text selection must be kept if there was one when
using a snippet option. However, it is not the case when toggling the
grid mode for snippets that have None columns (e.g. Text) or have some
content outside of their row element (e.g. Picture). Indeed, when these
contents are wrapped inside a new column and then in the row, the
selection is lost.
This commit, as done in commit [2], restores the selection after the
content wrapping. It also adds a test checking if the selection is well
kept when toggling the grid mode and going back to normal mode.
[1]: https://github.com/odoo/odoo/commit/e8112e2865ca449c4df9cd6147e9e24c4c6dcd41
[2]: https://github.com/odoo/odoo/commit/e4d7fbfca85c869d3a04dc517a8ad522cb533a90
task-3324775
closesodoo/odoo#124513
X-original-commit: bcb0e9b83fcb7e3f8a66131a089b88b39f58a2e4
Signed-off-by: Colin Louis (loco) <loco@odoo.com>
When toggling a snippet to grid mode, if it has None columns (e.g. Text)
or if it has contents located outside of the row element (e.g. Picture),
the contents are wrapped inside a column and then put inside the row.
However, after this operation, it is impossible to delete or replace the
text in this newly created column.
As mentioned in commit [1], this happens because there is an unwanted
rollback in the history, which should be prevented by resetting the
nodes unbreakable id (i.e. the `ouid` property).
This commit makes this property reset and therefore allows to delete or
replace the text after the toggle to grid mode.
[1]: https://github.com/odoo/odoo/commit/e33b802b05b41df20e13ebc44bc5b78edae50bb8
task-3324775
X-original-commit: 5bd354802a9aae9575806ad83350e0b002efa2fa
Part-of: odoo/odoo#124513
The ``stock.picking`` record doesn't have a 'mobile' or a 'phone'
field which can be used by ``sms.composer``,thus we need to return
the ``partner_id`` field instead.
opw-3286153
closesodoo/odoo#123716
X-original-commit: 35311aecef034402eac76e60acdc2658b9c681cf
Signed-off-by: Djoumatchoua Eteil Junior (etdj) <etdj@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
- Create a SMS template with the 'Applies to' property set to
Transfer (without this the action will never appear)
- Go to Transfer, pick one, open action and try to send a SMS
Issue:
Traceback
Cause:
When sending the SMS we try to modify the 'mobile' attribute of
'stock.picking' but it doesn't exist.
opw-3286153
X-original-commit: c84f952824bea4c1e0d5dcc7450d5e48a5637db8
Part-of: odoo/odoo#123716
Before this commit, the attendance and non-working days were
always based to the current calendar of the user's employee.
This is not accurate since we can see other's calendars and
contract changes can lead to calendar changes (from full-time to
part-time,...).
This commit base that view on the viewed employee contracts so that
even a contract change is correctly viewed.
task-3060722
closesodoo/odoo#121153
Related: odoo/enterprise#42125
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Current behaviour:
In the context that a variant is being archived after the removal of
one of it's attribute lines, on the e-commerce product's page of
said product some of the attribute values are disabled because they
were part of the archived variant.
Expected behaviour:
Archiving a variant due to removal of an attribute line shouldn't
disable the selection of the other attributes on the e-commerce
product's page of the product, since the variant can never be
reconstituted (the current selection of attributes lines is `X-1`,
where `X` is the number of attribute lines of the archived variant).
Steps to reproduce:
- Install eCommerce,
- Create a product with 2 attribute lines and add values A1,A2 and
B1,B2 respectively, 4 variants should be created (cross-product).
- Go on the e-commerce product's page of the product, add the
variant A2,B1 to the cart
- Go in the backend, delete attribute line (B1,B2), from the product
template
- Go back on the e-commerce product's page, the option with A2 is
disabled.
Reason for the problem:
When deleting an attribute line from a `product.template`, if one of
the variant is being used somewhere (in our case as a `sale.order.
line` of the cart), it is archived instead of deleted. This means
that when loading the page of the product with send the attribute
values of the archived products, so we can disable the selection of
the attributes that would make the archived variant. Since A2 is
part of the variant A2,B1 that was archived, we disable the
selection for A2, without taking into account that we don't have the
same number of attributes than the archived variant and it is
impossible to make the archived variant from the e-commerce
product's page.
Fix:
Restrain the condition that checks for which attributes to disable.
We make sure that we have *any* common part of the selection to the
archived variant, and we also make sure the count of the attributes
for the product is the same as the archived variant we are checking
against.
Affected versions:
- 16.0
- saas-16.1
- saas-16.2
- saas-16.3
- master
opw-3329225
closesodoo/odoo#124536
X-original-commit: 411441861a3242fddce5ffd02b09cbc5556aef90
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Issue:
When the product sold has a zero price,
it is possible to click the "Confirm Order"
button several times.
This will send several confirmation emails.
Cause:
Because the price is zero,
we do not have a widget that handles
the `disabled` attribute of the button.
This is handled by a widget
when we have the `o_payment_checkout` form,
but it is not the case when
selling a zero price product.
Solution:
Change the attribute of the submit
button when submitting the form to prevent
multiple click.
opw-3246935
closesodoo/odoo#124519
X-original-commit: 53c6ebfdf7c5acb5103bf9ef5cb7c12f92ceefb9
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Send a request to any json-rpc route with a HTTP header
`Content-Type: application/json-rpc` but send non-json or
non-jsonrpc data in the body. The application crashes with
a 500 Internal Server Error instead of a 400 Bad Request one
closes odoo/odoo#124571
Closes: #122048
X-original-commit: a1b83b07996f3fe4744474ff4023a3a2ce17ac7f
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Before this commit, when the user set a subtask and wants to directly
set the SOL of that subtask in the subtree view of a task form view. He
cannot because the field is in readonly.
This commit makes the field editable if the user has access to Sales app
as it is the case for the SOL field in the form view of task.
task-3336215
closesodoo/odoo#124563
X-original-commit: 0373abdf24e1139706e6d7610873cc89ada60e74
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Allow timesheeting on sub-tasks with no project_id set.
Instead, refer to the project_id set on its parent_id, and so on,
recursively.
task-3336215
X-original-commit: d794e41619a36a8c9ad1e77a816e57051207cdcf
Part-of: odoo/odoo#124563
This is a proposal to try to find a similar asset before generating one.
If get_attachments fails, the next step will be to generate the
attachments from scratch, a slow operations.
When creating a new website, all assetsbundle would actually be
similar to their version without website, but the url is different.
This can be visible because the first loading of /web is slow after
creating a new website: the website_id is forced in the session
and the assets_backend are regnerated, identical to the original ones.
This commit proposes to try to find an attachments with differents extra
but the same uniquifier when possible and copy it's content.
Note that just returning the other attachement url may work, but it
would be confusing to randomly have links to assets comming from another
website_id. This would also be a problem if the original attachment is
unlinked, forcing to recompute it for other websites.
Good to know, since the content is the same, no duplication of the
content should appear in the filestore, just an entry in the database.
Part-of: odoo/odoo#121376
Saurabh Mishra