New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merge from upstream 15 20240111 01 #833
Merge from upstream 15 20240111 01 #833
Conversation
Steps to reproduce: ------------------- - be in UTC -5 (America/Lima for example) on the system (and so browser) and the user profile; - create an event from 4pm to 5pm the next day; - be at 2pm today; Issue: ------ We have a notification in activities for this event today, which is one day too soon. Cause: ------ To find the events that need to be notified to the user, we use a domain which, in this case, can be expressed as follows: ``` ( the `start` of the event must be after "now" (the event has not yet passed) OR the event `stop` must be after now (the event is in progress) ) AND the `start` of the event must be less than the end of the day (the event must be today) ``` The end of the day must be determined, but taking into account the user's timezone. As the domain has to work with UTC values (because the `start` and `stop` values of the event are in UTC in DB), in order to determine the end of the current day, we first need to determine which day the user is in UTC. Logic before this commit (using the example): ```py start_dt = datetime.datetime.utcnow() # 19:00 (because 14h in America/Lima -5) start_date = timezone(tz).localize(start_dt).astimezone(UTC).date() # 00:00 next day end_dt = datetime.datetime.combine(start_date, datetime.time.max) # 23:59 next day end_dt = timezone(tz).localize(end_dt).astimezone(UTC) # 4:59 second next day ``` The result (for an America/Lima timezone) is that if the event has its `start` in UTC before 4:59 two days later, the event will be notified. Solution: --------- Correct the values used to construct the domain. Logic after this commit (using the example): ```py start_dt_utc = now_utc.replace(tzinfo=UTC) # 19:00 (because 14h in America/Lima -5) start_dt = start_dt_utc.astimezone(user_tz) # 14:00 (because 14h in America/Lima -5) stop_dt = datetime.datetime.combine(start_dt.date(), datetime.time.max).replace(tzinfo=user_tz).astimezone(UTC) # 4:59 next day ``` Because 23:59 today using user timezone and then converted to UTC gives 4:59 next day. In fact, the day of a user in the America/Lima (UTC -5) timezone ends in UTC at 4:59 the next day. If this same user creates an event that starts at midnight (and therefore tomorrow), the activity must not be displayed before midnight and therefore 5:00 the next day in UTC. opw-3523558 closes odoo#141949 Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Use case / Steps to reproduce the issue: - Enable multi-step routes- on the warehouse routes - warehouse a) receive goods (1 step) b) Send goods in output and the deliver (2 steps) - Create sales order ( 2 deliveries are generated - PICK and OUT ) - Go to product > forecasted > try to unreserve. The unreserve is only call in the last move of the chain. Add a context key to unrserve all the parents. It's not the best solution because it unreserve the whole picking and all the parents. So moves that are not related to the current product will be unreserved too. However, currently it does nothing when you click on it. So it just allow a new usecase for people without removing something. opw-3589811 opw-3544751 opw-3526349 closes odoo#143358 Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
The items in the Peppol Bis 3 xml should all have a `Name` tag, otherwise a validator will raise: "[BR-25]-Each Invoice line (BG-25) shall contain the Item name (BT-153)." This `Name` is the product's name or the label in case of invoice line with no product set. task-3607354 closes odoo#143178 Signed-off-by: Laurent Smet (las) <las@odoo.com>
Steps to reproduce: - Create a Batch transfer and create two reciept in it each with a serial tracked product in them - Confirm the batch transfer Bug: in the detailed operation tab of the batch transfer (use existing lots/ create lots) options of the picking type are not respected and lot id is displayed instead of lot name (many2one instead of char field) Fix: keep the same batch transfer as in the pickings that constitute it opw-3541324 closes odoo#142541 Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
The goal of this commit is to prevent the text animation overlay from blocking small text content selection. Remark: This behavior was already fixed on 17.0 (by [1]) for text animations and highlights and was backported here for text animation options. [1]: odoo@f64c9f2 Related to task-3285817 closes odoo#142833 Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
This traceback arises when the current day of the date is 31 while the schedule action (Generate Monthly Sales Closing) runs. Scenarios to produce the issue: [1] * Imagine the 'date_stop' value is '31-10-2023' * When the scheduled action('Generate Monthly Sales Closing') runs * The value of the 'month_target will be 9' and 'year_target' remains same * The value of 'interval_from' will be '31-09-2023' (an invalid date). [2] * Imagine the 'date_stop' value is '31-03-2023' * The value of 'interval_from' will be '31-02-2023' (an invalid date) It leads to the traceback Error: 'ValueError: day is out of range for month' See:- https://github.com/odoo/odoo/blob/5fb9825384895fd303bd15c3e4f8dbc55d35904f/addons/l10n_fr_pos_cert/models/account_closing.py#L124-L134 After applying this commit, it will resolve the issue by giving a valid date in all scenarios. sentry-4589899768 closes odoo#140652 Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>
An error will be generated when a user tries to import or upload a file into the invoice module and the file is attached to an image via a URL form but the image is invalid or cannot be found. step to reproduce- - install the `Accounting`. - open Accounting > Vendors Menu > Products. - import file (image url must be invalid or not found ) - the error will be generated. At the time of solving the conflicts of FW mistakenly changed the "ImportValidationError" to "ValueError". Due to these changes, the error is shown in the log. FW - odoo#137596 sentry-4538772256 closes odoo#138788 Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
The link isolation mechanism should not be applied in non-editable links. It also should not be applied in Bootstrap navigation as we don't want it to behave like a list of links and not to insert non-link content between the navigation elements. Part-of: odoo#142648
To prevent history steps that include the link zws, we need to ensure that the observer is always disabled when the link zws is inserted or removed. Due to these changes, we need to initialize `_currentStep` before setting the original link zws, so that `observerApply` can access it in the process of pausing the mutations observer. Part-of: odoo#142648
The `closest` method is only available on the Element class. `parentElement` guarantees the returned node will inherit from the `Element` class, which `parentNode` does not. This replaces calls to `closest` on nodes returned by `parentNode` so that they are called on `Element` nodes instead. Part-of: odoo#142648
When sanitizing the content of the editor, we should not move the cursor if it is out of the editable area. Part-of: odoo#142648
When reverting history removal steps, we check that the next node or the previous node exists so we can add the removed node next to it. But we failed to check that the node was still connected to the document. closes odoo#142648 Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
Currently there is no margin between the top edge and the image below in the DIN5008 layout. Thus the image may be cut off when printing the page. This commit adds a 10mm margin. opw-3599133 closes odoo#143383 Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
…usbar widget Before this commit: Using the readonly modifier on a statusbar widget would make it readonly whether or not the modifier was evaluated to true. After this commit: The readonly attribute on a statusbar widget now work as espected and the statusbar is readonly only when the modifier is evaluated to true. closes odoo#123668 Opw: 3222998 Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When using the vendor bill autocomplete feature, the vendor bill move lines are prepared using the values fetched from the purchase order. However, it uses the vendor bill's partner_id instead of commercial_partner_id and causes a mismatch in the partner_id column of line_ids. It is overwritten with the proper commercial_partner_id when the vendor bill gets posted, but duplicate tax lines are not consolidated. Now it uses commercial_partner_id from the beginning, saving the headache of duplicate taxes on accounting reports. closes odoo#141915 Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Since odoo@61a259f only users with Inventory permissions can see the quantity fields, but users with specific permissions (Sales, Purchase, Invoicing Point of Sale) should also be able to see it since they have stock.move permissions. TT45220 closes odoo#143099 Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Commit [1] moved page scrollbar to #wrapwrap, which introduced some issues. This was needed to not have a double scrollbar when the builder edition panel was moved from left to right. One of the issue if that the browser print was not working anymore. A workaround has been found with this commit to make it work again. It is just reverting the mentioned commit when inside the browser print preview, which can be achieved through css directly. Note that in the future, this PR [2] should revert the fact that the scrollable element is the #wrapwrap. Also note that while this fix allow printing pages again, there is still the same behavior as in Odoo 13 and before (where you can print pages too): the printing preview will not be in desktop size but display the pages as on tablet size. [1]: odoo@4e7be69 [2]: odoo#98429 opw-3557672 closes odoo#143790 Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce (V 17.0): - Create a new blanket order with agreement type "Call for bids": - Select only one RFQ - Use line of agreement - use quantities of agreement - Add a product and confirm - Create a New quotation - Traceback! Bug: typo in the onchange makes it so instead of setting payment_term_id to false it's a False, which is actually a tupple (False,) meaning payment terms will be a record set containg one value with Id False instead of an empty record set (it's wrong but it doesn't really make a difference in this case) until commit[1] in web_read clean up is used to get the Id from origin Id for inherited fields ´not vals['id']´ is expected to be true if the value has an origin Id but in this case it is true because Id is false (co_records wasn't expected to contains values with Id False if Id is False it should be empty) commit[1]:odoo#128878 closes odoo#143878 Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
The existing `_search_product_qty` was not scaleable for dbs with many lots, therefore we optimize it to be more clever. Also add in the missing operator/value checks. backport of: ee2fe22 Note that `_read_group` is only available from saas-16.3 onwards, so this backport has been adjusted for that. Also pot file does not need to be updated since the strings already exist in the module. closes odoo#144026 Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Steps to reproduce the bug: - Go to inventory settings > enable "batch transfer" - try to open any batch transfer Problem: A traceback is triggered: "Unkown field show_lots_text in domain" The bug is introduced by this commit: odoo@feb4bb8 the "show_lots_text" field was not added in the parent view closes odoo#144046 Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Currently, increasing the rounding factor for a currency is not allowed if accounting entries have already been generated in that currency. However, the restriction currently only applies to the current company. And since currency records are shared between multiple companies, a user can create a new company with no accounting entries and then change the currency's rounding factor, affecting all companies. This commit checks for the restriction on all companies, and fixes a few tests that were broken by this change. opw-3586785 closes odoo#142729 Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Speedup computation of tax_country_id by first filtering on record with fiscal_position_id.foreign_vat. Then group records without foreign_vat by company_id and call __setitem__ on each group. In the best case (1 company and no record with foreign_vat) this gives a speedup of 7.37s -> 450ms for 1000 records. This also speeds up the importing of account_bank_statements. opw-3576526 closes odoo#143224 Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Whether a question can belong to itself is too philosophical of a question for an error pop-up. opw-3572599 Part-of: odoo#141041
Versions: --------- - 15.0+ Steps to reproduce: ------------------- 1. Have multiple languages and Studio enabled; 2. create an event template; 3. add a question; 4. add translation to question; 5. use template to create event. Issue: ------ Translation doesn't get copied from template to event. Cause: ------ The `_compute_question_ids` method copied the questions by *manually* recreating them. It didn't use the `copy_translations` method like the regular `copy` methods does. The reason the questions were recreated is because question records cannot link directly from event template to event, as changes to the event shouldn't affect the template. Solution: --------- Use the `copy` method instead while setting `event_type_id` to `False` to satisfy the restriction. opw-3572599 closes odoo#141041 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
steps to reproduce: - as admin, go to /shop and add a storable product to cart - disable all delivery methods - use a coupon to set the price to 0 before this commit: - the payment button is clickable even if there is a big red warning saying "Sorry, we are unable to ship your order" after this commit: - the payment button is hidden if an error is displayed and the route /shop/payment/validate is blocked if there is an error displayed opw-3582207-nda closes odoo#142401 Related: odoo/enterprise#51216 Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
@duong77476-viindoo Viindoo Test Suite has failed! |
@duong77476-viindoo Viindoo Test Suite has failed! |
@viinbot rebuild |
@duong77476-viindoo PR in the queue to wait for rebuild! |
@duong77476-viindoo Viindoo Test Suite has failed! |
@duong77476-viindoo check lỗi runbot giúp anh nhé |
E có xử rồi anh ạ, chi tiết ở https://github.com/Viindoo/tvtmaaddons/pull/10155 |
@duong77476-viindoo Viindoo Test Suite has passed! |
Depends:
https://github.com/odoo/odoo/pull/149348
Video:
video-2024-01-11_08.34.00.mp4
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr