| Age | Commit message (Collapse) | Author |
|---|
|
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.
closes odoo/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.
closes odoo/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.
closes odoo/odoo#47306
Taskid: 2209133
Related: odoo/enterprise#9141
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
|
It is a computed field, there is no need to manually set its value.
|
|
Purpose
=======
The current kanban view is messy. It is difficult to identify which
apps are installed or not. The user can completely miss a module
that might have interested him. A search panel would make things way
more readable.
closes odoo/odoo#44401
Taskid: 2181557
Related: odoo/enterprise#8144
Related: odoo/upgrade#879
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
|
=======
Purpose
=======
Currently for a user to be allowed to see a private project they must follow the
project. This means that they will be added as a follower of all new tasks in the
project which causes them to receive 1000000 notifications, especially if there are a
lot of tasks in a project.
==============
Specifications
==============
1) Add an Employee m2m field on project next to 'Invited Employees'
- only visible if the 'Invited Employees' option is selected
- the project should only be visible to employees selected there (regardless if they
are followers or not)
2) Add an Employee m2m field on tasks below the 'Email cc' one in debug mode
- only visible if the 'Invited Employees' option is selected on the related project
- should be pre-filled with what is set on the project
- the task should be visible to employees selected there (regardless if they are
followers or not)
3) Add a Portal users m2m field on project next to 'Portal users and all employees'
- only visible if the 'Portal users and all employees' option is selected
- the project should only be visible to portal users selected there (regardless if
they are followers or not)
- rename the option into 'Invited portal users and all employees'
4) Add a Portal users m2m field on tasks below the 'Email cc' one in debug mode
- only visible if the 'Portal users and all employees' option is selected
- should be pre-filled with what is set on the project
- the task should be visible to portal users selected there (regardless if they are
followers or not)
5) Following a project/task should not grant the user/employee the ability to see the
project/task
Task 2031527
closes odoo/odoo#40505
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
|
This was already performed on 3c568aec0b46, but there still are some
remnants on model access records.
Fixes odoo/odoo#25408
Closes odoo/odoo#37946
closes odoo/odoo#37958
Signed-off-by: Martin Trigaux (mat) <mat@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
|
|
As task can be billed, it became a important business model. To avoid mistakes in a multi company
environment, we need to make the company_id field required. Indeed shared task can be problematic
with access rights when a employee will log timesheet from another company in a task that is not in
the same company as its project.
To populate this field, we recommend to take the company of task's project, or to fallback on
the company of the user that created one.
Task-1999686
|
|
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
|
|
Purpose
=======
Allow the user to select the allowed companies for which he wants to see records
on top of selecting his current company.
It is confusing for users to see the records from the company he is connected to
and the records of the children companies.
Instead of using the hierarchy of companies to access records across companies,
the user can now select (from his set of allowed companies) the companies for
which he wants to access records.
/!\ This means that the user will interact with records from company A when in
company B.
Example: a SO has been created and confirmed in A. When in B, I create the
invoice from it.
Specifications
==============
1/ Deprecate the parent/children hierarchy on the res.company model. The fields are
kept on the res.company model to ensure the retro-compatibility, but won't be used
accross the standard code anymore. The only functional usage for this mechanism
was to allow to see records from several companies by creating a virtual parent
company, which will be possible with the new mechanism.
2/ By default, a user will only see the records of the company he is connected
to (or records without a company). (It is still editable by the user if needed).
For that, put this information in the user context, to allow having different
configurations on different browser tabs. Instead of having domains like
['|',
('company_id', '=', False),
('company_id', 'child_of', user.company_id.id)]
you'll have something like
['|',
('company_id', '=', False),
('company_id', 'in', company_ids)]
Note that the 'company_ids' is a value that is passed in the evaluation
context on the record rule, as we already have user, or time.
company_ids is a list of the ids of all the enabled companies in the
user's context.
3/ Out of the generic improvements brought by this task, this will illustrate
issues that could exist since several versions. For example, it should not be
possible to create a scrap order for the company A with a package of the company
B, or it should not be possible to create an invoice on the company A with
payment terms from the company B. Before the version 12.0, it was easy to
encounter this kind of issues as the admin was the SUPERUSER_ID. A positive side
effect of the fact that the SUPERUSER_ID has become an inactive user was to
make it more difficult to introduce mismatch on the records, but haven't solved
the issue, as it was still possible to do it with parent companies
configuration. Some of these issues have been fixed in this commit, but all the
business flows should be re-tested to check if an ir.rule should be introduced
(eg: a multi company rule for stock.quand.package), if the company of a record
is correctly transfered to another record created from the first record (eg:
From a SO, create an invoice and a payment, the company of the sales order
should be transfered on the invoice and the payment, even if the company of the
sales order is A and I'm logged into the company B with the company A enabled.
4/ Currently, if I click on a button on a notification email (example 'View
Task'), I face a traceback if I'm not logged into the company of the record.
Now, if you click on a button and if you have access to the record, the correct
company will be automatically set.
5/ If I display a kanban view with several records from several companies (and
an image), all the images should be displayed.
6/ Currently if you copy paste an url, this will crash if you're not in the
correct company. This won't be fixed because it's quite impossible to do it in
a clean way. This task brings a workaround. Copy/Paste -> Traceback -> Log into
the correct company, re-copy/paste -> Ok.
7/ 2 property methods have been added on the environment to retrieve the company
on which the user is logged in and the companies the user enabled, on a specific
tab.
That way, when creating a record, instead of doing
default=lambda self: self.env.user.company_id
do
default=lambda self: self.env.company_id
On the other hand, to retrieve the enabled companies, do
companies = self.env.company_ids
8/ Modify the Company Switcher widget to allow to log into another company
WITHOUT writing on the res.users (and thus bringing cache invalidation issues
and so on). Also allow to enable several companies and see records from several
companies, and independantly of the other browser's tabs.
9/ When focusing on a tab, save the current company configuration on the local
storage. That way, when doing 'CTRL+T' or a middle click, the context is
propagated to the new tab.
10/ Improve the error message in case of multi company access errors. Now, when
the user is in debug mode, display the related names of the records and the name
of the user who brings the issue.
11/ Remove the context erasing when writing on a res.users
This is probably coming from the migration to new API of the base module.
The context was not propagated at this moment, which was a common mistake at
that time. When migrating the module, probably by using the 'black box' method,
as the context was not propagated, it was erased on the new version. This is
now an issue because the context (i.e. the enabled companies) was erased when
writing on a res.users, leading to tracebacks.
See: https://github.com/odoo/odoo/commit/7eab8e26d3d46c53f4be924d6a34e80a66e74960#diff-4c2e738ee8f64f11806c889ea097b5e7R624
12/ Fix the crash manager on redirect warnings. The issue is the following
- Create an invoice on a company without a configured CoA.
- Set a partner
- On the onchange_partner_id, a redirect warning is raised to propose you
to configure a CoA
- Click on 'Go to the configuration panel'
- A generic warning says something like 'Do you want to discard your changes?'
- Click on yes, the page refreshes, but not on the redirect action.
Now, set correctly the action on the hash, and reload instead. The breadcrumb is
lost for example, but you reach the correct action at least.
13/ Introduce a res.group to enable/disable the multi company per tab
feature.
14/ To help the users to know which tab is in which company, add the
possibility to have a favicon per company. When creating a company,
the classical 'O' icon is colored by default in a random color.
15/ Remove the company switcher on the frontend. This was mainly there
to allow a user to swicth to the company linked to the website.
This behavior is now transparent to the user. If the website A is
activated, then the company set on the context is the company of the
website.
16/ Deprecated the _company_default_get method on the res.company
model. Remove the method _get_company on the res.users model.
17/ Add 'allowed_company_ids' and 'current_company_id' on the pyeval
context. You can now use those variables on domains in the views to
access directly to the activated company.ies on the current tab.
TaskID: 1960971
closes odoo/odoo#32341
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
|
Steps to reproduce:
- Create a channels C with user A linked to an employee E
- Create project P with privacy_visibility='followers' meaning only visible for employees that follow P
- Add the channel C as a follower of P
- Log as user A go to Project app
Bug:
The project P is not readable for A
opw:1958386
closes odoo/odoo#32324
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
|
|
Purpose
=======
Access group terminology is missleading. Yous have to be manager to administrate
an application. This task consists to rename groups to be understandable for everyone.
Groups should be reorganised on the users form to be more explicit.
Specification
=============
1/ Rename 'Manager' to 'Administrator' in users groups.
2/ Define a hierarchy on access groups by using the category_id in the manifests
A category 'Operations/Project' will create a category Project with a parent
category 'Operations', and something smart is already developed (in modules/db.py)
to avoid duplicating categories.
3/ Add a group in expenses to be able to approve expenses reports for my team.
4/ Add a group in timesheets to be able to approve timesheets for my team.
5/ Remove partially the useless crap in ir_module_category_data.xml
6/ Sort access rights groups on users form according to its parent category
closes odoo/odoo#29362
Signed-off-by: "Yannick Tivisse (yti)" <yti@odoo.com>
|
|
|
|
This reverts commit 382fbd35204ff947c16b795ca090c97d6741fb1d.
|
|
User 1 simply becomes a technical user (inactive, no password).
|
|
The categories other extra rigths and hidden are not used now.
|
|
'remaining_hours' is defined in project as a simple
float field, manually updateable, only displayed
when the group "Time Estimation on Task" is activated.
But for now, there is no setting to active this group.
Those are legacy useless stuff, so we can remove it.
The purpose is to make 'time estimation' feature only
available when timesheet is installed.
Thie commit also split the compute methods of
'remaining_hours' and 'progress' fields to make
'remaining_hours' updateable, though inverse method.
Without splitting the compute method, the calculation
of the progress was done correctly during onchange
but not when saving.
|
|
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;
|
|
Impacted modules: project, rating_project,
sale_service_rating and website_rating_project.
Removed modules: rating_project and sale_service_rating.
Move code to empty 'rating_project' module, in order
to kill it.
Code is not modified, simply copy/paste at the right
place in 'project' module code.
However, 'enable rating on task' options is convert
into a res.groups that can be activated from the
project settings.
|
|
|
|
Making project depending on portal, makes website_project
useless. So move all feature from one module to the other.
|
|
-> Move Subtasks mechanism from hr_timesheet to project.
-> Various functional improvements:
- Add new 'Sub-tasks' setting and 'Sub-task Project' field based on
this setting.
- Relabel 'Team Collaboration' section to 'Task Management'.
- Remove 'Customer Satisfaction' section and move setting
'Rating on Tasks' into 'Task Management' section.
- Add customer name on the project's kanban view.
- Set default value of 'Sub-task Project' field is the same project.
- Add 'Parent Task' stat button on task form view.
- Make 'Sub-Tasks' stat button visible when no parent task
|
|
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
|
|
Add a link in the general settings to access easily the default_user form view in order to modify the default access rights
The default_user manager rights declarations in all the applications have been move in a noupdate="1" definition to avoid the manual configuration overwrittings
|
|
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 fa6e415cdb23ce9494487ed672792186157b40e0.
|
|
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.
|
|
- Hide account_id field and add a required project_id field on timesheet entries
- Remove is_timesheet field: as project_id is only required for timesheet entries and not for other analytic lines, it can be used to determine wether a line is a timeheet entry or not.
- Remove project_timesheet module as all its functionalities are moved to hr_timesheet
- Replace timesheets on contract option on products by timesheets on project
- Small fixes and improvements in timesheets and projects views and groups
|
|
Coming from a bug in web_settings_dashboard. Invited user didn't have any rights
when created from the dashboard, which was leading to an error.
This bug leaded to a new discussion. Better to have basic employee having user
rights for all main applications. For bigger entreprises there is an admin that
will carefully remove extra rights, if necessary. The target is small businesses,
it makes sense that every way to create a user gives the same result.
In conclusion, each new user has a full access to the applications by default
How is it implemented ?
We added an inactive default user which original access right to the groups
'base.group_user' and 'base.group_partner_manager' in base. Each
application will extend the default user's access right by adding the maximal
access right for this application.
On user creation, we will use by default the 'group_id' field from the default
user. We will in the same time remove the ugly 'default_groups_ref' key which
was passed sometimes in the context for some fields in some views, and sometimes
nothing.
So, the user can modify the access rights for the default user, but he should be
aware that removing project user access rights for a default user will prevent
a *created on the fly in a task* user will not be able to access the task.
|
|
|
|
This change avoid to display the tasks
that a user is not permitted to see
in the reporting view 'Task analysis'
Closes #4399
Courtesy of jkei
https://github.com/jkei
|
|
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.
|
|
Followers can now be partners or channels. Partners following a document
will receive needaction, as previously. However people can follow documents
through channels. Members of a channel are able to listen to a stream
of messages using the channel. Those messages do not create needaction
messages. It is therefore possible to follow documents without receiving
too much notifications. For interesting documents subscribing with its
partner will create notification.
message_follower_ids fields is udpated. It is now a many2many to
mail.followers, not to res.partner anymore. A subscription can be either
a partner (partner_id) or a channel (channel_id).
Some access rules have been updated accordingly.
|
|
visibility and access rights modifications
[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)
|
|
Conflicts:
addons/project/wizard/project_task_delegate.py
|
|
|
|
- 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
|
|
modules. hr.analytic.timesheet is removed, and account.analytic.line is used directly to represent timesheets.
Also removed worklogs on tasks and replaced them by generic timesheets, i.e. account.analytic.line(s)
|
|
For privacy_visibility 'followers' or 'portal', the user should be follower of the project (not the task).
Remove public access to portal task
Fixes #2372
If no project on the task (or other rule), an employee (not a portal) can access if is follower of the task.
Follower rule is not enough as a user creating a rule will subscribe to the rule but to subscribe to record, the user should have access to it in the first place.
To make sure the snake does not bit its tail, fallback to give access on task where the user is reponsible (user_id = user.id).
Fixes #139
Adapted the tests to the new behaviour (removed not relevant and added some on creation)
|
|
Allow access to task without a project defined if the user is follower.
Fixes #3450
|
|
|
|
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
|
|
|
|
In order to be able to read the days_since_creation field
|
