*: account,event_sale,fleet,hr_attendance,hr_contract,hr_timesheet,
im_livechat,point_of_sale,project
When the user tries to delete a record(s) from the reporting views, this
traceback will be generated.
Steps to produce (Example only):
- Settings > Technical > Actions > Window Actions
- Search for the Work Entries Analysis. Open it and add a 'tree' as view_mode
in that action.
- Payroll > Reporting > Work Entries Analysis menu and select the tree view.
- Select one or more records and try to delete these records.
Error: A traceback appears: "cannot delete from view "hr_work_entry_report"
Handled the unlink access by using their model access of the reporting models.
similarly, this issue resolves in other reporting models.
Sentry-3975590063
closesodoo/odoo#125697
X-original-commit: 209d8c76ce9bb1d6cc7084d55b5623e939af8fbc
Related: odoo/enterprise#42825
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
THese are rarely intended for all users but often intended only for
employees.
account:
account.incoterms: only used within internal business models
account.journal.group: same as account.journal, add sudo in computed field
account_edi: need access to accounting objects
base_address_extended:
res.city: only employees should access address data
board: only employees uses this (old) module
crm:
crm.stage: internal users business object
hr_recruitment: employees can read
im_livechat: apply same as for the steps
l10n_ar: used on partner, not only invoices
l10n_ec: accessed only through account.move
l10n_latam: accessed on res.partner
mail:
publisher.warrenty.contract: no data, only static models
mail.channel: group_user has already his own rule
mail.group: group_user has already his own rule
mail.message.subtype: group_user has already his own rule
mail.message.all: remove, already has a portal and employee rule
partner_autocomplete: no interaction with public
project:
project.tags: only needed for project sharing
sale_management:
sale.order.option: same as sale.order
utm: employee already has write access
web_editor: test models that have nothing to do here
web_tour: only employees uses tours
website_sale:
product.ribbon: add sudo for access
base:
ir.default: only employees uses set (could probably be converted to group_system)
ir.ui.view.custom: same as ir.ui.view, add sudo when needed
report.*: portal users don't configure reports
res.users.log: create in sudo, no access needed (adapt test to use another model)
res.lang: still needed for public
closesodoo/odoo#118701
Related: odoo/enterprise#41285
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This commit (and its enterprise equivalent) purpose is to smooth the
user experience and remove unnecessary steps.
The commits:
- Remove all stat buttons except the status and collaborators one from
the project edit form.
- Add multiple small changes to string/name fo fields in views
- Change the custom O2M widget for a standard M2M for the management of
child tasks
- Add the milestone field to the portal page of shared project.
- Remove the wizard 'marked_as_reached_milestone'
- Add the automatic generation of milestone when a SO is confirmed if
some SOL need it
task-2941835
closesodoo/odoo#98546
Related: odoo/enterprise#30628
Related: odoo/upgrade#3798
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Purpose of this commit to improve generic usage of project app.
So in this commit done following changes:
- when deleting a project, delete all of its tasks in the process instead of
raising an error
- make the list view editable bottom
- add a 'view task' button to open the task form view
- the 'download' and 'print' buttons should be centred
- rename 'planned hours' into 'allocated hours' (or 'allocated days' if the
timesheet encoding unit is in days)
- when a project is linked to an SO manually, he should appear in the
'projects' stat button of the SO; same goes for tasks
- remove the 'profitability' setting
- display the SOL and the quantity in red as well if the milestone hasn't been
reached yet for update right side panel
- add a project field for quickcreate in kanban view
- 'fa-check-square-o x/y' in muted on the project kanban cards
task-2838372
closesodoo/odoo#92262
Related: odoo/enterprise#27758
Related: odoo/upgrade#3561
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Before this committ:
- Stats buttons were hidden when records are zero
- Some wordings were insignificant
- Existing filters don't allow us to check blocked, blocking and tasks soon in overtime and some other information
- Product form fields need some changes in their order
After this commit:
- All stats button are displayed when records are zero
- Wordings fixed
- New filters added to check blocked, blocking tasks and tasks in overtime soon
- Fields were rearanged
task-2726465
closesodoo/odoo#82253
Related: odoo/enterprise#23257
Related: odoo/upgrade#3185
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Before this commit, when the user changes the stage of a task linked to
a milestone, he cannot know if after that task, there is another one
before reaching the milestone related.
This commit displays a wizard to allow the current user to directly
mark as reached the milestone when the user changes the stage of a
task linked to a milestone to a closed stage and all tasks linked to
that milestone are done too. However, if the milestone is already
reached, no wizard will be displayed.
task-2829542
Before this commit, the portal user can read the `project.update`
and `project.milestone` records but there is no reason to grant this
access for those models.
This commit removes the read access for thoses models since we don't
show the data in its portal.
X-original-commit: f0331531826974ddaab5dff28739115c37a351c0
Forward-port-of: #88546
Forward-port-of: #88509
Part-of: odoo/odoo#88819
* hr_timesheet_{attendance}, project, rating, sale_timesheet
- removed the 'admin' group on the reporting menu items so that 'users' can
access these menus.
- 'timesheet / attendance' menu should only show if user has access for both
the attendance and timesheet.
- Project/User should access 'Task Analysis' report And Added rule for user.
- customer ratings: only show ratings which has access of their project/task.
- ratings: user should not able to edit ratings.
task-2467564
closesodoo/odoo#82634
Related: odoo/enterprise#23439
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Co-authored-by: Priyanka Kakadiya <pka@odoo.com>
Purpose of the commit is to improve the generic UX of task
and project views.
task-2590412
closesodoo/odoo#75509
Related: odoo/enterprise#20423
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Before this commit, when a project user wants to see the project form
view, he has an access error because he does not have any access to
`project.collaborators`.
This commit adds `ir.model.access` to give read access to the project
user to `project.collaborators` model.
task-2692587
closesodoo/odoo#79899
X-original-commit: 012b014d0b95f10f7b512ac547b166e28bf32b65
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
* = hr_timesheet, sale_project, test_main_flows
Smaller changes:
- Projects created on the fly (through `name_create`) will now come with a
default `new` stage in order for them to not be empty.
- Removed task auto assign upon creation besides in FSM's 'My tasks' menu.
- Allow the reordering of projects without needing to group by
anything.
- Make `project.task`.`description` and `project.tags`.`name`
translatable.
- Disable the creation of records in the view when clicking on `Tasks
in recurrence` stat button.
- Track the planned date of the task in the chatter
- Disable the creation of records in the view when clicking on
'invoices' stat button and add the kanban view to that action.
- Make milestones completely available to regular project users.
- Remove the 'Documents' button in the project's kanban settings menu.
- Add kanban, pivot and graph views to the 'Hours Recorded' stat button
on projects
- Add the calendar view on the 'Hours Forecast' stat button on projects
- The 'Sales Orders' stat button on the `project.project`'s form view
will now display the amount of sales order linked to the whole
project. So the one linked to the project itself if it exists + all
the tasks. It will also open them, form view if 1 else list view.
- Fix a typo in the settings 'projets' => 'projects'
- The analytic account of the project will now be assigned to the
sales order when a task is created through the 'Create a task in an
existing project' option.
Changed the portal task view to include a sidebar similar to sales
orders, with a simple menu leading to different parts of the screen.
Changed the `project.task` 'rating' stat button:
- The icon will now represent the latest review.
- The action will directly lead to the record's form view if there is
only 1 rating.
- Make some fields readonly in the form view.
- Display the % of satisfaction instead of the number of ratings.
Reorder all stat buttons on the `project.task` form view in this order:
- Products, Worksheet, Sales Order(s), Invoices, Ratings, Hours
Forecast, Parent Task, Tasks in recurrence, Tickets, Quotations and
lastly Customer Preview
Make the status of the project editable directly through the kanban
view. A new widget has been added to handle that properly. When editing
the status through that means, a `project.update` will be created with
the current date and the appropriate status. In addition to that a new
status has been added (only on `project.task`, not `project.status`)
namely `to_define` in order to differentiate new and running projects.
Projects now start with the `to_define` status.
The `project.project`'s rating stat button has been changed in the
following ways:
- The icon will now change in function of the satisfaction percentage,
smile above 66%, meh between 33% and 66% and frown below 33%.
- The color will also change depending on the rate, smile is green, meh
is orange and frown is red.
- The ratings will now be in function of the last 30 days instead of
all time and the action will also filter on those 30 days.
- Change the action name from 'Rating' to 'Ratings'.
`project.project` ticket stat button:
- Will now open the form view when there is only one record.
- Added the activity view.
- Disable the creation of new records.
- Rename the action to 'Tickets'.
Closes: odoo/odoo#75269
See: odoo/enterprise#20334
Task ID: 2611006
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Adds personal stages to tasks.
Users assigned to tasks will be able to have their own pipeline to
handle their tasks independently of the project's pipeline.
The assignee field on Tasks has also been changed to a Many2many to
support multiple assignees on one task.
The same table is used to store those information, essentially a triplet
(task, user, stage), to ensure that:
1) personal stages only apply to tasks to which you are assigned to.
2) synchronizing to make sure that you don't have a personal stage for a
task on which you are not assigned anymore.
Alongside those changes, some minor changes have also been made:
- Modified the task's tree view.
- Renamed the Tasks menu to 'My Tasks'.
- The default view is now the kanban view for the 'My Tasks' action.
- project_id is not required anymore, tasks with no project are
considered 'private', those tasks are only visible to those that are
assigned to it.
- Added tracking of both user_ids and depend_on_ids in the chatter.
Closesodoo/odoo#74087
Task ID: 2398734
Before this commit, the project sharing feature is enabled by default
when the Project app is installed but the user could never use the
feature and thus we add more access rights to portal user for nothing.
To avoid this, this commit removes by default all additional access
rights given by project sharing feature and adds this access rights only
when a collaborator is added.
If the user removes all collaborators for all projects then we need
to disable the feature. That is, we will remove the access rights and
ir.rule records added.
So, the feature will not really disable but we remove the additionnal
access rights and ir.rule records added with this feature.
task-2379518
closes#73341
This reverts commit fc7778f8c512202dc3361d6b87be8c28b299c3c8 because of
a change in the spec.
The access mode are removed and replaced by this access mode for portal
user:
- read: the user goes to the classic portal view
- edit: the user is added as collaborator of the shared project and can
access to project sharing views.
To do this, the portal share is inherited by the project share wizard.
This new wizard can be open to share in readonly and open to share in
edit mode via 2 buttons in the form view of the shared project.
A new stat button is added to form view of project to see the
collaborators of this project. That is, the ones can access to the
project sharing views. The project manager will can remove or also add
new collaborators via the views in this stat button.
task-2379518
closes#73341
Before this commit, when the portal user can access to project sharing
views, he can just read. If we just add ir.rule to allow the edition,
the portal could create/edit. We have to allow the project manager to
define the access rights of portal users when he want to share them a
project with the project sharing feature.
This commit adds 3 access modes portal users in project sharing views.
1. **Readonly**: the portal can only see the tasks in the different views.
2. **Comment**: the portal can use the chatter in task form view.
3. **Edit**: the portal user can create and edit tasks.
task-2379518
closes#73341
Co-Authored-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, the portal users can only see the tasks in the
project sharing views.
This commit allows these users can also create tasks and edit some
fields in task.
task-2379518
closes#73341
Adds new optional stages for the project.project model.
Previously projects would stay dormant when they were finished, we can
now define stages for those projects to determine where a stage is in
it's lifecycle.
Also adds some small changes to the project itself, such as adding tags.
Closesodoo/odoo#73648
Task ID: 2581575
Related: odoo/upgrade#2646
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
This commit adds project updates in project to take in stock the current
status of the project : which task or milestone changed in the past 30
days.
The project manager is able to add a status on the project update, and
edit the description of the update. There is also a chatter in which
he/she can discuss some points with other project users.
The description is build with informations retrieved from mail tracking
values or from project.* models. Those informations are collected in a
dict and rendered in a template to ease the inheritence in further
modules needs.
Following commits will add behaviour to handle those updates and
milestones in the various views. See PR for further information.
PR : #68899
task-2393768
Before this commit we have reports that depict the status of a
project at a certain point in time, but we don't have any reports
representing the actual progress of the project in time.
This commit adds a burndown chart, this chart would help users see
the evolution of the project and determine whether it is on the
right track or not.
task-2458017
Some interventions are done on a regular basis (e.g. maintenance of
fire alarms, safety inspections). Having tasks auto-generate would
facilitate the process and would ensure that the next intervention
isn't missed/forgotten.
closesodoo/odoo#55517
Taskid: 2172156
Related: odoo/enterprise#12246
Related: odoo/upgrade#1604
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, deleting a stage with tasks, the user received an
error.
With this commit, when deleting a stage containing tasks, a wizard
offers the choice to move the tasks to another stage.
closesodoo/odoo#46410
Taskid: 1869030
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose of this commit is to allow multi-create in alias mixin by correctly
creating / updating aliases in batch.
Task ID 1919277
Community PR odoo/odoo#41160
Enterprise PR odoo/enterprise#6983
Upgrade PR odoo/upgrade#872
Co-Authored-By: Rémy Voet <ryv@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
* Reword tasks in the sample project
* Add a "Create and Edit" button on the project creation modal
* Open the file chooser in "Set a cover image" if there are no images
set
* Correclty display the kanban state button on archived task
* Add a button to list the tasks when deleting a project
* Open file chooser for cover image: Automatically open the file chooser
when setting a cover image on a task if there are no attachments to chose
from.
closesodoo/odoo#47306
Taskid: 2209133
Related: odoo/enterprise#9141
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
For historical reason (problably the inheritS between project and AA, removed in 12.0), portal
user can read Analytic Account. This makes no sense, as it is a purely internal resource
for companies. Removing the access rights don't change anything for portal user and make
those data secure.
Task-1911581
When we remove the inheritS between project and analytic account, we move the
analytic_accound_id field in timesheet because it was the only use case for
a project to be linked to an analytic account.
This commit prepares new cost origin for a project (other that timesheet).
Register costs on project will required an analytic account to keep analytic
costs tracking. The analytic account management is now moved to project, like
it was in 10.0, but without the inheritS.
Task-1911581
This commit removes the inheritS between account.analytic.account and
project.project. This means :
- When a project is created, an analytic account is not necessarily
genareted
- project has now its own name, company_id and partner_id fields
- an analytic account can be linked to several project
- project module does not depend anymore of analytic, but hr_timesheet
does.
This change implied
- an analytic account is required on project to timesheet on
its tasks. So, when checking 'allow_timsheets', if an AA is not
provided at project creation, an AA will be generated.
- to timesheet on project, an active AA is required. We don't want
timesheeting on project linked to unused AA to avoid bad analytic
entries.
This prepare the fact a sale order can create multiple project, sharing
the same analytic account (the one from the SO).
First purpose of this commit is to limit access on activity types.
Employees can now only read activity types. Indeed defining or modifying
activity types should not be done by employees as it impacts daily work
of all other employees. Specific app-based rights are added for project
and sale managers. Those have a specific menu to configure activity
types, meaning they should also have the access rights to do so.
Also including :
* ease default computation for res_model_id of activity types: using
default_res_model in context it is possible to specify a default
res_model_id. It is useful for example to give a specific context
in configuration menus;
* add a domain on res_model_id field in order to limit it to models
inheriting from mail.thread and not being transient;
* various improvement in activity type form view to ease configuration
notably the # days renamed to planned in;
This report is too advanced and/or complex to be a single menuitem. Furthermore the model was a mess and a horn of plenty for bugs.
The class ProjectTaskHistoryCumulative inherits from the class ProjectTaskHistory, and create a view based on the same model.The orginal class defines a compute field 'end_date' which calls a compute method '_compute_end_date' that will either make a simple assignment or a SQL request if the columns is always opened or folded.
As ProjectTaskHistoryCumulative is declare with '_auto=False' the compute method will try to write on this table, which is obviously wrong because we are trying to write on a view.
This leads to erors when trying to edit a project stage like:
OperationalError: cannot update view "project_task_history_cumulative"
DETAIL: Views that do not select from a single table or view are not automatically updatable.
HINT: To enable updating the view, provide an INSTEAD OF UPDATE trigger or an unconditional ON UPDATE DO INSTEAD rule.
or when trying to delete a column which already contains some tasks.
So we removed this these models and view and replaced them by a simple favorite filter in the Tasks Reports
Split project to move portal features to a new module named website_project.
Portal users may now access their projects and tasks throught the
website_portal My account page. The Backend portal menuitem is removed.
Simplify the privacy settings of project, to be visible to portal users the
project must be in 'portal' mode.
Original authors: Vipul Bhatt, Florian Wintjens
Purpose:
Having the res_group defined in base and sales_team auto installed
with mail doens't make sense.
- Move the empty res_config class and the related view from
base_setup to sales_team (base_setup only contains the 'General Settings'
model and views
- Move the 'sale' related content from product to sale module (Access rights,
menuitems,...)
- Set sales_team at autoinstall False. The module is installed when needed by
crm or sale for example
- Set sales_team as a dependency of voip. (Access rights defined for configuration
purpose)
- Set sales_team ad a dependency of subscription (Access rights issue too)
[FIX] account: move some ir.model.access to sale module
[FIX] payment: Move some ir.rule to website_sale
[FIX] stock: move some ir.model.access rule to sale_stock
[FIX] project: Move some ir.model.access rules to crm_project_issue
[FIX] mrp: Move some ir.model.access rules to sale_mrp
[FIX] calendar: move some ir.model.access rules to crm
Rename xmlids accordingly. Example: 'base.group_sale_manager' becomes
sales_team.group_sale_manager.
[ADD] sales_team: See own documents => See only his sales team
Moved the "User: Own Leads Only", "User: All Leads" and "Manager" groups from sale and crm
into sales_team module. Add the record rules so that user can see only his Own Sales Team
if "See Own Leads" is sales right and can see all sales teams if he is having sales rights
of "See All Leads" or manager.
This branch need more testing instead of doing 10 fixes. A lot of issues are occuring
when installing modules in different orders.
This reverts commit fa6e415cdb.
Purpose:
Having the res_group defined in base and sales_team auto installed
with mail doens't make sense.
- Move the empty res_config class and the related view from
base_setup to sales_team (base_setup only contains the 'General Settings'
model and views
- Move the 'sale' related content from product to sale module (Access rights,
menuitems,...)
- Set sales_team at autoinstall False. The module is installed when needed by
crm or sale for example
- Set sales_team as a dependency of voip. (Access rights defined for configuration
purpose)
- Set sales_team ad a dependency of subscription (Access rights issue too)
Rename xmlids accordingly. Example: 'base.group_sale_manager' becomes
sales_team.group_sale_manager.
Major changes:
- New start and expiration dates
- Remove field Contract Status
- Simplified because use of sale_timesheet
Reason: complete rewrite of the Sale module.
Responsible: fp, dbo, nim
Employees (base.group_user) can read tasks. However they miss the right to read
task stages (project.task.type). This causes issues when reading the form view
of a task. This commit fixes this issue.
[REM] portal_project: move ALL the things
- move portal access rights from portal_project and website_project_issue to project and project_issue
- move portal menuitems back to their respective module
- remove public visibility of projects
- adapt demo data to have a 'Demo Portal' project
- add correct access rights for account.analytic.line for portal users
- small view tweak (do not display 'timesheet' tab if one can't see antyhing in it anyway)
- remove unnecessary copy() method from project/res_partner.py
- remove old methods on project.project
- progress is not used anymore on project.project
- use clickable statusbar for project states
- remove _resolve_project_id_from_context
- rename project.category becomes project.tag to be more explicit
- remove old methods on tasks
- issues: remove option fetchmail_issue
Backport of 79bed94 (project user access to resource.calendar) and adding the access to resource.calendar.attendance.
It is needed to compute function fields such as day_open (present in form view of project.issue)
Fixes#3201
prye-odoo