before this commit,
Users are unable to fold/unfold tickets
after this commit,
Users can fold/unfold tickets
task- 3081378
closesodoo/odoo#106992
X-original-commit: ae5df3e46559185773d2826bfbd74335df4d122d
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Stepts to reproduce:
Go to Time-off app > configuration > Public Holidays.
Try to create a new holiday and select working hours.
Issue:
It will show up all the working hours available for all companies even
if we are not in that company at the moment.
Solution:
We need to take into account the company for this field in order to only
show the working hours available for this specific company. I've added
to the field the `domain="[('company_id', 'in', [company_id, False])]"`
in order to follow the same behavior as next versions.
This issue affects 15.0 and saas-15.2
opw-3068827
closesodoo/odoo#106981
X-original-commit: 65f2861bf2728a7f9f991c47edc77fc557dfde14
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit description is in three parts: a generic explanation, a real
use case and the solutions
**Explanations**
1. When getting an odoo `Environment`, we first generate a tuple used as
an environment identifier:
https://github.com/odoo/odoo/blob/7475bcbef601b69e11c88a2ebb5fa39d7fcb52ab/odoo/api.py#L446
Then, there are two possibilities:
1. If such environment already exists in the environments list of the
transaction, we reuse it:
https://github.com/odoo/odoo/blob/7475bcbef601b69e11c88a2ebb5fa39d7fcb52ab/odoo/api.py#L448-L452
2. Else, we create a new one and store it in the transaction:
https://github.com/odoo/odoo/blob/7475bcbef601b69e11c88a2ebb5fa39d7fcb52ab/odoo/api.py#L454-L464
2. The `company` attribute of an `Environment` object is a lazy property
https://github.com/odoo/odoo/blob/7475bcbef601b69e11c88a2ebb5fa39d7fcb52ab/odoo/api.py#L537-L538
It means that its value won't be recomputed unless we delete it
https://github.com/odoo/odoo/blob/083c70bbb63f27839b2c9a4b549e216947bc4dd1/odoo/tools/func.py#L12-L17
3. When running a `SavepointCase` test class, the `setUp` method ensures
that, after each test, we do cleaning:
https://github.com/odoo/odoo/blob/a50a65be19b682201fc010d33c1b1f0b90cdf4d3/odoo/tests/common.py#L652-L662
The functions are added in a stack. So, in the execution order, we
will
1. Clear the current environment and the registry
2. Reset the environments list with the ones that were existing
before the executed test
4. Suppose a test class TC that inherits `SavepointCase`. TC has a
special `setUpClass`:
1. We create a new user U and replace the environment with a new one,
E1, based on U. This user has a company Comp_U. Because of [1], the new
environment E1 is added to the environments list of the transaction.
2. For some reasons, we need to do some operations in `sudo` mode:
again, because of [1], a new environment E2 (same as E1 but with the
`su` flag to `True`) is created and added to the environments list of
the transaction
5. TC contains a first test T1. In that test, we create a company
Comp_tmp and set it as default one to U. Therefore, E1 and E2 are
updated (their `company` attribute is now Comp_tmp)
6. At the end of T1, because of [3]:
1. E1 is reset (but its lazy properties are not deleted)
2. The environments list of the transaction is reset and still
contains E1 and E2 as they have been created in the class setup (i.e.
before the test setup)
7. In a second test T2, there will be an inconsistency: both E1 and E2
have an incorrect value for their field `company`: Comp_tmp, which is
not the value defined on `self.env.user.company_id` (the value Comp_tmp
does not even exist anymore)
**Real use case**
- The class `AccountTestInvoicingCommon` is an inheritance of
`SavepointCase`. In its class setup, we create a user and set it on the
current environment. Later on, we create a company (the sudo mode will
be activated during the company creation process)
https://github.com/odoo/odoo/blob/1e69c4fe5f8dd8a92d92f350b6d6a9539157f206/addons/account/tests/common.py#L38-L52
- The class `TestPurchaseOrder` inherits `AccountTestInvoicingCommon`
- The test `:TestPurchaseOrder.test_06_on_time_rate` creates a company
and sets it as the one of the current user
https://github.com/odoo/odoo/blob/87ffe5983be7f0f4a926b458c4bd1f13001048ec/addons/purchase_stock/tests/test_purchase_order.py#L313-L316
- Therefore, all next tests will have an issue with the environment
(unless we force the writing of the company on the current user to
bypass the issue)
```py
self.assertEqual(self.env.user.company_id, self.env.company) # will fail
self.assertTrue(self.env.company.exists()) # will fail
```
**Solution**
The above issue has been fixed from Odoo 15 on, thanks to commit C1.
Thanks to that diff, at step [3.1] in the above explanations, the lazy
properties of E1 are deleted (so, because of [2], the `company`
attribute of E1 will be correct again). However, once C1 is applied, we
can still add some lines in T2 to fail the test:
```py
sudo_env = self.env.user.sudo().env
self.assertEqual(self.env.user.company_id, sudo_env.company) # will fail
self.assertTrue(sudo_env.company.exists()) # will fail
```
The reason: at the end of the test T1, we reset the environments list of
the transaction ([6.2]). However, E2 has been created before the test
setup (it was in the class setup, see [4.2]). So, after the list reset,
E2 is still in that list and still has the value Comp_tmp for its
`company` attribute.
So... first we can conclude that C1 is not enough. Second, once the
environments list of the transaction is reset ([3.2]), we also have to
reset each environment to ensure that their lazy properties are correct.
We can then remove [3.1] since it will be included in that new step.
C1 a40511cd29closesodoo/odoo#106952
X-original-commit: a685f17ec9b0663d3632c903f4f0304d9a58f103
Signed-off-by: Raphael Collet <rco@odoo.com>
The association module was just overwriting a menuitem in membership. This
commit removes the association module and migrates the menuitem change to
membership.
task-3080120
closesodoo/odoo#106472
Related: odoo/upgrade#4075
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose: Use the same labels for the API settings of calendar providers in the
configuration modal as those used in res.config.settings for the same values.
closesodoo/odoo#105500
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
CONTEXT:
emoji_char_field and emoji_text_field
previously used the emoji_dropdown component
along with some utility functions to display
a very limited number of emojis.
As discuss now has a feature-full emoji picker
we aim to take advantage of it by bootstrapping
the picker from the existing components,
using a new javascript model for the
insert/update logic
AFTER THE CHANGE:
Users should be able to select the same emojis
they can use in the discuss chat in all fields
that previously featured an emoji picker.
Such as the livechat bot responses,
social posts, mailing subjects and
the sms message composer.
RELATED CHANGES:
Some tests are updated to use the pyEnv testing
'framework', as we now need to have access to
the messaging service to test these fields.
emoji_mixin is modified to match any emoji
character. The mixin is consolidated into
a single function is actually called anymore.
The text to emoji dict from emojis.js is removed
as it is no longer relevant where it was used.
The fields that used the emoji_mixin will no longer
trigger onChange on inserting an emoji.
However both the input and keydown event are fired
to allow fields using onchange_on_keydown
to trigger the onchange.
The emoji button was turned into an actual button
replacing the original span used in these fields.
This required a different approach to styling as
buttons inherently behave differently than spans.
The button is now moved using an empty div next
to the input and absolute positioning.
Most of the code used for char and text emoji
fields is consolidated into emojis_field_common.
task-3035021
closesodoo/odoo#104799
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Add the Coa and tax data for the peruvian
localisation (in english with translations)
closesodoo/odoo#104073
Task: task-2774275
Related: odoo/enterprise#33183
Signed-off-by: Julien Alardot (jual) <jual@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit, when resizing window so that chatter swap
position, the text content of message disappeared.
This happens because OWL re-render the message view as completely
different DOM elements, while modeling in discuss code kept
identity of the MessageView. As a result, the message text content
was unchanged therefore it was not updated in the DOM, thus staying
blank.
This commit fixes the issue by enforcing setting the message text
content in DOM whenever the value is empty in DOM but the message
has logically some text content.
closesodoo/odoo#106978
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Since [1] when the search bar was refactored, images can be displayed in
the autocomplete results, and fallback icons are displayed instead of
images for records that have no images.
However, if no module that participates in the results provides actual
images, then the fallback icons are not displayed at all.
This commit makes the fallback icons displayed only based on the "Image"
toggle option of the search bar.
It also disables the hidden display options and enables the visible
ones.
Steps to reproduce:
- Do NOT install website_sale (which is currently the only module that
provides autocomplete results with images).
- Drop a "Search" block.
- Save.
- Type a single letter in the search box. (e.g. "a")
=> Autocomplete results were displayed without their icons.
[1]: https://github.com/odoo/odoo/commit/7559626c54e34b41e1549e28276a650accec6986
task-2951026
closesodoo/odoo#106953
X-original-commit: 4eecba4c8f5327fd1a137a8d88574c2b6a5eda05
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The tooling has been introduce in later version of odoo.
It is a problem when somebody switches to older branches without
disabling the tooling as it would then try to commit the tooling config
files.
We just add a few lines in the gitignore to prevent this issue.
closesodoo/odoo#106951
X-original-commit: b469295c884026caea1b7779e7ffb778e7a08ab3
Related: odoo/enterprise#34552
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Steps to reproduce:
1- install ecommerce - payment_stripe
2- configure stripe testing credentials
3- edit main currency to have more decimal places (assume 4 instead
of 2 for USD)
4- add product p to cart (assume p.price = 100 USD)
5- checkout with stripe
6- the price is 10,000 USD instead of 100 USD
Bug:
Stripe expects the amount in the smallest unit possible for the
currency. https://stripe.com/docs/currencies#zero-decimal
This differs from a currency to another according to
https://en.wikipedia.org/wiki/ISO_4217#Minor_unit_fractions
`to_minor_currency_units` uses the decimal places of the currency by
default which will produce wrong values
Fix:
use currency exponent table built from
https://en.wikipedia.org/wiki/ISO_4217#Minor_unit_fractions
default behavior (for a currency that is not available) is not changed
OPW-3058173
closesodoo/odoo#106936
X-original-commit: 703ed2b4e162ff0a7b621e3cf8b92b8eb7fddff8
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Previously, _intervals_duration (called by _compute_duration)
sometimes loose the last mrp.workcenter.productivity.
A fix has been made.
First, mrp.workcenter.productivity.loss _convert_to_duration
calculates according to the loss type, we have to take that in account.
Second, mrp.workcenter.productivity _close badly generates
performance timers.
For example, test_mrp_employee_analytic_account generated
- productive for 1st employee from 10:00 to 11:00
- performance for 2nd employee from 10:00 to 11:00
- performance for 2nd employee from 11:00 to 11:00 (! duration = 0)
Now, the timers are
- productive for 1st employee from 10:00 to 11:00
- productive for 2nd employee from 10:00 to 11:00
which is correct.
closesodoo/odoo#106908
Task: 2985735
X-original-commit: 8638ec145ab83e4afafa39a5c9e987e8d772bfd1
Related: odoo/enterprise#34533
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Jean-François Aubert <ajf@odoo.com>
Fix workorder times problems:
- sum in workorders list view
(displays numeric value rather than mins:secs)
- timers sometimes starts at -00:01
- almost all tablet view actions reset the timer (click burger, ...)
- clicking pause stops the timer at the next second
- seconds are lost in employee timers
Task: 2985735
X-original-commit: 7dceef12771890f9fb9fa554e70414c622053ced
Part-of: odoo/odoo#106908
This commit adds tracking to the "plan to change car" field in res.partner.
task-3086287
closesodoo/odoo#106845
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Add an ACL to allow read-only access for basic users to the workcenter
capacities. This avoids an error in the bom overview opening with a
simple MRP "user".
closesodoo/odoo#106935
X-original-commit: 3095eb4d39711260b483771f04f0904d7f7a245a
Related: odoo/enterprise#34545
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Take the following BoM :
Final_product
Semi_final_1 (Subcontracted)
Component_1 (Dropshipped to subcontractor)
Semi_final_2 (Manufactured by us)
Component_1 (Bought then put in stock)
Component_1 is used in both semi_finals, but in different contexts. For
Semi_final_1, it's directly dropshipped to the subcontractor, while for
Semi_final_2 we resupply our stock and then use it from there.
Problem is, since both components are the same, there was no distinction
made when fetching the data for the resupply methods. So if the first
case encountered was the dropship (like here), then for Semi_final_2 the
dropship would be used as well, while we're not in a subcontracting
context anymore.
Now we consider the parent_bom when fetching and storing the resupply
data, as different boms can have different contexts.
Part of task-2985735
X-original-commit: 9ceb6b4f5996f962689ea671ea79ba81deeee763
Part-of: odoo/odoo#106935
Before this commit, the rules were checked related to the currently
selected warehouse. Doing this didn't allow to check the subcontracted
locations for their related rules (like Drophip subcontractor on order).
The point here is that when no rules are found within the warehouse, it
checks the subcontracted location of the parent if the parent is
subcontracted itself.
Part of task-2985735
X-original-commit: feeef868093042ae4cb788d513c02244b8c36623
Part-of: odoo/odoo#106935
Before this, when working on a bom with variants, when checking the
parent from the component / child_bom, it would always take the first
variant since it used the bom's product_template.
This could lead to incorrect data when working with subcontracting, as
when another variant from the first would be selected, when fetching
quantities no parent info would be found as it would seek info from the
first variant of the bom instead of the correct one.
By doing this, we can now have the right variant and fetch the right
informations.
Part of task-2985735
X-original-commit: c855038c73e2c964ef78b41090c35e3a07d30f9b
Part-of: odoo/odoo#106935
Since the pager div doesn't appear anymore in the DOM when it would be
empty, the filters buttons (warehouse and display) would be pushed back
to the end of the flex div.
Part of task-2985735
X-original-commit: 4ee3875a6d6faf5563c720fa399eca5b4a1d0e4f
Part-of: odoo/odoo#106935
The group `“base.group_user”` is added in the view for the field
`standard_price` while it is already set on the python side:
https://github.com/odoo/odoo/blob/16.0/addons/product/models/product_template.py#L76
this causes an issue in the case of a product with variants,
the invisible attrs is ignored, the `standard_price` and
`uom_name` field are hidden, but the label will still be displayed
opw-3076827
closesodoo/odoo#106925
X-original-commit: 206e88b0ad9fdb6e1767c93b3eca8feeecddd3da
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
When the contract has a working schedule different
from the employee's, a red triangle appears with a tooltip
explaining the reason. That tooltip was implemented in the
arch view using data-tooltip, which is not intended.
This commit adds an owl widget replacing that issue.
In order to test that tooltip warning, it's only needed
to go on any running contract and change the resource_calendar
so it's different to the one on the employee's page.
Same process on the employee form.
closesodoo/odoo#106760
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Steps to reproduce the bug:
- Enable “package” option in the settings
- Create a storable product “P1”
- update the stock to 100
- Create a picking:
- product : P1
- Qty: 1
- operation type: delivery
- go to additional info > add a carrier
- Mark as todo
- update the qty done to 1
- Create a second picking with the same steps
- Create a batch picking:
- Add the picking 1 and 2
- Confirm
- Go to “Detailed operation” tab
- Click on “Put in pack”
- add a “Delivery packaging”
- Save
- Click a second time on “Put in pack”
- Select the same “Delivery packaging”
- Save
Problem:
Traceback is triggered: “tuple index out of range”
When the “Put in pack” button is clicked, the “action_put_in_pack”
function is called, the move_line_ids which has no package or with
a 0 quantity done are filtered, in this case the 2nd move_line with
the product “P2” will be used, but the `_pre_put_in_pack_hook` function
is not called with its picking:
https://github.com/odoo/odoo/blob/14.0/addons/stock_picking_batch/models/stock_picking_batch.py#L229
But rather with the first picking, it will have no move_line because the
first move_line already has a quantity done at 1 and a package.
So we try to get a record in an empty array:
https://github.com/odoo/odoo/blob/14.0/addons/stock/models/stock_picking.py#L1312
opw-3067921
closesodoo/odoo#106943
X-original-commit: 1b6208a2db00ed387bcd0833787fa05416a426ba
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
In the 2022 Tax report, box 16: 'Total de la TVA brute due (lignes 08 à 5B)'.
The formula is missing tags P1, P2, I1 to I6.
opw-3036679
closesodoo/odoo#106948
X-original-commit: 67a4538e4c9ff3c2df895dfd43843154af728997
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
This commit fixes a non-English line of the Portuguese tax report.
Moreover, it also adds `l10n_multilang` as a dependency of the module such that the CoA can automatically be translated to Portuguese if the user chooses to without installing it manually.
closesodoo/odoo#106929
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Before this PR, posting a message containing an attachment with a long
name in the chatter would result in the chatter overflowing the main
window. This is due to the fact that flex items cannot be smaller than
their content.
This PR fixes the issue by adding the `overflow-auto` class to the
chatter container in order to override the default `min-width: auto`
of flex items thus allowing them to be smaller.
closesodoo/odoo#106927
X-original-commit: 73fb78e75b6126586385ea7621b6d71fae715305
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
- Settings > manage languages > english > Set time format to `%H:%M:%S %p`
> Save
- Install Planning app > go to list view > Try modifying a time manually
(without using the widget which pops up).
Issue:
When trying to save the new time, an error pops up: `Can't include meridiem
when specifying 24-hour format`.
While parsing the new date, the `luxon` library throws this error to
prevent wrong hour values, such as `17 AM`.
Fix:
Prevent the user from inputting both `%H` and `%p` in the same time format
and display a warning notification.
opw-3038797
closesodoo/odoo#106926
X-original-commit: c2b8faa1c89dc16094c1ebec397e935a3b46fac4
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Stefan-Calin Crainiciuc (stcc) <stcc@odoo.com>
Current behaviour:
Changing the package quantity may change the package type,
leading to an incoherent product quantities in the SOL.
(For ex: 20 uom in 2 packages of 20)
Expected behaviour:
When setting the package quantity, don't change the
package type. If the user wants to change the package type
they can do it by manually setting it or changing the product_uom.
Steps to reproduce:
- Install Sale and Inventory
- Activate Packages in settings
- Create 2 package types for a product of choice, one of 10, another of 20
- Create a new SO with that product
- Set the quantity to 10 (a new package_qty=1 and packaging type of 10 should appear)
- Save
- Edit package_qty to 2
- Observe that we have 20 units of the product, 2 packages of 20,
instead of 2 packages of 10
Reason for the problem:
When setting the `product_packaging_qty`, the `product_uom_qty` compute is triggered.
When `product_uom_qty` changes, it triggers `product_packaging_id`'s compute.
When `product_packaging_id` is computed, it doesn't trigger `product_package_qty`,
because it is protected, since we are writing to it.
Fix:
When we are writing the `product_packaging_qty` and the `product_uom_qty`
we remove the compute for `product_packaging_id`.
Affected versions:
- saas-15.2
- saas-15.3
- 16.0
- master
opw-3010703
closesodoo/odoo#106924
X-original-commit: acfa94b7aeea9f8efdc1886b094697ae3f0f1d2a
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
The comment became outdated:
- For 14.0 and above: mentioned the "Customize dialog" which does not
exist anymore.
- For 16.0 and above: mentioned "Bootstrap 4" instead of "Bootstrap 5".
Related to opw-3056683
closesodoo/odoo#106916
X-original-commit: fe90329ee32f9608c143a9fd658fe2a00712f9e4
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since odoo/odoo@69c3d5aa25
the readonly and required modifiers were no longer passed
for non-editable views. Which means:
- kanban: never passed,
- tree: passed only when `editable="1"` or `multi_edit="1"`,
- form: always passed.
The rationale behind that is that a view which is considered
as readonly doesn't need to know if its field are readonly or required,
as by definition, if the view is readonly, the user shouldn't
be able to modify anything in the view.
This was to make the views sent to the web client more light-weight,
not sending unused information, and save KB of transfers.
However, some widgets, used in the kanban and non-editable tree,
allow to modify fields, even in readonly considered views,
and therefore need to know these readonly/required modifiers
from the field definition in the Python model.
e.g. the `widget="color"`, odoo/odoo#103478
Ideally, these readonly/required modifiers should be transferred
only when the widget requires it, to avoid transferring the
readonly/required modifiers
when they are not useful in kanban/tree views
(which is 99% of the time).
However, this would require a bigger refactoring,
which is considered too risky compared to the added value
for a stable release.
task-3013110
closesodoo/odoo#106838
X-original-commit: 5a68d254949f1d0ff545023cfd14890efff10f5f
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
This commit:
- Adds the placeholder `Non-billable` on the sale order line
- Hides the sale order line if the project is not allow_billable
task-2893556
Part-of: odoo/odoo#96330
In this commit, modify the test to avoid searching the contract if
hr_contract module is installed before this hr_timesheet module.
task-2893556
Part-of: odoo/odoo#96330
In this commit, the approver word is used instead of a manager because someone
else approves the timesheet.
Technical:
Modified the field name and some strings.
-reminder_manager_allow -> reminder_approver_allow
-manager -> approver
task-2893556
Part-of: odoo/odoo#96330
Release notes: https://github.com/odoo/owl/releases/tag/v2.0.2
- fix: compiler: do not look up ComponentNode in the context
- fix: t-model takes precedence over t-on-input
- fix: reactivity: fix issues with reactive objects in proto chain
closesodoo/odoo#106898
X-original-commit: a86a8544883aaaf5d530320c84706dde35d17ef6
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
With this commit datetime of stock move are correctly converted with the current timezone.
closesodoo/odoo#106886
X-original-commit: 242da76b2763d5add36da6e23d4b1f7e640c72aa
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
## Steps to reproduce
1. navigate to Settings -> CRM -> Lead Enrichment section
2. change the Lead Enrichment option to "Enrich leads on demand only"
3. click Save button
4. wait for system to save and refresh.
You should see that the change you made was not saved.
opw-3063639
closesodoo/odoo#106891
X-original-commit: 0803775e4a156aa6988453edbbaf799730c996b2
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Purpose:
Make the command palette easier to discover - indeed, unless you
know about CTRL+K, it's difficult to know you can use that elsewhere
than the home screen.
Solution:
Add CTRL+K next to the Shortcut menu in the user menu.
closesodoo/odoo#106820
Tackid: 3074492
X-original-commit: 536ea340ec1347a4a7598b5b51e2f2801521973f
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Georis François (fge) <fge@odoo.com>
Before this commit, when remaining hours is negative then it the
label was displayed as muted instead of danger.
So in this commit, display the label danger when remaning hours
are negative.
task-3014420
closesodoo/odoo#106815
X-original-commit: c06aa5331eda0408453552a304170ee0bf027a4d
Related: odoo/enterprise#34504
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit, the progress bar was missing since the progress bar CSS
wasn't loaded to the project sharing webclient.
So in this commit, the progress bar CSS path has been added to the manifest file
for the project web client.
task-3014420
X-original-commit: 84caa0bb2f8a3095c4b98b35ab72f85fd456943a
Part-of: odoo/odoo#106815
Before this commit, missing borders of remaining hours in project sharing
kanban view.
So in this commit, added border and respected color boder classes like
'border-success','border-warning' and 'border-danger' on remaining hours.
task-3014420
X-original-commit: b73f3dd256d79cfb68432b73f13d5cf9e2d541ce
Part-of: odoo/odoo#106815
Nikunj Ladava