- Jun 25, 2023
-
-
Odoo Translation Bot authored
-
- Jun 24, 2023
-
-
Denis Ledoux authored
Revision odoo/odoo@cabb9e7e573b86cd523980588360d8514090d370 introduced a regression: This is no longer possible to import a data module using `<field file="..."/>` in their data file. This revision targets to restore the feature as expected. The unit tests added covers the feature, so that regression no longer happens in the future. It introduces a new concept of temporary directory `file_open` can read from. e.g. ```py with odoo.tools.file_open_temporary_directory(self.env) as module_dir: with zipfile.ZipFile('foo.zip', "r") as z: z.extract('foo/__manifest__.py', module_dir) with odoo.tools.file_open('foo/__manifest__.py', env=self.env) as f: manifest = f.read() ``` Note that `file_open` will be allowed to read from that temporary directory only if `env` is passed to `file_open`, and if the `env` is part of the same transaction/request than the `env` passed to `file_open_temporary_directory`. This is to avoid having users, whether from other databases, or even the same database, trying to access these directories not belonging to them. e.g. If an admin uploads sensitive data in this temporary directory, no one than him must be allowed to read from these files, not even another user from his database. closes odoo/odoo#126278 closes odoo/odoo#126337 Signed-off-by:
Denis Ledoux (dle) <dle@odoo.com>
-
- Jun 23, 2023
-
-
Julien Van Roy authored
When parsing an email containing an xml attachment, the `email` python module will decode the base64 attachment using the charset or ascii if the charset is missing. In some cases, the payload is in UTF-8 but the charset is omitted. This results in replacement characters for the non ASCII characters. The solution is to force the charset to UTF-8, since it is a superset of ASCII that should not be a problem. NB1: Omitting the charset for text/xml is not recommended. See the RFC (section 6.4): https://www.ietf.org/rfc/rfc2376.txt opw-3144519 closes odoo/odoo#125628 Signed-off-by:
Julien Castiaux (juc) <juc@odoo.com>
-
Yolann Sabaux authored
Steps to reproduce: - Install the lux localization - Configure Peppol for a customer: Select a customer > tab accounting > under "electronic invoicing": format: Peppol BIS Billing 3.0 Peppol e-address: 0130 - Directorates of the European Commission Peppol Endpont: testendpoint - Create an invoice for the peppol customer - Add a section or a note in the Invoice - Confirm the Invoice Issue: Raise user error: Odoo requires a tax for EACH LINE, instead of each product Solution: Exclude the section/note line opw-3354757 closes odoo/odoo#124806 Signed-off-by:
Laurent Smet (las) <las@odoo.com>
-
Julien Van Roy authored
Currently, it's not possible to check the 'Peppol Bis 3' option on the journals of Italian companies, since Italy is not present in our mapping `COUNTRY_EAS`. The EAS for Italian companies may be the codice fiscal (code: 0210) or the VAT number (code: 0211). See https://peppol.agid.gov.it/en/news/expiration-validity-codes/ Use the VAT number by default, and add it in our mapping such that the option now appears for Italian companies. opw-3346572 closes odoo/odoo#126168 Signed-off-by:
Florian Gilbert (flg) <flg@odoo.com>
-
Mohit Beniwal authored
JSONDecoderError occurs when users enters invalid JSON format data in 'Default Value' field inside 'User-defined Defaults' and wherever this field is being accessed to get default value this traceback will be generated. Steps to reproduce: 1) Install 'Contacts' module. 2) Open 'Settings' > 'Technical' > 'User-defined Defaults'. 3) Click on record 'Language' > 'EDIT' button > in 'Default Value' field enter any improper JSON format data (e.g 'Maa' : FI ) . 4) Now, open 'Contacts' module > click on 'CREATE' button and traceback would be generated. By applying this, it will check for proper JSON format. Sentry-4169062951 closes odoo/odoo#124051 Signed-off-by:
Rémy Voet (ryv) <ryv@odoo.com>
-
Enric Tobella authored
closes odoo/odoo#105495 Signed-off-by:
William Henrotin (whe) <whe@odoo.com>
-
Guillaume (gdi) authored
When a user creates a link that is tracked, an interface with graphs is presented to him so that he can track the performance of his tracked link. Unfortunately, these graphs did not work when the site was in a foreign language. This was due to the fact that the code had not been designed to handle this. This commit fixes the code so that it works in all languages. Note that the data is received via RPC and the python code format the dates for the current language of the website. So we had to do a little hack to make it work properly. Steps to reproduce the issue: - Install website_links module - Go to the website app - Click on Promote > Link Tracker - Create a tracked link - Visit the link - Install Arabic (Syria) for your website - Check the stats of your link in Arabic => There is a traceback and the data is not displayed. task-3289167 closes odoo/odoo#119375 Signed-off-by:
Outagant Mehdi (mou) <mou@odoo.com>
-
- Jun 22, 2023
-
-
Benoit Socias authored
This commit ensures that the unsplash beacon calls home when an unsplash image appears on a page. To achieve this it patches the RPC call when the test URL contains the test name as parameter. The patch cancels the actual beacon call to avoid polluting data during the test, but marks the image as having had its beacon message sent. The test then simply checks if this marker appears on the image. task-3360109 closes odoo/odoo#125028 Signed-off-by:
Outagant Mehdi (mou) <mou@odoo.com>
-
Saurabh Choraria authored
In the start_sync method, the logger is updated to use the 'warning' level instead of the 'error' level. This change reflects a less severe logging level for cases where sending a partner to sync fails. The changes have been made to reduce the noise level in the sentry. sentry-3955309841 closes odoo/odoo#123827 Signed-off-by:
Louis Baudoux (lba) <lba@odoo.com>
-
- Jun 21, 2023
-
-
Matheus Leal Viana (malv) authored
Some account terms are mistranslated, this PR aims to fix these translations. The customer provided a table with the mistakes and suggestions. The customer’s suggestions are available in the ticket. How to reproduce: 1. Ukrainian translation > chart of accounts > some terms are mistranslated closes odoo/odoo#125747 Opw: 3247005 Signed-off-by:
Josse Colpaert <jco@odoo.com>
-
Jinjiu Liu authored
Reproduction: 1. Install Event, Sales, Webiste 2. Login as Admin, go to Website -> Go to website -> Events 3. Click the Open wood event, Register, buy one VIP ticket 4. In Address step, Edit the billing address, change the name to “Test Name”, click next 5. The user name “Mitchell Admin” is changed to “Test Name”, we shouldn’t be able to change the info Reason: In the fix to block name change here: https://github.com/odoo/odoo/commit/d823033ad67702b1b92d27a3f66c7a4ec304c644 we use the can_edit_vat to check if we have existing invoice(s) or SO(s). However, we should block the route that an employee changes the billing address when placing an order. If they are placing an order for external people, it should be done from the back end. Fix: add an extra error case when it's an employee trying to change the name or email address when editing billing address. This is the case when an employee tries to order for external people. They should do it from the back end. They can still buy for themselves without changing the billing address. Also added translation in pot. Edited the test for editing address of log in user, added tests for portal user. Reformat the invoice exsits check for name change to have better readability In website, add render on MockRequest that return a supported type (string e.g.) The adding of can_edit_vat: https://github.com/odoo/odoo/commit/f8b05f52f5ea7f31135f700b0e240ff563204085 Related fix to block the name change: https://github.com/odoo/odoo/commit/d823033ad67702b1b92d27a3f66c7a4ec304c644 A patch to not block the checkout process when name is not set: https://github.com/odoo/odoo/commit/781dbeaccac76a6ec4f4b8cac1b607810697e394 opw-3126325 closes odoo/odoo#111708 Signed-off-by:
Antoine Vandevenne (anv) <anv@odoo.com> Co-authored-by:
Jeremy Kersten <jke@odoo.com> Co-authored-by:
Antoine Vandevenne (anv) <anv@odoo.com>
-
Francesco Ballerini authored
This commit fixes a simple SyntaxError on `website_ribbon_id` options attribute on view `product_template_form_view` of `website_sale` module. It doesn't seem to cause issues on module update, but it's a common syntax mistake which should be fixed. closes odoo/odoo#125715 Signed-off-by:
Antoine Vandevenne (anv) <anv@odoo.com>
-
paso-odoo authored
If the user change a location type of the 'Production' from inventory locations and installs the 'MRP' module, the traceback will appear. Steps to produce: - Install Stock module. - Inventory > Configuration > Settings > enable the Storage Locations. - Inventory > Configuration > Locations > Remove the filter 'Internal'. - Open the 'Production' location and change the Location Type to 'View'. - Now install the 'Manufacturing' module. Error: A traceback appears: 'ParseError: while parsing /home/odoo/src/odoo/saas-16.2/addons/mrp/data/mrp_data.xml:17, somewhere inside' At the time of installing the MRP module, it will search for the production location using the location type as the production here - https://github.com/odoo/odoo/blob/f65a9bffe2cbc03b2efc969dc205c9ba01ee9ab5/addons/mrp/models/stock_warehouse.py#L65 If the production location is not found it will raise an userError. In this commit, the production location is created based on the company if not found. It will lead to the above traceback. sentry-4215564628 closes odoo/odoo#125143 Signed-off-by:
William Henrotin (whe) <whe@odoo.com>
-
Thomas Lefebvre (thle) authored
Issue: ------ The "Launch Plan" button appears for an archived employee. It causes a traceback. Solution: --------- Do not display the button for an archived employee. opw-3366815 closes odoo/odoo#125616 Signed-off-by:
Kevin Baptiste <kba@odoo.com>
-
Florian Charlier authored
Post counts were not updated when a post was created or deleted because of missing dependencies in the _compute. Note that while "active_test" is included when counting without specifying it, the field must be explicitly added to the `_compute`'s dependency list to trigger it. Task-3358143 closes odoo/odoo#124234 Signed-off-by:
Stéphane Debauche (std) <std@odoo.com>
-
- Jun 20, 2023
-
-
Christophe Monniez authored
The Debian package is replacing some fonts by a soft link to the Debian packaged ones. The glyphicons-halfings were for bootstrap 3.x which is not used anymore in Odoo, resulting in harmless broken links in the Debian package. Closes odoo/docker#453 closes odoo/odoo#125773 Signed-off-by:
Christophe Monniez (moc) <moc@odoo.com>
-
Saurabh Choraria authored
When the user will not get an HTTP response as 200 while retrieving the location using OpenStreetMap Nominatim service, the logger error will occur. The logger is updated to use the 'warning' level instead of the 'error' level. This change reflects a less severe logging level for cases where a request to OpenStreetMap fails. sentry-4151622143 closes odoo/odoo#124393 Signed-off-by:
Julien Castiaux (juc) <juc@odoo.com>
-
- Jun 19, 2023
-
-
Romain Derie authored
We have introduced a new tag `website_nightly` which is linked to a custom build on the nightly. It has been introduced with this commit [1]. The goal is to extract the `external` tagged tests linked to the website app to another special build linked to the website team. Otherwise, we would not see when the test fail, as the `external` build of the nightly is always red and we don't check why all the time. Encapsulating this in a new build and linking to our team means that whenever the test fail in a nightly, we will be visually warned on the runbot homepage by a red warning, see screenshot on the PR of this commit. Sadly, before 16.4, as there is not yet `website_nightly` tours, the build is considered failed, showing the error. Another solution would have been to somehow disable this tour on Odoo versions < 16.4 but it we opted for this solution as: - It's simpler, no need to add yet another custom stuff in runbot - It will work out of the box should be introduce such a test in those versions: we won't need to ask runbot to activate the test in another version, should we even think about it.. [1]: https://github.com/odoo/odoo/commit/a0d0afb20594aa103eb1d0476d53012b9821e861 closes odoo/odoo#125662 Signed-off-by:
Xavier Dollé (xdo) <xdo@odoo.com>
-
mega-odoo authored
'replace() argument 1 must be str, not bool' is generated if the user edit a float or monetary section in the website view. Steps to Reproduce - Make debugger mode ON. - Go to Settings > Translations > Languages. - Remove the value of the 'Thousands Separator' field from the current user language. - Install the 'eCommerce' module. - Go to the website. - Go to the shop menu, and click any product from the product list. - Click on the Edit button and try to edit any float or monetary section like a product price (eg. change a product price from 750 to 70) and click on the Save button. And traceback will be generated. Applying this commit will resolve this issue. sentry-4148693017 closes odoo/odoo#124245 Signed-off-by:
David Monjoie (dmo) <dmo@odoo.com>
-
- Jun 18, 2023
-
-
Hubert Van de Walle (huvw) authored
Steps to reproduce ================== - On Chrome for Android, create an invoice with an amount of 0 - Save and confirm it - Click on "Customer Preview" - Go back - Click on "Action" > "Create invoice" > "Regular Invoice" - Click on "Create and view invoice" A User Error should appear Cause of the issue ================== When clicking on "Customer Preview", the crashManager was disabled When going back on some mobile browsers, instance of reloading the page, the same odoo instance is kept, and thus the crashManager is still disabled. opw-3166451 closes odoo/odoo#125239 Signed-off-by:
Géry Debongnie <ged@odoo.com>
-
Odoo Translation Bot authored
-
- Jun 16, 2023
-
-
John Laterre (jol) authored
This reverts commit 7b433492. There is a legal requirement in Switzerland that justifies ignoring the generic `display_qr_code` field. Confirmed with an accounting PO. closes odoo/odoo#125413 Signed-off-by:
Florian Gilbert (flg) <flg@odoo.com>
-
Florent de Labarre authored
By RPC an other user in other company can access to an other fec. closes odoo/odoo#115958 Signed-off-by:
Olivier Colson (oco) <oco@odoo.com>
-
Yolann Sabaux authored
closes odoo/odoo#124135 Signed-off-by:
Laurent Smet <las@odoo.com>
-
- Jun 15, 2023
-
-
Julien Van Roy authored
Issue: the xml declaration "<?xml version='1.0' encoding='UTF-8'?>" is lost when opening the send & print wizard with existing xml attachments. Explanation: When opening the send and print wizard, the PDF are generated and postprocessed by `_postprocess_pdf_report`. In the `_postprocess_pdf_report` override in `account_edi_ubl_cii`, the xml attachments are parsed through `tree = etree.fromstring(xml)`, then the base64 PDF is inserted, and the etree is converted to a bytes through `etree.tostring(cleanup_xml_node(tree))` and the resulting bytes is written back on the attachment, but the xml declaration disappeared. Solution: include the arguments `xml_declaration=True, encoding='UTF-8'` in the `tostring` function when converting the etree to a bytes. opw-3144519 closes odoo/odoo#125223 Signed-off-by:
Laurent Smet <las@odoo.com>
-
Arthur Detroux (ard) authored
Ever since iOS 16.4, going back and forth through a website with the cache enabled, creates an error in the console which Odoo tries to handle but fails to do so. Therefor a generic CORS error message appears. There is unfortunately no proper way to fix this bug on our end so instead, this commit tries to mitigate the error by returning early and not showing the traceback dialog. I (ARD) have submitted a feedback through Apple's Feedback Assistant app and will subsequently remove this commit when Apple releases an update that fixes this. opw-3281727 closes odoo/odoo#124828 Signed-off-by:
Romain Derie (rde) <rde@odoo.com>
-
Arthur Detroux (ard) authored
Prior to this commit, when using the "Slide Hover" reveal effect on the footer, Safari would glitch it scrolls and could result in unreadable content. This commit fixes this by a weird hack that seems to work. Adding an element with a background-image and a background-attachment set to fixed seems to resolve the issue. task-3302302 closes odoo/odoo#122029 Signed-off-by:
Dieleman Guillaume (gdi) <gdi@odoo.com>
-
Antoine Dupuis (andu) authored
When creating an invoice with a positive line and a negative line, with different taxes, the DatiRiepilogo node for the tax of the negative line contained positive amounts when they should be negative. This is because we were applying `abs()` too naively in the XML template and in the code of _l10n_it_edi_prepare_fatturapa_tax_details. This bugfix commit changes the logic to no longer use abs(). We also include a test to check that the XML is correctly generated for credit notes. Back-port of #121933 opw-3316300 closes odoo/odoo#122928 Signed-off-by:
Josse Colpaert <jco@odoo.com>
-
flvr-odoo authored
This commit fixes the malformed comment that would sometimes comment out the rest of the html resulting in an improper display. this is due to the new html5 notation --!> not behing understood by our parser. this commit replaces any --!> into -->. this commit also remove <!--> or <!---> opw-2812488 closes odoo/odoo#123041 Signed-off-by:
Vranckx Florian (flvr) <flvr@odoo.com>
-
Mayurrajsinh Rathod authored
Before this commit: Duplicating the contact that is linked to an attendee of a course also creates a copy of an attendee as well. After this commit: It does not create duplicate attendee in course. Task-3253983 closes odoo/odoo#118015 Signed-off-by:
Thibault Delavallee (tde) <tde@openerp.com>
-
- Jun 14, 2023
-
-
Robin Lejeune (role) authored
The triangle pointing towards an option in the editor is pointing right. In a RTL setting, this does not make sense and should be mirrored. task-3284274 closes odoo/odoo#120134 Signed-off-by:
Quentin Smetz (qsm) <qsm@odoo.com>
-
Benoit Socias authored
When the browser is zoomed, the value of the `border-width` CSS properties obtained through `getComputedStyle` are impacted by the zoom. Because of this, entering a "10px" border in a Chrome zoomed at 125% turns it into "9.6px" when leaving the input field. This commit neutralizes the zoom effect by rounding the value up. The rounding operation was empirically determined by observing values, see table below. When zoomed out this does not always work: e.g. at 50% zoom, a value of 11px becomes 10px. But zooming out is an unxpected use case, that situation is therefore not handled by this fix. Observed values of the border-width property: Set value => `getComputedStyle` ``` Value Chrome 125% Firefox 120% 1px 0.8px 0.83333px 2px 1.6px 1.66667px 3px 2.4px 2.50000px 4px 4.0px 3.33333px 5px 4.8px 5.00000px 6px 5.6px 5.83333px 7px 6.4px 6.66667px 8px 8.0px 7.50000px 9px 8.8px 8.33333px 10px 9.6px 10.00000px 11px 10.4px 10.83333px 12px 12.0px 11.66667px ``` Steps to reproduce: - Drop a "Text - Image" block. - Select the text column. - Zoom with ctrl+mouse wheel or ctrl-plus. - Set a 10px border. - Leave input field. => Border option field displayed a different size. task-3172235 closes odoo/odoo#119084 Signed-off-by:
Quentin Smetz (qsm) <qsm@odoo.com>
-
Eric Antones authored
This takes into account the option that allows to disable/enable the QR file generation Closes #85283 closes odoo/odoo#124995 Signed-off-by:
John Laterre (jol) <jol@odoo.com>
-
Louis (loco) authored
Steps to reproduce the bug: - Add a "Cover" snippet on the website. - Add a "Custom" filter on the image. - Put the "Blur" setting to the maximum. - Save and edit. -> The "Blur" setting is not on maximum anymore. Since [1], the dataset of background images is first filtered (by the elements inside of the `BACKGROUND_IMAGE_ATTRIBUTES` set) before being copied into the dataset of `this.img`. Because `filterOptions` was missing in the set, the values of the custom filter were not displayed correctly (see `_computeWidgetState()`). [1]: https://github.com/odoo/odoo/commit/31ba9060723f365d16d51d3de0acf42c5e95f63b task-3358051 closes odoo/odoo#124227 Signed-off-by:
Dieleman Guillaume (gdi) <gdi@odoo.com>
-
Merel Geens (mege) authored
After creating a sales order for a product with cost 0, automatic inventory valuation and AVCO, and validating the delivery, no account move is created for the stock move. If an invoice is then created from the sales order, it will create 0 amount COGS lines. Automatic reconciliation of the invoice with the corresponding stock account move will fail because no such entry exists, resulting in unreconciled lines remaining in the invoices. This issue can be prevented by either creating a 0 amount journal entry for the stock move, or preventing the creation of the 0 amount COGS lines on the invoice. Not creating unnecessary COGS lines is preferable and this was also the solution used for the same problem with purchase order invoices: https://github.com/odoo/odoo/pull/106785 . So this fix does the same for sales order invoices. opw-3000320 closes odoo/odoo#124125 Signed-off-by:
Brice Bartoletti (bib) <bib@odoo.com>
-
Thomas Lefebvre (thle) authored
Issue: ------ When we have the link to the form to apply for a job, even if the job is not published, we can still apply. Solution: --------- Check that the job is published before the creation of the record in the `website_form_input_filter`. opw-3331717 closes odoo/odoo#124399 Signed-off-by:
Kevin Baptiste <kba@odoo.com>
-
- Jun 13, 2023
-
-
Benjamin Vray authored
Steps to reproduce the bug: - Install the Website Slides module. - Got to the /slides page. - Click on a course. - Click on the "Add Content" button. - Choose "Web Page" in the modal. - Once in edit mode, drag and drop a "Table of Content" snippet onto the page. - Save the page. - Scroll the page and observe that the navbar items are updated as you scroll. - Click on the "Fullscreen" button. - Bug: When scrolling the page, the navbar items are no longer updated as you scroll. This commit fixes the issue by detecting the scrolling element by traversing up the ancestors from the 'table of content' snippet, instead of using the 'getScrollingElement' function, which always returned the '#wrapwrap' when a Website Slides page is in fullscreen. opw-3302118 closes odoo/odoo#124459 Signed-off-by:
Romain Derie (rde) <rde@odoo.com>
-
Hamza (hisl) authored
Steps to reproduce the issue: Add a project and create a task with a timesheet in it set the allocated hours to 00:03 add a line in the timesheet with hours spent 00:03 Current Behaviour: The percentage calculated would be 96%, even though the time allocated and time spent are equal. Desired Behaviour: The percentage should be 100 as both values i.e. time spent and time allocated are equal. This is happening because effective_hours value is being rounded off to 2 decimal places, and is not accurate enough to compute the progress_hours. Here, I have used the same line, that is used to compute effective_hours, to compute the task_total_hours but without rounding off. This will make the calculate more precise and accurate. OPW-3270858 closes odoo/odoo#121168 Signed-off-by:
Xavier Bol (xbo) <xbo@odoo.com>
-
Harald Panten authored
closes odoo/odoo#124688 Signed-off-by:
Josse Colpaert <jco@odoo.com>
-