Have something like:
```js
sprintf("my string %s", _lt("lazy translated"));
```
Before this commit, the lazy translated term was not formatted into the string.
This was because _lt returns an object containing a custom toString function, which was not handled by sprintf
After this commit, sprintf is able to handle lazy translated strings
closesodoo/odoo#72598
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, "lazy translated" strings were implemented as
objects with a toString function. This is simple, but does not emulate
very well the real behaviour of a string.
In this commit, we create a LazyTranslatedSTring class which subclass
the String class, so all string methods will work as expected.
We also expose the _t function here, to make it more convenient for some
code to access the translations instead of depending on the presence of
an environment.
Purpose of the commit is to improve the usability and onboarding
of the project app.
So in this commit, done the below changes:
- Rename column "Kanban state" in list view screens
- Hide column "analytic account" when not needed
- Do not show "Internal" project
PS: Moved leave_timesheet_project_id into hr_timesheet and rename
it as internal_project_id and we used it in the domain in the
kanban/action to the kanban in order not to have it in the result.
closesodoo/odoo#68857
Taskid: 2451722
Related: odoo/upgrade#2479
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Before this commit, for the db with old active tasks and many
projects and tasks. The report takes several hours to execute the sql view.
Because we take the create date of the oldest task as the begin date
of each generate_series to calculate the different group bys (day, week,
month, quarter and year) until CURRENT_DATE.
This commit hugely improves the performance of the sql view execution
for the burndown chart report.
closesodoo/odoo#72664
X-original-commit: 89726a22862cf14f7b88e130fb79ddc74bffff5e
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Co-authored-by: Nicolas Seinlet (NSE) <nse@openerp.com>
Co-authored-by: Thibault Libioulle (TLE) <tle@odoo.com>
Co-authored-by: Laurent Stukkens (LTU) <ltu@odoo.com>
The amount of cash present in the POS may be incorrect
To reproduce the error:
1. In POS settings, enable "Advanced Cash Control"
2. Start a POS session
3. Make an order of 70$, payment in cash
4. Close the POS session (correctly set the closing cash)
5. Start a POS session, close it (correctly set the closing cash)
Error: Back to kanban view, the information about the POS are incorrect:
the cash balance is equal to zero, it should be $70
The value of the cash balance is computed in `_compute_last_session`:
https://github.com/odoo/odoo/blob/5ea1d31df9041ca7b25fbea6178e798e62bebca0/addons/point_of_sale/models/pos_config.py#L276-L291
This method gets the last session and extracts the information. However,
in the above case, there were no sales during the last session (step 5).
In such situation, the bank statement of cash is deleted. As a result,
in `_compute_last_session`, `last_session_closing_cashbox` will be
defined to `False`. This is the reason why the cash balance will be
equal to 0
The deletion of `cash_register` has been introduced in case the user
closes a session that does not contain any SO. This fix suggests keeping
such a bank statement and automatically posting it.
Linked to OPW-2507394
closesodoo/odoo#72663
X-original-commit: dae9ba62d98d4238600ccd637dd5e879f1cac903
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Since odoo/odoo@1971bf3 the customised dropdown in the pivot view (the one that opens its submenus horizontally) cannot open at all its submenus.
As the correct behaviour cannot be restored without reintroducing the +300 scss lines that has been removed, this commit applies a temporary fix that *changes* the design of this dropdown. Now, its submenus will open vertically, like for the groupby menu near the search bar.
The final dropdowns design is currently ongoing within the taskid: 2578926
closesodoo/odoo#72640
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Stefano Rigano <sri@odoo.com>
This could save some time when `_compute_quantity` is used thousands times in
request and there are thousands UOMs in the system
* if qty is zero, then result is zero
* if to_unit is the same, then result is `round((qty / factor) * factor) = round(qty)`
---
opw-2549026
closesodoo/odoo#72582
X-original-commit: a122db226cdf801675daaee5a69bcb47a47ab174
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
When consulting a delivery slip, a portal user won't see the lots/serial
numbers used.
To reproduce the error:
(Need demo data)
1. Create a product P
- Product Type: Storable
- Tracking: By Lots
2. Update its quantity
3. In Settings, enable "Display Lots & Serial Numbers on Delivery Slips"
4. Create + Validate a SO:
- Customer: Joel Willis
- Lines: 1 x P
5. Validate the delivery
6. Log in DB with 'portal' (Joel Willis)
7. On SO, open the Delivery Slip
Error: The product's lot is not mentioned
Here is the condition to display the lot:
https://github.com/odoo/odoo/blob/c61db20204700a375f7005f50f95b44a60c3bb70/addons/stock/report/report_deliveryslip.xml#L77-L79
Problem is that portal users are not part of
`group_lot_on_delivery_slip`
When enabling the option, the groups are updated here
https://github.com/odoo/odoo/blob/adccb562209c2431a49438d36794f0765f1bc86d/odoo/addons/base/models/res_config.py#L570-L576
`implied_group` (which is `stock.group_lot_on_delivery_slip` in our
case) is added to `groups.implied_group`
The variable `groups` comes from `classified`, which is defined thanks
to method `_get_classified_fields` (see L553 in above code block)
And here is an extract of how this method works:
https://github.com/odoo/odoo/blob/adccb562209c2431a49438d36794f0765f1bc86d/odoo/addons/base/models/res_config.py#L460-L462
At some point, it checks if the field `group_lot_on_delivery_slip` has
an attribute `group`. In case `group` is not defined, the group
`base.group_user` is used. This is the reason why, by default, the
option is enabled for internal users only instead of all users.
Therefore, we just need to define the attribute `group` to the field
`group_lot_on_delivery_slip`
OPW-2558761
closesodoo/odoo#72656
X-original-commit: 475b35397b7254012a082a1206c478084c069857
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Before this commit, the template of some dynamic classes (usually as WOWL to legacyAdapters)
were registered at each definition of the class which is potentially at every doAction/switchView
After this commit, they are all registered only once, as early as possible.
closesodoo/odoo#72476
Related: odoo/enterprise#19199
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Before this commit, when clicking on menus or debug items or use menu items
the URL briefly changed pushing an unwanted history entry.
We do want those to be links (tag `a`) with an href to be able to open in a new tab.
But we don't want the current url hash to change because of it.
This commit fixes this.
on a legacy form view, do an action in target new
The view in target new should, during its onchange, trigger a ValidationError
Before this commit, the dialog_container was stuck in an error loop.
This was because the received error was never an instance of Error, rather it was
a legacy error event. So it was never transmitted upstream were the ErrorHandler could remove
the dialog in error from is dialog array.
After this commit, the ValidationError mesage is displayed.
This commit additionally fixes another issue:
An action in target main that failed to render erased the whole DOM. This is not what we want,
at least for now. Imagine a list view, open a record, this record fails to load. We still want to be
on the list view, not in a blank state.
Before this commit, the error service bound its listeners onto window.
This may create pollution when executing more than one test instanciating an error_service
After this commit, we bind the handlers onto browser, which is fully in our control in tests.
Open a action in target new that you'll know will fail to open.
Make sure you put an onClose callback when executing doAction.
Open another action in target new, that will succeed.
Before this commit, the onClose of the first dialog is executed, while it should not.
Indeed, if the dialog fails, the whole business flow is invalid altogether
and no more business operation (in the onClose) should be executed
After this commit, the onClose callback of the failing dialog is not executed.
Steps to reproduce the bug:
- Let's consider an employee E with 8.00 hours as Average Hour per Day
- Create an Allocation for E with a Time-off Type in Hours
(be sure the number of hours is different from the average hour per Day)
- Open the form view of E
Bug:
The smart button Time Off(remaining leaves) was completely unreadable
opw:2441019
closesodoo/odoo#67849
X-original-commit: af8ce1d8891a4dcdeb80b069a114299d84e021f1
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Add an enrich and update endpoint allowing the user to update an existing
company if the company has no insights, as this can bring valuable information
for the user especially if the company has no infos.
Task-2563180
closesodoo/odoo#73658
X-original-commit: 72c35667d3e6f99cb4cfdbd1c93b877cc9fef750
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
More often than not these 2 fields have the same value, but when they are
different it is `displayName` that holds the expected value (eg. for a DM,
`displayName` would be the custom name or the name of the correspondent).
This commit updates them to avoid confusion and having bad examples in the code.
closesodoo/odoo#73659
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Following design update with new web client, the heading color is too strong
to be kept on author. The default color now does just fine actually.
closesodoo/odoo#73656
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
When using the Add button on the calendar view introduced with
odoo/odoo#64948 the event would not be linked with the applicant.
After further investigation the method used to get the applicant id in
default_get was not flexible enough, the one from crm calendar has been
'copied'
Task ID: 2578165
closesodoo/odoo#73635
X-original-commit: f23e07dcb0606dbc4bf835b8266323d5a515662d
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: William Braeckman (wbr) <Williambraecky@users.noreply.github.com>
When setting the request_date_from and request_date_to when creating a
leave that will be used to show the range of days of the leaves, we are
using the current user timezone to determine it.
eg. in UTC+2 if the leave begins at midnight on the 6th, we will see 6
and not 5 which is the day in UTC.
When creating a leave in a mode different than employee, when it is
confirmed and a leave is created for each employee, we would use the UTC
day instead which is a little unexpected.
Without the fix, the added test fails with:
AssertionError: datetime.date(2019, 5, 5) !=
datetime.date(2019, 5, 6) : Timezone should be kept between company
and employee leave
opw-2573730
closesodoo/odoo#73633
X-original-commit: eb5c4e9b8d32a10e460ac089794bf1ceb9b7b71a
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Sorry but not sorry, I have to fix this file's "codestyle" (unread
variable, missing or extra ";" characters, etc) post-editor merge...
hard to work inside of it in the current state.
closesodoo/odoo#73629
X-original-commit: dbf245891099b506f21a66ea8e7a9146f6c9e28b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Add support for tasks for the mail plugins via the new project_mail_plugin
module.
The new module provides the following new features:
- Enables the user to see tasks related to the selected contact, tasks where the
contact is the customer
- Enables the user to log an email directly to a task as this can be useful when
the user finds important information in the email
- Enable the user to create a task with the email message being directly set
in the description field, as the user would probable want the email
message to be included in the created task, this is done through the
"create_task" method, which the plugins will use in order to
create the task and send the related information, the plugin would then
directly redirect the user to the task form view realted to the created
record in edit mode.
Purpose is to allow users to connect their tasks to their mailbox.
Which allows for example to create a task from an email received,centralize data
regarding a customer on its task, check ongoing tasks for a customer, ...etc
UPG-PR: https://github.com/odoo/upgrade/pull/2488
Task-2518640
closesodoo/odoo#70943
Related: odoo/upgrade#2488
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
On reconcile models, a rule can be set to map a partner to a bstline if
the bstline "Notes" matches a regex. This "Notes" field is actually
the "narration" field inherited from move. In commit 0f3c7f153e8bd20f83b7d1df031634996d36935b
this field is converted from Text to Html. This breaks the regex match.
The fix converts back the field value to text for the regex check.
closesodoo/odoo#73618
Task: 2427089
X-original-commit: 8e9616034678a627f92740487f20cf66e60c0f30
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: jbw-odoo <jbw-odoo@users.noreply.github.com>
One could edit bank statement line values with new from a bstline modal. This
is due to new quick edit behaviour. This prevent the editiing of bst lin values
if bst is not new.
closesodoo/odoo#73617
Task: 2427089
X-original-commit: c9e220d0276f59834baeae3196560a7f893ff337
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: jbw-odoo <jbw-odoo@users.noreply.github.com>
before this commit, the name of the event and hour is not
correctly centered while dragging the pill in month mode.
This commit fixes the issue by adding the CSS property.
after this commit, the name of the event and hour should be
correctly centered while dragging the pill in month mode.
TaskID-2506060
closesodoo/odoo#73553
X-original-commit: 59156daa150bf285626600f0a999dfe9838e1344
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
You can do same (with matching on name, instead of rel) with dynamic snippet
Else you can create one Ecommerce category by blog, and hide this category on
shop page, and have a lot a useless record, and have a 'bordel' in your categs
and from this way use a product snippet linked to this category.
Or install a module from the community that do the same that this one: a simple
way to link your product to blog, and show them without string matching or fake
categ.
closesodoo/odoo#73403
Related: odoo/upgrade#2632
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
When hotkey overlays are removed, we now prevent default on keyup,
as this may cause some browsers to display their menu bar
(as the overlay key we use is ALT). e.g. Firefox.
closesodoo/odoo#73343
Related: odoo/enterprise#19627
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
The purpose of this commit is to:
- Improve the design of the command palette
- Add few data-command-category and data-hotkey
- Scrolling through the command palette dropdown with the up/down arrows
should loop
- Moving the mouse over the palette command no longer causes scrolling
Task-2590390
- The work order state changes based on the availability of the components
- So if all BOM components are available the state of the first WO is set to ready
- The color of ready in the WO tree editable view will stay blue as long as done reserves the green color
- If one or multiple components are not available, the state of the first WO is set to waiting
- The color of waiting in the WO tree editable view is set to orange
By default to launch takes workorder_ready_count so it counts only ready WOs
- The user can always process the WO without restrictions even if the WO state is waiting
Task-2426773
closesodoo/odoo#71250
Related: odoo/enterprise#18523
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Co-authored-by: nouraellm <nea@odoo.com>
Issue: we can't canceled a MO without component to consume when the MO
is in the state 'to_close'. It is due to
bf5e1debf9 which now allows to confirm a
MO without component to consume.
Like for the 'done' state. the state 'cancel' can't be modify after to
be set.
task-2426773
For data quality purposes and bug prevention, when I reverse an entry,
the reversal should always be postable on a journal having the same type
as the initial Journal Entry's journal.
closesodoo/odoo#72431
Task: 2497529
Related: odoo/enterprise#19543
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Fixes an underterministic error during the holidays_attendance test.
Also speeds up both holidays_attendance and hr_attendance_overtime
significantly.
Task ID: 2599846
closesodoo/odoo#73570
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit loosens 2 things:
1. A batch can now be deleted for all statuses except 'done'
2. Cancelled batches will now remove links to any pickings assigned to
it (so they can be more easily reassigned in barcode app)
closesodoo/odoo#68898
Task: 2486993
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Before this commit, if the user chose the "red" color suggestion, "red"
did not appear as a custom color (but the color suggestion was marked
as selected). This made sense in the previous colorpalette widgets but
not anymore as the suggestions do not always appear in all colorpickers
anymore.
Now those colors are always considered custom when used in the page and
at worst appear as "common" and "custom" at the same time (the "common"
one being the one which can appear as selected in that case).
Part of https://github.com/odoo/odoo/pull/67545
task-2476601
closesodoo/odoo#67545
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This allows the user to not have to understand that it has to decrease
the transparency by himself.
Part of https://github.com/odoo/odoo/pull/67545
task-2476601
In order to save space and gain clarity, the colorpicker elements are
now displayed in two separate tabs: "theme" and "custom".
It is still possible to display the combinations tab instead of the
theme one (for the background color option for example).
Part of https://github.com/odoo/odoo/pull/67545
task-2476601
Unbreakable elements were being considered as unremovable in some deleteBackward cases.
With these changes it is now possible to remove a unbreakble element if it is empty.
task-2580158
(cherry picked from commit 18abf537f07bd9c504dc19c3fa8eda5b1f4d4e9e)
closesodoo/odoo#73592
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
Color and background-color styles on `<font>` tags were being wrongly overridden when applying another color or background color to the element.
Task-2580158
(cherry picked from commit a532d096faf55550ac6d01795aaa2b6843ebc988)
Since 54e9527ec2, a new session module is
used to access the session info. The legacy session uses also this
module to access the session info. This means that if a module uses the
legacy session, the new session.js needs to be added to the manifest.
closesodoo/odoo#73500
Related: odoo/enterprise#19581
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
1. When creating a putway rule, default location_in_id is receipt
destination location (in case of single warehouse).
2. When changing location_in_id, copy value to location_out_id.
3. Allow to hide some fields and change of some labels.
4. Move location tab to a smart button.
closesodoo/odoo#69580
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
To improve the payment method system, proceed to a few changes
such as changing the view a bit, making sure payment acquirers are not
linked to a journal by default and that only the manual payment method
type can be used multiple times in a single journal.
Task id #2573145closesodoo/odoo#73596
X-original-commit: 9122b367baea10e59b66e45bf7c458a6f1e82efb
Related: odoo/enterprise#19623
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Before this commit, if there was a crash in a view or client
action during an update (i.e. the action is already in the DOM,
but an update triggers a re-rendering), the error was caught by
the action service, it wasn't displayed to the user, and the
action was re-rendered again (which could obviously result in the
same error being thrown again and again).
With this commit, we properly show the error, and we do not try
to re-render the action.
closesodoo/odoo#73507
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Lucas Perais (lpe)