Anonymous Login
2019-08-23 19:18 PDT

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000701v2.3 Release (Closed)[All Projects] Generalpublic2011-03-29 21:45
Reportereureka 
Assigned Topedroa 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
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

-Relationships
+Relationships

-Notes

~0001574

caseydk (administrator)

You can remove someone's Delete Task via a Role or Permission. Is that sufficient?

~0001575

eureka (reporter)

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

~0001605

achiele (reporter)

Last edited: 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.

~0001658

pedroa (administrator)

Hi,

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?

Thanks,

Pedro A.

~0001663

eureka (reporter)

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

~0001682

pedroa (administrator)

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.

Cheers,

Pedro A.

~0001683

eureka (reporter)

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

~0001684

pedroa (administrator)

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.

Cheers,

Pedro A.

~0001815

pedroa (administrator)

Fixed in SVN
Revision 1784

Removed the code to delete the tasklogs upon task deletion.

Pedro A.

~0001820

caseydk (administrator)

Closed in preparation for v2.3
+Notes

-Issue History
Date Modified Username Field Change
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
+Issue History