Can't easily unassign tasks that have be deleted from events

[GoogleCodeExporter]

What steps will reproduce the problem?
I removed 2 tasks from my client before I removed the assignment of those tasks 
to an event. SJQ was still tying to assign the tasks to a client, but none 
supported those tasks. Thats probably fine, but the real problem was that those 
task names no longer show up in the screen to assign (and unassign) tasks to an 
event, so I could not stop SJQ from queuing them up. In order to remove the 
assignment to the task, I had to recreate a dummy task with that name in order 
it to show up for me to unassign it.

What is the expected output? What do you see instead?
I guess I would suggest that the list of task names displayed in the screen to 
assign/unassign tasks to events should get its task list both from the tasks 
that exist (which it does now) and the tasks that are currently assigned to an 
event

What version of the product are you using? On what operating system?
SJQ 4.0.0.1326
SJQ Agent 4.0.0.1325
SJQ UI 4.00.20101219
Server 2008

Please provide any additional information below.

Original issue reported on code.google.com by kkuh...@gmail.com on 9 Jan 2011 at 9:18

[GoogleCodeExporter]

Tom, I believe this is a UI issue only.  Bounce it back to me if you discover 
something different.

Original comment by de...@battams.ca on 13 Jan 2011 at 2:40

• Changed state: Reviewed
• Added labels: Component-UI, Plugin-SJQ

[GoogleCodeExporter]

Original comment by tom.mira...@gmail.com on 14 Jan 2011 at 12:13

• Changed state: Accepted

[GoogleCodeExporter]

Diagnosis: The "Choose Tasks for Events" dialog invokes 
ServerClient.getRegisteredTaskIds() to get the list of tasks that may be 
assigned and unassigned to Events.  If a Task is removed from the last Client 
supporting it, the Task will not be displayed in the dialog and will remain 
assigned to Events.

Cure: When a Task is removed from the last Client that supports it, the Task 
should also be removed from any Events it may be assigned to.

Original comment by tom.mira...@gmail.com on 14 Jan 2011 at 10:56

[GoogleCodeExporter]

Hmm... but the suggested cure doesn't account for the (real) possibility that 
someone may queue up tasks that have yet to be configured for task clients.

For example, I might create a cron entry that queues up a REBOOT task nightly, 
but may not have any task clients configured to run that task.  The REBOOT task 
should still be returned by getRegisteredTaskIds() because it's still being 
queued up via cron.

I have to look at the code a little closer to see exactly what I'm doing, but 
I'm pretty sure this example illustrates why it's working the way it appears to 
right now and assuming that's correct, I don't think the behaviour should be 
changed.

Original comment by de...@battams.ca on 15 Jan 2011 at 3:46

[GoogleCodeExporter]

If the user does not use the UI to add and remove tasks they are on their own :)

I put in the code to remove the task from any events but there is a small 
issue.  If the user removes the task, but then does not commit the change the 
task will still be removed from the event.  Do you think it worthwhile for me 
to keep track of the Tasks that were removed and then if the user does not 
commit the removal go back and re-add the Task(s) to the Events(s)?

Original comment by tom.mira...@gmail.com on 15 Jan 2011 at 12:55

[GoogleCodeExporter]

Original comment by tom.mira...@gmail.com on 15 Jan 2011 at 2:50

• Changed state: Fixed

[GoogleCodeExporter]

I added the code to re-associate tasks to Events if the user does not commit 
the changes.

Original comment by tom.mira...@gmail.com on 15 Jan 2011 at 6:54

[GoogleCodeExporter]

Original comment by de...@battams.ca on 9 Apr 2013 at 2:12

• Changed state: Verified