On large databases, the method `_compute_new_application_count` could
take up to 80% of the total loading time of the Job positions as each
job was generating 2 queries.
closesodoo/odoo#87862
Taskid: 2812400
X-original-commit: 147f6a933f106fea540bd62522b941a855fffda2
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Open a activity view(record modal), that will show records, clicking on the
'o_activity_btn' of a record will show dropdown and make sure that there are
many scheduled activity there .
Before this commit:
The dropdown was bigger than the record modal which had a scroll bar. It was not
scrollable properly and "+ Schedule Activity" button is not accessible.
After this commit:
The dropdown follows the scroll, and it will be possible to click the button.
Task- 2528111
closesodoo/odoo#87823
X-original-commit: 6436950bae7a8d0e3ec4a6eb83f42a3208a100d4
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Fixes a mistake from 0c468f6c2f160dec672bd25c673401b154b2709b where the uom
autocompletion was lost and adds a test to make sure it won't happen again.
closesodoo/odoo#87667
X-original-commit: 10bc8dc114511740d549dfc5261bc244e0a98ad9
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
When entering a date in a datetime field, it will be in the format
`08/01/2022 00:00:00`. If we place our cursor at the end of the
entry (after the hour) and each time we press enter, the timezone
offset is applied (so if offset is +1 it does +1 hour each time)
opw-2754116
closesodoo/odoo#87655
X-original-commit: 33e8540d64bb6e21debb7da9a121b706f551ab2e
Signed-off-by: Achraf <abz@odoo.com>
Previously, only one popup is allowed such that when one is not
yet close, but another one is requested, the new one will replace
the old. The function that tries to wait for the replaced popup
will never resolve resulting to some potential broken state.
This commit resolves the said issue which now allows multiple
popups at a time. We can use POS instance without demo as an
example.
Before this commit: The popup that asks whether to load the demo
products will be shown but it will be replaced by the cash opening
popup.
After this commit: The popup that asks whether to load the demo
products will be shown, then the cash opening popup will show.
When the user is done with the cash opening popup, the demo products
confirmation is shown next.
closesodoo/odoo#83661
Related: odoo/enterprise#23859
Signed-off-by: Masereel Pierre <pim@odoo.com>
In hr_holidays_attendance, the model that inherits from res.users adds a request_overtime field.
This field is used to allow the user to request overtime based on the total overtime.
The domain for the time off type includes has_valid_allocation. If the user doesn't have any allocation,
he won't be able to deduct extra hours
task-2701128
closesodoo/odoo#87845
X-original-commit: b6d186d7b46df1e0f4e0af3eb7c8e7b07909a040
Related: odoo/enterprise#25843
Signed-off-by: Kevin Baptiste <kba@odoo.com>
When using the widget res_partner_many2one (e.g. in the customer invoice
form view), the VAT number disappears when being in 'edit' mode.
This is caused by the '_getDisplayNameWithoutVAT' function, which was introduced
in PR https://github.com/odoo/odoo/pull/29189, because the VAT appeared in edit mode
but disappeared when saved at that time.
Since the VAT no longer disappears when saved, we no longer need this function
removing the VAT from the edit mode.
task-2749331
closesodoo/odoo#87843
X-original-commit: 78a5e53a99d9f0f04edf42f1ed8d713fda4de36e
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
https://github.com/odoo/odoo/pull/86101 introduced a check of the number of days
of the allocation when a time off is taken.
The _compute_from_holiday_status_id method search for allocations based on employee_id.
If a holiday has multiple employees, no allocation will be found and the validation error
message asking to split the request to fit in their number of days will appear
task-2812415
closesodoo/odoo#87818
X-original-commit: 2c4f4e4ec6b6b8a0f5233b589369e4aff70a3ca7
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Demo data to improve the flow of testing the edi. A bank account and a
partner with a street/city/zipcode/codice fiscale are required for the
edi, so having these as demo data is useful.
The demo company vat code and codice fiscale are also changed to those
of a valid company, so that they will be accepted by the sdi testing
environment. The address of the demo company is updated so that, if by
accident, an invoice is sent using the demo company, through the
official channel, the address will make it an obvious test.
closesodoo/odoo#87835
Task-id: 2809328
X-original-commit: f8da2dbedf948eaf86b92a0ac4ecd90acc811203
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
This commit removes the multilang feature on the /web/login/totp controller,
it doesn't really add value since it triggers a redirect and that the page is
all the same translated.
It is a good practice by default for SEO, but in this case it brings
some bug with the IOS apps that doesn't follow the redirect, while we don't
need to optimize this page for Search Engine.
The bug into the IOS apps, create a loop when we request the totp screen.
Device request /web/login/totp
Server ask a redirect to /fr_FR/web/login/totp
Device redirect to /web/login/totp
Server ask a redirect to /fr_FR/web/login/totp
...
closesodoo/odoo#87810
X-original-commit: 4dea1b9b7cf0855095f9cfa37ff6a9a6db7cf55e
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Jérémy Kersten <jke@odoo.com>
Have 3 moves named 0, 1 and 2
Delete move 1 to make a hole.
Resequence, starting the sequence at 2.
Expected: new names are 2 and 3
Result: an error because 1 is renamed to 2 but 2 still exists, leading
to a (temporary) duplicated name, which is not allowed.
We clear all the names to be resequenced before doing it in order to
avoid that.
closesodoo/odoo#87836
X-original-commit: bf5173f64582e2675f4121122ce26cb57624e08a
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Purpose
=======
The goal is to review the information displayed in the project updates side panel and also completely review the project profitability calculation.
It will try to better cover the use-case of companies working by an offer by project. For instance, one of the companies we are working with maintains and repairs engines. Once they receive the engine from another company, they will evaluate the state of the machine and determine what it would take to repair it (parts to order, parts to produce, workforce etc.). Each engine has its unique requirements. The company has to determine whether it is profitable for them to repair the machine or not.
Before these changes, the side panel of the project updates does not allow that analysis for a two main reasons:
1. There are no details on the allocation of costs, revenues and budget. (What it makes a deal breaker exactly: is it because a part is very hard to find and thus very expensive to purchase? Is it because the worker spent 10 hours on the repair instead of the 2 estimated?)
The only option the user has is to open each stat button individually. This process is tedious and annoying.
2. There is a confusion between the gross and the net margin, and neither of them are a true reflection of the margin the company can expect.
The gross margin only takes into account AALs generated by invoices or vendor bills. This doesn't allow any kind of future estimation because it doesn't take into account sales or purchases that were already made, but not invoiced/billed yet.
The profitability report still provides insights of an unrealized margin, but it is hard to understand where the numbers come from and it doesn't take into account records others than SOs and expenses. It is thus not complete either.
Furthermore, the sold section representation is not perfectly clear, it could be the amount delivered or invoiced compared to the amount that was sold. Finally, the design of the `Total Sold` section is confusing and the information under that section is a bit redundant with the previous one.
## Implementation details
### Review the Sales section
The Sold and total sold sections have been replace Sales one. This new section will displayed all SOLs from SOs linked to the project. Each line will represent:
- the name of the SOL,
- the ordered quantity (`product_uom_qty` field),
- the delivered quantity (`qty_delivered` field),
- the invoiced quantity (`qty_invoiced` field).
The name will be clickable to see either the timesheets linked (if the product is a service) or the stock moves linked if the user has the sales: own documents access right level and he is assigned to the SO, or if he has the sales: all documents access right level.
This section will only visible if the project is billable (=`allow_billable=True`).
### Review the profitability section
In this section, the project profitability report has been removed to search the data in each model related to correctly compute the project profitability and also to get the records impacting the profitability.
This section replaces the `Profitability forecast` one and will be design like 3 tables:
1. a table representing all the revenues found for the project. Each row will correspond to a invoice type with the untaxed amount to invoice, the untaxed amount invoiced and the total amount expected for this section (invoice type). Here if the list of *sections*
1.1. timesheets (fixed price)
1.2. timesheets (billed on timesheets)
1.3. timesheets (billed on milestones)
1.4. materials
1.5. expenses (reprensents the reinvoice expenses)
2. a table representing all the costs found for the project. Each row will correspon to a invoice type with the untaxed amount to bill , the untaxed amount billed and the total expected for this section (= invoice type). Here is the list of *sections*:
2.1. timesheets (fixed price)
2.2. timesheets (billed on timesheets)
2.3. timesheets (billed on milestones)
2.4. timesheets (non billable)
2.5. purchase orders
2.6. manufacturing orders
2.7. expenses
3. a table representing the margin of the project, 3 totals will be shown:
3.1. the result of the total revenues amount to invoice **minus** the total costs amount to bill,
3.2. the result of the total revenues amount invoiced **minus** the total costs amount billed.
3.3. thee result of the total revenues amount **minus** the total costs amount.
In the 2 first tables, each row name will be clickable only if the user can see the records related in that row, for instance the section 1.1 will be clickable only if the current user has access to the Timesheets app as Timesheet Manager. Moreover, if no data is found for a row then this row will not be shown.
### Additional changes in the right side panel
- remove the following stat buttons: hours recorded, billable time, expenses, manufacturing orders, work orders, gross margin.
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#87480
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
PURPOSE
This commit introduces a chatbot operator that works based on a user-defined
script with various steps.
SPECS
A im_livechat.chatbot.script can be defined on a livechat rule.
When a end-user reaches a website page that matches the rule, the chat window
opens and the script of the bot starts iterating through its steps.
The chatbot code is currently directly integrated with the existing livechat
Javascript code.
It defines extra conditions and layout elements to be able to automate the
conversation and register user answers.
AVAILABLE STEPS
A script is defined with several steps that can currently be one of the
following types:
"text"
A simple text step where the bot posts a message without expecting an answer
e.g: "Hello! I'm a friendly robot!"
"question_selection"
The bot will ask a question and suggest answers, the end-user will have to
click on the answer he chooses
e.g: "How can I help you?
-> Create a Ticket
-> Create a Lead
-> Speak with a human"
"question_email"
That step will ask the end user's email address (and validate it)
The result is saved on the linked im_livechat.im_livechatchatbot.mail.message
"question_phone"
Same logic as the 'question_email' for a phone number
We don't validate the input this time as it's a complicated process
(requires country, ...)
"forward_operator"
Special type of step that will add a human operator to the conversation when
reached, which stops the script and allow the visitor to discuss with a
real person.
The operator will be chosen among the available operators on the
livechat.channel.
If there is no operator available, the script continues normally which allows
to automate an "answering machine" that will redirect the user in case no
operator is available.
e.g: "I'm sorry, no operator is available right now, please contact us by email
at 'info@company.com', we will try to respond as soon as possible!".
(Or even something more complex with multiple questions / paths).
"free_input_single"
Will ask the visitor for a single line of text.
This text is not saved anywhere else than in the conversation, but it's still
useful when combined with steps that create leads / tickets since those print
the whole conversation into the description.
"free_input_multi"
Same as "free_input_single" but lets the user input multiple lines of text.
The frontend implementation is made by waiting a few seconds (currently 10) for
either the next submitted message or the next character typed into the input.
This lets visitors explain their issue / question with multiple messages.
Which is very useful since new messages are sent every time you press "Enter".
"create_lead"
Special step_type that allows creating a crm.lead when reaching it.
Usually used in addition to 'question_email' and 'question_phone' to create
interesting leads.
LINKS
Task-2030386
closesodoo/odoo#84000
Related: odoo/enterprise#24894
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Patrick Hoste <pko@odoo.com>
Co-authored-by: Aurélien Warnon <awa@odoo.com>
This commit adapts the "button_background_color" field default value from a
grey to a purple (the same color as the default header background).
The grey color makes the button look disabled, which is counter intuitive for
visitors as they will think the livechat is not active even though it is.
Task-2030386
Part-of: odoo/odoo#84000
PURPOSE
This commits adds a special step_type on the chatbot.script.steps that allows
creating a crm.lead when reaching it.
SPECS
In addition, we let the end user configure in which crm.team that lead will
land upon being created, making it possible to sort your leads based on
previous questions.
e.g: "In which country do you live"
And based on the answer, you assign to a different sales.team.
This commit comes with the necessary business code to make this feature work
as well as some extra testing methods that ensure it is correctly implemented.
Task-2030386
Part-of: odoo/odoo#84000
Co-authored-by: Patrick Hoste <pko@odoo.com>
Co-authored-by: Aurélien Warnon <awa@odoo.com>
PURPOSE
This commit introduces a chatbot operator that works based on a user-defined
script with various steps.
SPECS
A im_livechat.chatbot.script can be defined on a livechat rule.
When a end-user reaches a website page that matches the rule, the chat window
opens and the script of the bot starts iterating through its steps.
The chatbot code is currently directly integrated with the existing livechat
Javascript code.
It defines extra conditions and layout elements to be able to automate the
conversation and register user answers.
AVAILABLE STEPS
A script is defined with several steps that can currently be one of the
following types:
"text"
A simple text step where the bot posts a message without expecting an answer
e.g: "Hello! I'm a friendly robot!"
"question_selection"
The bot will ask a question and suggest answers, the end-user will have to
click on the answer he chooses
e.g: "How can I help you?
-> Create a Ticket
-> Create a Lead
-> Speak with a human"
"question_email"
That step will ask the end user's email address (and validate it)
The result is saved on the linked im_livechat.im_livechatchatbot.mail.message
"question_phone"
Same logic as the 'question_email' for a phone number
We don't validate the input this time as it's a complicated process
(requires country, ...)
"forward_operator"
Special type of step that will add a human operator to the conversation when
reached, which stops the script and allow the visitor to discuss with a
real person.
The operator will be chosen among the available operators on the
livechat.channel.
If there is no operator available, the script continues normally which allows
to automate an "answering machine" that will redirect the user in case no
operator is available.
e.g: "I'm sorry, no operator is available right now, please contact us by email
at 'info@company.com', we will try to respond as soon as possible!".
(Or even something more complex with multiple questions / paths).
"free_input_single"
Will ask the visitor for a single line of text.
This text is not saved anywhere else than in the conversation, but it's still
useful when combined with steps that create leads / tickets since those print
the whole conversation into the description.
"free_input_multi"
Same as "free_input_single" but lets the user input multiple lines of text.
The frontend implementation is made by waiting a few seconds (currently 10) for
either the next submitted message or the next character typed into the input.
This lets visitors explain their issue / question with multiple messages.
Which is very useful since new messages are sent every time you press "Enter".
LINKS
Task-2030386
Part-of: odoo/odoo#84000
Co-authored-by: Patrick Hoste <pko@odoo.com>
Co-authored-by: Aurélien Warnon <awa@odoo.com>
Currently, when inviting members to a mail.channel using the "add_members"
method, it is not possible to signal to web client to automatically open that
conversation in a chat window.
This commit adds a parameter to that method to allow that behavior, and also
slightly adapts the notification handling to open the chat window accordingly
on the web client side.
This is necessary for the upcoming chatbot, where we want to invite operators
to the channel and make them see the new conversation immediately.
Task-2030386
Part-of: odoo/odoo#84000
Currently, when adding members to a mail.channel using the add_members method,
we always post notification message on the channel mentioning that someone has
joined the channel / was invited to join by another user.
This commit simply adds a method parameter allowing to disable that behavior.
This change is necessary for the upcoming chatbot, where we want to add members
but handle the join notifications differently.
Task-2030386
Part-of: odoo/odoo#84000
Currently, when creating a partner, there could be a situation
in which a commerical field has some access restriction
due to `groups` being set on a the field declaration.
The `sudo()` makes sure it does not happen.
closesodoo/odoo#83205
Related: odoo/enterprise#25828
Signed-off-by: William André (wan) <wan@odoo.com>
The basic idea of this functionality is for users
to be able to put limits on Partners that would
trigger non-blocking warnings when trying to confirm new:
- Sales Orders
- Invoices
when that partner has too many open invoices.
task-2722165
Part-of: odoo/odoo#83205
In case you applied inventory in batch the system would create a lot of useless
stock moves and stock move lines.
closesodoo/odoo#87771
X-original-commit: 07f18f62db490608b316cc9482f228252ed8fc63
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Wolfgang Taferner <w.taferner@wtioit.at>
Current behavior:
In some particular cases bootstrap was throwing an error "Uncaught Error: Please use show on visible elements"
wich appeared on the users screens.
Steps to reproduce:
- Could only reproduce on copy of clients Db
- Go in CRM and go in any lead
- Create a new activity
- Swap to an activity with less fields
- Then quickly put your mouse on the top of a field that just disappeared
- The "Please use show on visible elements" error appears.
Here's a video where I reproduce it on clients Db : https://watch.screencastify.com/v/gksBwwF0McirZzSFwaAP
opw-2720853
closesodoo/odoo#87770
X-original-commit: 3404c9500fad4004d6d8beef6041ac51439078cd
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Current behavior :
When you delete a record (for example project.task), all the messages related
to this record aren't deleted.
This, in case a user has his notifications managed in Odoo, may prevent him
from accessing the History tab in the Discuss app because these messages are
linked to a record that doesn't exist anymore and it will raise a Missing Record
error
Steps :
*with demo data*
- Install Project
- Make Marc Demo notifications managed in Odoo
- Delete a task project to which Marc Demo is assigned
(*with Marc Demo*)
- Go to Discuss and try to access History tab
OPW-2764855
closesodoo/odoo#87732
X-original-commit: ee8feeb73c920827090b1a5ecf78e8b1d21bbae4
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Claude Thibault (thcl) <thcl@odoo.com>
Steps to reproduce:
1) start from a clean database (http_routing should not be installed).
2) go to the app menu and install project (don't install via `-i`!!).
3) traceback: `request` has not attribute `is_frontend` while rendering
a template.
The `is_frontend` attribute on request is set by the http_routing
module. At the moment the "install now" button is clicked, http_routing
was not installed so the `is_frontend` attribute was not set.
FF to the end of the installation: the registry is reloaded to include
the modules that have been installed, http_routing among them.
We are in a tricky situation: (1) there is a request, (2) http_routing
is installed and (3) the `is_frontend` attribute is missing from the
request.
This situation is illegal, when http_routing is installed, the
`is_frontend` attribut should always be set. In this work we reset the
missing attributes using sensitive default values via post-init hooks.
closesodoo/odoo#87684
Signed-off-by: Julien Castiaux <juc@odoo.com>
Improve a few things in accounts modules:
- Users wants to be able to change the account in the general ledger
list view
- Do not group by date by default when auditing a tax line.
- Make the currency fields only show in debug mode for accounts and assets
- Disallow to delete taxes linked to a tax repartition line, and
clarify the error message when trying to delete one linked to a
fiscal position's account mapping
Task id # 2810379
[IMP] account_*: some Back2Basics improvements
Improve a few things in accounts modules:
- Users wants to be able to change the account in the general ledger
list view
- Do not group by date by default when auditing a tax line.
- Disallow to delete taxes linked to a tax repartition line, and
clarify the error message when trying to delete one linked to a
fiscal position's account mapping
Task id # 2810379
closesodoo/odoo#87659
Related: odoo/enterprise#25770
Signed-off-by: Laurent Smet <las@odoo.com>
* = website
Change the wording of the sms reminder template to make it sound friendlier and
more complete. The sms will include the event address if it is defined.
Otherwise, it will link to the event page if website is installed.
A one line-formatted version of the venue is added to the model to be used in
the template and other places.
This required to update `event_registration.get_date_range_str` to not include
the time when describing an event happening more than a month from the current
date, which makes sense as there is no reason to specify the time only in that
case, and we add the time somewhere else when it's useful anyway.
For consistency, Wembley Stadium is updated to London timezone in the demo
data.
Task-2777183
closesodoo/odoo#85664
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Skip the confirmation step when wanting to get rid of a notification
for emails, sms or letters that were not sent.
Technical:
- All 3 wizards to confirm the discarding of the notification have been removed
(the ones for mail, sms and letter) have been removed
- The method to discard notification has been centralized in MailThread
(notify_cancel_by_type in addons/mail/models/mail_thread.py)
- This centralization has been done as well on the client code as the same
server code is called whether it is a mail, a sms or a letter
(in addons/mail/static/src/models/notification_group/notification_group.js)
- Existing front and back test have been adapted
- A test of notify_cancel_by_type for mail has been added
(addons/test_mail/tests/test_mail_management.py)
- add missing author_id in mail_notification demo data
Task-2752190
closesodoo/odoo#84452
Related: odoo/upgrade#3246
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
A reorganization of the calendar alarm form view was necessary for easier
extension with new fields
(such as the one from appointment, see links).
The partner is now the author of notifications about their invitation
(instead of public user).
Task-2709580
See odoo/enterprise#23191closesodoo/odoo#82387
Related: odoo/upgrade#3383
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
- Create a fiscal position [FPOS]
- Assign [FPOS] to a customer [DEMO]
- Add [FPOS] to the available fiscal positions of POS
- Open pos session, add a product, select [DEMO], [FPOS] will be
automatically selected. Confirm order and pay
- Click on refund button and select the previous order
[FPOS] will not be automatically selected for the refund order
opw-2799179
closesodoo/odoo#87503
X-original-commit: 4f8e257f2fc8e3d505342f9e1d6cb243a25e83e2
Signed-off-by: Masereel Pierre <pim@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Before this commit, the order of rows shown in costs and revenues is not
fixed and depends on the order of the modules.
This commit adds a sequence on each row and then sort the rows to fix
the order of those rows.
task-2710808
Before this commit, the components created and used in the right side
panel are components for the `project.milestone` and we cannot reused
some components for another context.
This commit refactors a little bit to create a parent component with the
common code useful for another components than `project.milestone` ones.
task-2710808
Before this commit, the domain used to find the SOLs inscreasing the
revenues of the project is fixed, so it is not possible to override the
domain without rewriting the method which computes the revenues from the
SOLs linked to the project.
This commit adds a hook to easily modify the domain used.
task-2710808
Before this commit, when all projects in `self` have no AA set, the
`read_group` used to `_compute_expense_count` is called. However, if AA
is in projects in `self` then `expense_count` field is always equal to
0 for each project because the link between the project and the expense
is made with AA.
This commit checks if at least a project has a AA set before calling the
`read_group` otherwise `expense_count=0` for all projects contained in
`self`.
Before this commit, the label is giving with the data computed for the
project profitability.
This commit separes the label with the data to avoid translating many
times the same things.
task-2710808
Before this commit, the Manufacturing orders are displayed in the costs
but the user sees which MO impacts the costs of the project
profitability.
This commit adds an action to allow the users to see all the MO related
to the project. However, the MO section will be clickable in the project
profitability only if the user has access to the MO.
task-2710808
Before this commit, the project profitability shows the total due to the
purchase orders linked to the project. However, the user cannot easily
sees which purchase orders impact the project profitability.
This commit adds an action to see all purchase orders related to the
project. However, the 'Purchase Orders' section in the costs will be
clickable only if the user has access to the purchase orders
task-2710808
Before this commit, the project profitability takes into account all
timesheets related to the project but the user cannot see which
timesheets for which row in the revenues or costs for a project.
This commit adds an action for each row containing timesheets to
correctly see which timesheets are found for an exact row. For instance,
the user will be able to see all timesheets for the 'Timesheets (Non
Billable)' row. The name of each row will be clickable only if the
user has access to the timesheet app.
task-2710808
Before this commit, the materials row displayed in the revenues of the
project profitability in the right side panel shows only the result of
all SOLs containing a material product. The user cannot see which SOLs
give that result.
This commit adds an action to see all SOLs related to that row. If the
user has access to the Sales app then the name in that row (that is,
'Material') will be clickable to redirect the user to the view of SOLs
found for that row.
task-2710808
Before this commit, the expenses inscreasing the revenues or the costs
in the project profitability are not visible for the user because he can
just see the result and not which expenses are related to that result.
This commit adds the action to see the expenses related to the revenues
that is, all expenses reinvoiced to the customer for that project or the
expenses related to the costs of the project. However, the user needs to
have access to the expenses to access to the action, otherwise the name
section is not clickable.
task-2710808
Before this commit, the expense costs are not clickable to see the
expenses impacting the project profitability in that row.
This commit adds the action to allow the user to click on the name on
the row to see all the expenses related.
task-2710808
This commit adds a generic method for all sections in the project
profitability to get the correct action based on the which section the
user clicks. Moreover, a new parameter is added into
`_get_profitability_items` method to add the action data in the
profitability items or not. This parameter will be useful for the unit
tests.
task-2710808
Fabio Barbero