How do I set a task's DueDate outside an execution context

[brianshowers]

I apologize if there is an obvious answer to this question.  It seems terribly simple.

I have a scenario in which I want to programatically change the DueDate of a Task.  I thought this would be as simple as other elements such as Assignee and Priorty where I could call taskService.setAssignee() or taskService.setPriority().  However, there doesn't appear to be a corresponding method for taskService.setDueDate().

Is there another way in which I can change a task's due date from outside of an execution context?

[frederikherema1]

First, query the task by ID. Update the Task.setDueDate(). Call taskService.saveTask(task); done!

[brianshowers]

Unfortunately, while that seems nice and simple, I don't think that taskService.saveTask() can really be used in a system that also uses TaskListeners. 

Specifically, it re-sets the assignee and TaskEntity.setAssignee() generates an event to any listeners (even when the assignee value is the same).  This means that if the task already has an assignee when you call taskService.saveTask(), it will re-assign that person and fire false TaskListener.EVENTNAME_ASSIGNMENT events to any listeners.

TaskEntity:419 has a line of code that would prevent this, but it's commented out.  I don't know the history behind that.

[frederikherema1]

Is there another way in which I can change a task's due date from outside of an execution context?

I just answered your question. The issue with the task-listener is something else and needs to be looked into, off course…

[brianshowers]

Would you like me to start a new post for this, or just continue the discussion here?

FWICT, it looks like the TaskService logic was changed by Joram as a part of ACT-1290.  That commit commented out all of the logic in the TaskEntity setters (assignee and owner), that treated re-setting the existing value as a no-op.  It's not clear to me if that was somehow related to fixing the bug reported in the ticket or if the changes were unrelated.

[frederikherema1]

I'll check with Joram to see what his opinion is. However, I don't immediately see any objections to revive commented out piece of code…

[jbarrez]

We discussed it and indeed decided I wan't thinking clear at that point …

[brianshowers]

Do you need me to open a Jira ticket?

[frederikherema1]

No need for that, we're on it

[frederikherema1]

The commented lines of code should be removed, indeed. Otherwise, the assignee won't be recored if it has been set before (e.g.. by setAssigneeWithoutCascade or when task is created). So this change was intended and I'll remove the commented out code completely. Any code that relies on the "no-op" should be changed I'm afraid.