|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000701||v2.3 Release (Closed)||[All Projects] General||public||2011-01-21 10:54||2011-03-29 21:45|
|Target Version||Fixed in Version||2.3|
|Summary||0000701: removal of a task|
|Description||Is it possible to prohibit the removal of a task when tasklogs exist for this task.|
In my company (800 contacts, 90 users, 118 projects, 900 tasks, 4500 tasklogs), a project manager has accidentally deleted a task and all tasklogs of this task were removed. This is problematic, only an administrator should have this right
|Tags||No tags attached.|
|You can remove someone's Delete Task via a Role or Permission. Is that sufficient?|
no, it is not sufficient because a project manager must be able to delete tasks during the design phase of a project.
at least a confirmation message could be useful
Last edited: 2011-02-08 06:46
Create a relationship between project and rights (something as an matrix of responsibilities w2p/project).
This would solve several problems besides that. Currently I have a need to liberate the use of the system only for some projects. Here are some rules of this functionality:
- Information for each project who participates and what are their rights.
- Rights definitions apply: View, Edit, Delete related the project.
- User admin does anything. Full permission of course, and need not be added to the array.
- All features of W2P should now also check these permissions, plus the general permission given to the user.
Sorry achiele, but I don't think that fits this problem in particular, and believe that would give a rather big discussion.
Eureka, doesn't it already pops a alert box confirming the removal of the task?
Or you mean that on that alert, we should also inform that the Tasklogs are going to be wiped out too?
There is one thing we can not do, and that is to prevent the user from clicking the alert ok button, and confirm it... if you know what I mean.
There is some other discussion, about preventing deletion altogether, and simply recording deletion actions without actual database record removal, but that would give yet another big discussion.
Lets stick with the issue at hand, shall we?
Here's how I see things:
- An administrator may delete any task even if this one includes task logs
- A project owner may delete any task of its project even if the task includes task logs
- Any other user who has permission to delete a task, may delete this task if and only if this one does not include task logs
I have been watching closely your work and your suggestions for web2Project, and as you know, this one will bang the permissions logic.
For w2P if you have delete permissions over tasks, you have it no matter the user type or project ownership.
Now my question was more of the type:
Shall we or shall we not delete the tasklogs when a user (who has permission to do so), deletes a task? And is the alert task delete confirmation box working?
Other than that all that I have to say is that these are annoying situations for which the users should be responsible for.
Deleting stuff should never be taken lightly, and that is why we have those confirmation boxes.
Now, if there is one deletion box that is not working, please let me know which one and I will be glad to fix it.
Again, thanks a lot for all your suggestions and contributions, we at web2Project appreciate it.
Last edited: 2011-02-24 10:18
Yes, the alert task delete confirmation box is working but don't forget this : even for responsible users "errare humanum es !"
One question : Is it possible to dissociate setting permissions on tasklogs and setting permissions on tasks without banging the permissions logic ? This can be a solution available to the administrator to prevent accidental deletions
Best regards :)
I understand your Latin all too well.
As far as task removals are concerned, dissociating the tasklogs removal is not a permission issue, it is more of logical issue.
Someone in the past thought that, if you remove a task it makes sense that we should remove its tasklogs.
Same goes with projects, when you delete one, it is "logical" that we should also remove its tasks (which will then lead to the tasklogs removal as well.
Basically it is mimicking what you have on database engines as enforced Relationships between tables.
If you want to know the truth, I hate it.
My experience with Relationships always lead to things vanishing and people not knowing why. Kind of the same thing that you reported.
Like I said somewhere in the forums, and that I keep trying to tell people is, "don't delete anything, don't drop tables", simply store the information that it is virtually deleted so that it can be ignored but let it be.
You never know when you need your skeletons, so leave them in the closet.
Since everybody has them, just make sure you can get them when you need it.
And you get the benefit of knowing who did and when, and you get the chance to resurrect them.
Like I said, it'd give discussion for another topic.
Anyway I think that this cascading deletion can be challenged, and though I believe in the permissions cascading, I don't believe in the delete cascading.
Permissions you can always reconstruct them, valuable data you simply can't.
Fixed in SVN
Removed the code to delete the tasklogs upon task deletion.
|Closed in preparation for v2.3|
|2011-01-21 10:54||eureka||New Issue|
|2011-01-21 15:59||caseydk||Note Added: 0001574|
|2011-01-21 16:18||eureka||Note Added: 0001575|
|2011-02-08 06:46||achiele||Note Added: 0001605|
|2011-02-08 06:46||achiele||Note Edited: 0001605|
|2011-02-22 01:59||pedroa||Note Added: 0001658|
|2011-02-22 01:59||pedroa||Assigned To||=> pedroa|
|2011-02-22 01:59||pedroa||Status||new => assigned|
|2011-02-22 09:53||eureka||Note Added: 0001663|
|2011-02-24 08:40||pedroa||Note Added: 0001682|
|2011-02-24 10:09||eureka||Note Added: 0001683|
|2011-02-24 10:18||eureka||Note Edited: 0001683|
|2011-02-24 10:36||pedroa||Note Added: 0001684|
|2011-03-22 12:04||caseydk||Project||v2.3 Release (Closed) => v2.4 Release (Closed)|
|2011-03-28 18:53||pedroa||Note Added: 0001815|
|2011-03-28 18:53||pedroa||Status||assigned => resolved|
|2011-03-28 18:53||pedroa||Resolution||open => fixed|
|2011-03-29 16:40||caseydk||Project||v2.4 Release (Closed) => v2.3 Release (Closed)|
|2011-03-29 21:45||caseydk||Note Added: 0001820|
|2011-03-29 21:45||caseydk||Status||resolved => closed|
|2011-03-29 21:45||caseydk||Fixed in Version||=> 2.3|