Tuesday, January 21, 2020
12 changes · master
Enhancements to existing features
This update cleans up how document followers are managed across mail features, making the behavior clearer and easier to maintain. It also streamlines related web routes and improves follower information handling, which should support better performance and reliability in messaging workflows.
Original PR description
Follower model holds relationship between a document, and a partner or a channel. It is used mainly through dedicated routes and methods as it has been optimized for performance reasons. In this commit we go further in route and management cleaning, trying to optimize follower management using notably sudo to lessen query count.
Email Marketing and SMS Marketing activities now appear as separate entries in the activity menu instead of being grouped together. This makes the alerts clearer, uses the right app icons, and opens only the relevant email or SMS marketing activities when selected.
Original PR description
PURPOSE mass_mailing and mass_mailing_sms activities are grouped as 1 item in the systray due to them using the same model name (sms inherits and distinguishes itself with a different field.Selection value). This is confusing behavior because they are 2 separate modules and the default icon ends up mismatching the sms-related activities. SPECIFICATIONS Split mass_mailing and mass_mailing_sms activities into 2 separate items in systray. Additionally, make it so when mass_mailing and mass_mailing_sms activities are clicked on, only the relevant activities are shown to prevent confusion. In order to only show relevant activities, an optional "domain" check is needed in __systray_activity_menu.js__ for when overriding _systray_get_activities_ methods provide a domain to apply. Task: 2169498 PR #43272
This improves how Odoo gathers related record data, reducing repeated work and making better use of caching. Business users should see faster responses in areas that process large sets of records, especially where reports, lists, or automations rely on these lookups.
Original PR description
Reimplementation of (part of) #38850 TODO: - [x] Make `_RelationalMulti.__get__` use the new and improved `mapped` instead of naively reimplementing the old one
This change adds compatibility tools that let older Odoo web screens and newer Owl components work together during the ongoing interface modernization. It reduces migration risk for the web client and updates the pivot view to use the new adapter approach without aiming to change day-to-day business workflows.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update speeds up common data lookups by reusing a previously calculated cache value instead of recalculating it repeatedly. It can make heavily used operations noticeably faster across Odoo, while also preventing website sale tests from changing shared environment settings unexpectedly.
Original PR description
It's caches all the way down `Field.__get__` and `BaseModel.mapped` are up to 2x faster thanks to this patch When paired with #42611, `BaseModel.mapped` becomes blazing fastererer Benchmarks will be made public later (?)
New users now receive a default profile picture, making profiles look consistent even when no photo is uploaded. Unassigned records in kanban-style views now show a clear unassigned icon and hover text, helping teams quickly distinguish missing assignments from users without photos.
Original PR description
======= Purpose ======= When you go in project (or any other module) and nobody is assigned to a task, the default 'missing image' is displayed. Because of that, there is no way of telling if the user is missing a profile picture or if nobody is assigned to the task. =========== Specifications =========== - Set a default image for new users - Each user should have a distinct backgroung color - If the record is unassigned display user-slash icon and unassigned on hover TaskID: 2060206
Event and website event track Gantt views now open around the relevant event or record dates instead of defaulting to calendar period starts. The view can also choose a more suitable timescale automatically and avoids an error when switching from grouped list views.
Original PR description
Purpose ======= Improve the gantt views in Event, to show relevant data. Specifications =========== We want to gantt view to start at the `initialDate`, and not at the beginning of the year/month/week. For that purpose, we added a new parameter on the gantt view, `dynamic_range`. If this attributes is set, the gantt view starts at the `initialDate` (now, or defined in the parameters) instead of starting at the beginning of the year/month/day. We also want to have an automatic scale. If all the records are on the current week, we want the scale to be "week". Fix a bug when in the tree view we group by day:hours, and then we go to the gantt view. Task 2168740
Kanban cards now clearly show when a record has no assigned person, using an unassigned icon and hover text instead of a generic missing image. New users also receive a default profile image, helping teams distinguish between missing photos and genuinely unassigned work.
Original PR description
======= Purpose ======= When you go in project (or any other module) and nobody is assigned to a task, the default 'missing image' is displayed. Because of that, there is no way of telling if the user is missing a profile picture or if nobody is assigned to the task. =========== Specifications =========== - Set a default image for new users - Each user should have a distinct backgroung color - If the record is unassigned display user-slash icon and unassigned on hover TaskID: 2060206
Accounting reports now have cleaner alignment, better spacing, and more consistent printed output. Users can also search more reports and see totals handled consistently, making financial review easier and reducing confusing display issues.
Original PR description
TODO : complete commit message
Resolved issues and error corrections
The base language list now replaces Filipino with Tagalog to better match common language naming and avoid confusion with Finnish browser language detection. This helps prevent Finnish users from being incorrectly directed to Filipino-language pages while keeping the expected Philippines language option available as Tagalog.
Original PR description
This is the second move to replace Filipino by Tagalog language Using Filipino (code fil_PH) is problematic as conflicts with Finnish (code fi_FI) and users having their browser in Finnish were…
This is the second move to replace Filipino by Tagalog language Using Filipino (code fil_PH) is problematic as conflicts with Finnish (code fi_FI) and users having their browser in Finnish were redirected to the Filipino version of the website (cf discussion at opw-2172710). This problem was also raised in other softwares like in the below discssion in Mozilla L10N groups https://groups.google.com/forum/#!topic/mozilla.dev.l10n/TW2qYyDDNoE Quoting the discussion in above thread: > Filipino is the national language of the Philippines, but it is > commonly referred to (and registered as) Tagalog, since most of the > terms therein were derived from it (Tagalog). This commit targets the master (future 14.0 as of today), adds a new Tagalog language and removes the Filipino. In 12.0, only the Tagalog was added at odoo/odoo#43633. As fil_PH is only translated on odoo-com project but remains at 0% in other Transifex project, it is assumed the language switch won't impact too many people.
This update corrects how website, sales, mailing, and web interface templates mark text for translation. It prevents layout or style text from being sent to translators while ensuring real user-facing labels are properly translatable, improving localization quality across Odoo.
Original PR description
This commit fix most `t-set` errors that either led to:
1. unwanted text to be considered as translatable.
eg: `<t t-set="classes">text-left bg-100 p4</t>` would create an
`ir.translation`.
2. text that should be translatable were not.
eg: `<t t-set="text" t-value="'Both'"/>` would not create an
`ir.translation` while it should.
If a text should be translatable, it should never be inside a `t-value`:
- `<t t-set="text">Both</t>`
If a text should not be translatable, it sould either be inside `t-value`,
`t-valuef` or the `<t>` tag should have `t-translation="off"`:
- `<t t-set="classes" t-translation="off">text-left bg-100 p4</t>`
- `<t t-set="classes" t-valuef="text-left bg-100 p4"/>`
- `<t t-set="classes" t-value="'text-left bg-100 p4'"/>`
https://github.com/odoo/odoo/pull/43660
https://github.com/odoo/enterprise/pull/7839
https://github.com/odoo/design-themes/pull/203This fixes a timing issue where quickly creating a related record while editing order lines could reset or disrupt unsaved line changes. It makes sales and rental form interactions more reliable and also corrects product configurator dialogs so follow-up choices appear in front as expected.
Original PR description
Let's assume a form view containing a many2one with an onchange that updates the value of a one2many. Do a quick create in the many2one. While the name_create request is pending, add a row to the…
Let's assume a form view containing a many2one with an onchange that updates the value of a one2many. Do a quick create in the many2one. While the name_create request is pending, add a row to the one2many but do not leave it. When the name_create returns, and the onchange has been performed, the one2many is reset, and the row is no longer in edition (worse, it could be invalid, i.e. in a state that the user could not have reached in a normal situation). This commit fixes this issue by considering the whole [name_create + onchange] operation as one. This operation is executed in the mutex of the model, so the other request (adding a row to the one2many) is delayed until the many2one value has been correctly set. This fixes an issue with the sale and rental tours (on sale_order), that had been deactivated for a while. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr