MantisBT - v2.3 Release (Closed)
View Issue Details
0000701v2.3 Release (Closed)[All Projects] Generalpublic2011-01-21 10:542011-03-29 21:45
Assigned Topedroa 
PlatformOSOS Version
Product Version2.3 
Target VersionFixed in Version2.3 
Summary0000701: removal of a task
DescriptionIs 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
TagsNo tags attached.
Attached Files

2011-01-21 15:59   
You can remove someone's Delete Task via a Role or Permission. Is that sufficient?
2011-01-21 16:18   
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
2011-02-08 06:46   
An idea!
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.

2011-02-22 01:59   

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?


Pedro A.
2011-02-22 09:53   
Hi Pedro,

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
2011-02-24 08:40   
Hi eureka,

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.


Pedro A.
2011-02-24 10:09   
(Last edited: 2011-02-24 10:18)
Hi Pedro,

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 :)

2011-02-24 10:36   
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.


Pedro A.
2011-03-28 18:53   
Fixed in SVN
Revision 1784

Removed the code to delete the tasklogs upon task deletion.

Pedro A.
2011-03-29 21:45   
Closed in preparation for v2.3

Issue History
2011-01-21 10:54eurekaNew Issue
2011-01-21 15:59caseydkNote Added: 0001574
2011-01-21 16:18eurekaNote Added: 0001575
2011-02-08 06:46achieleNote Added: 0001605
2011-02-08 06:46achieleNote Edited: 0001605
2011-02-22 01:59pedroaNote Added: 0001658
2011-02-22 01:59pedroaAssigned To => pedroa
2011-02-22 01:59pedroaStatusnew => assigned
2011-02-22 09:53eurekaNote Added: 0001663
2011-02-24 08:40pedroaNote Added: 0001682
2011-02-24 10:09eurekaNote Added: 0001683
2011-02-24 10:18eurekaNote Edited: 0001683
2011-02-24 10:36pedroaNote Added: 0001684
2011-03-22 12:04caseydkProjectv2.3 Release (Closed) => v2.4 Release (Closed)
2011-03-28 18:53pedroaNote Added: 0001815
2011-03-28 18:53pedroaStatusassigned => resolved
2011-03-28 18:53pedroaResolutionopen => fixed
2011-03-29 16:40caseydkProjectv2.4 Release (Closed) => v2.3 Release (Closed)
2011-03-29 21:45caseydkNote Added: 0001820
2011-03-29 21:45caseydkStatusresolved => closed
2011-03-29 21:45caseydkFixed in Version => 2.3