Daily updates from Odoo
Friday, March 15, 2024
4 changes · master
Resolved issues and error corrections
Recurring shifts now handle existing overlapping shifts more accurately when shift lengths differ. This reduces cases where employees are incorrectly treated as available or busy, helping planners create more reliable schedules while still falling back to open shifts when needed.
Original PR description
When generating recurrent shifts, we check whether the resource is busy or not and if they are, we generate the recurrent shift as an open shift. Currently, we check whether the resource is busy by…
When generating recurrent shifts, we check whether the resource is busy or not and if they are, we generate the recurrent shift as an open shift. Currently, we check whether the resource is busy by seeing whether there are any overlapping slots already for that resource and by checking that the allocating percentage for all overlapping slots wasn't above 100%. That is quite naive and only works when all the overlapping slots are of the same duration. This task should change the implementation in order for it to work with different duration slots. We do this by comparing the total planned hours between the overlapping slots to the total hours in the overlapping period. **Disclaimer:** This does not respect the working hours of the employee: Let Bob work from 9:00 to 17:00. If shift A is planned from 8:00 to 17:00 (8h) and recurrent shift B is planned from 16:00 to 17:00 (1h). In this scenario, the recurrent shift will be planned normally because the total hours in the overlapping period are 9 and the total hours being planned are also 9. We do not take the fact that Bob should work 8 hours :) task-3806681
The Austrian financial reports now produce a balanced Balance Sheet by adding missing account classifications and separating current-year results from carried-forward profit or loss. This helps businesses produce reports that better match official Austrian reporting requirements and reduces the risk of incorrect statutory filings.
Original PR description
According to the Balance Sheet diagnostic test in #47602, the Balance Sheet was unbalanced. To fix this, - missing account tags have now been added (cf community PR); - the Balance Sheet Profit (loss) line has been split into the current year's profit/loss and the profit/loss carried forward. - the Profit and Loss in excess for the current year has been created as a new line in the P&L. This is all done in accordance with the official Balance Sheet found at https://www.bmf.gv.at/services/finanzonline/informationen-fuer-softwarehersteller/softwarehersteller-e-bilanz.html Community PR: https://github.com/odoo/odoo/pull/147108 taskid: 3060790
Intrastat report values are now taken from accounting entries in the company currency instead of recalculating from invoice line subtotals. This makes reported amounts more reliable, while still correctly valuing fully discounted goods using the appropriate exchange rate.
Original PR description
Amounts on the intrastat report should always be in the company currency. At present the intrastat report retrieves the value of the line subtotal (or the unit_price * quantity if the price_subtotal…
Amounts on the intrastat report should always be in the company currency. At present the intrastat report retrieves the value of the line subtotal (or the unit_price * quantity if the price_subtotal is equal to zero). The current behaviour is to retrieve the currency rate at the invoice date of the line, and calculate the value by converting to the company currency using this rate. Since the journal items are always in the company currency, it makes more sense and is more reliable to retrieve the balance of the line. This commit adapts the sql query that retrieves the data for the intrastat report. Instead of the "value" column of the report being retrieved using the "price_subtotal", we instead use the "abs(balance)", since the balance of the line is always in the company currency. In the case where the line has been fully discounted, is is still necessary to report the value of the goods being gifted. In this case, since there is no amount on journal items in the company currency, conversion still needs to occur. The existing method is to multiply the price_unit by the quantity (applying the conversion outside of this query). This commit adds a lateral join to the query so that conversion can be performed from within the query. The lateral join fetches the most recent conversion rate to the invoice date so that it can be applied to the price_unit * quantity. task-id: 3477631
Portal and member users can now view published Knowledge articles that include embedded kanban content without hitting a generic error. The fix ensures published article stages are readable when needed, improving access for shared website knowledge pages.
Original PR description
**Current behavior before this PR**: -> Create 1 article that has an embedded kanban and 1 article inside a kanban(both articles are published). Now if the user opens this article from another user - member/portal, the user gets an error like 'Something went wrong'. **Reason:** -> Access to the Kanban stage was only for the user who had access to that article, there was no record rule defined that the stage was shown to the member/portal user if the article was published and the article was an item article. **Solution:** -> In previous versions there was a temporary fix that was added here(https://github.com/odoo/enterprise/commit/e9f63e0aa0bb51e2d686473227671ab392d56b9e) so removing that fix and adding the access rule which allows other users to read stages if the article is published. **Desired behavior after this PR:** -> Kanban will appear properly with read access to the portal/member if the article is published. **Task**-3486083