Allow to resolve Storm tickets with a Storm task

I don't know about the hierarchy of content types in Storm, and I can not find a documentation of it's data model, so I have to guess a bit.

The normal use case for a ticket - like this issue on d.o. - would be, that a user or a client has a problem; thusly, the ticket or issue would be the starting point of the processing workflow; for the issue, he/she files a ticket, because that's the only content type he/she is allowed to create. Somone is now supposed to respond to the ticket ("help desk" or whatever); usually that responder would do something, e.g. write an explanation or solve a problem and document what he has done. For that he would have to assign some kind of "document" to the ticket. In Storm's logic, this IMHO would be a task. If the task is set to "completed", the ticket would need to be automatically set to "closed", "fixed" (or whatever indicates that the issue actually has been resolved).

However, Storm seems not to work this way. E.g., it makes no sense for the user (!) to assign a ticket to someone; the user probably not even knows the support personnel. As far as I understand the workflow in Storm, a ticket gets stuck in nirwana as soon as it is posted. There is simply no way to respond to it.

If you say in #1, that "in Storm, a task comes above a ticket in the hierarchy", that probably means that the user should not be allowed to post a ticket, but that he should directly open a task. That task would indeed have a mechanism to handle the issue (by creating a ticket). However, that's not how a project management workflow is supposed to work; the decision to create a task, or to assign a task to a person/team is the decision of the project manager, not of the user.

So maybe this is "just" a terminology problem and we've entered bogus data into the system in the past couple of days. Maybe what usually is referred to as a task in project management is a "Ticket" in Storm, and what usually is referred to as a ticket is a "Task" in Storm. Would that be possible?

Probably my assumption from #2 is correct, this seems to be a total terminological mixup.

Indication: A "Storm Ticket" has several categories, including "Task". This makes absolutely no sense, even if you come from a "Storm Task", to assign a Storm ticket the Category "Task". It's either a ticket or a task, it must not be an ambiguous mixture of both.

I believe we need some clear definitions what a "Storm Task" and what a "Storm Ticket" exactly is, and how it is supposed to be used correctly.

OK, I understand. I'm changing this to a feature request: "Allow to resolve Storm tickets with a Storm task". Hopefully the data model would allow that.

Pros: Existing workflows don't need to be changed; Storm gains more flexibility.
Cons: Needs work ;)

Regarding the definitions: #1181224: Documentation: What is a Storm Task, what is a Storm Ticket?

Attaching a mockup of a revised Storm Ticket node: It simply gains "Tasks" and "Add Task" links (marked as (1) in the mockup). Since the ticket has not yet a task, the "Task: " field is empty, until the help desk clicks on "Add Task". Then - ideally - the "Task: " field would be filled with a link to the newly created "Storm Task".

I'm not a coder, so I can not suggest how to put this into the module's code; however, speaking in CCK terms, I'd probably use a Node Reference URL Widget to create a node reference from ticket to task; if I'd need to reference a not yet existing node, I'd probably use Node Relationships with a modal frame to create the new node. I'm pretty sure there is a way in Storm to do this more elegantly (yes, I'm aware that CCK node references are unidirectional [1] ;)

Are you suggesting that on creating a Storm Task, a Storm Ticket can be marked fixed?

I don't think that any issue would be fixed just by creating a task (ticket: "My house is burning"; creating the task: "Call the firefighters" does not extinguish the fire ;), so this is probably more complicated. Do the Storm content types have the means to automatically update other node's properties? If so, there might be a hook to set the Storm Ticket to "fixed", as soon as the connected Ticket is set to "fixed".

[1] Approaches: Reverse Node Reference, NodeReferrer, Relation

...and probably these hard coded relationships are the reason why you're talking about a "hierarchy":

• A task can have (multiple) tickets;
• a project can have (multiple) tasks;
• a task can not be split into (multiple) projects;
• a ticket can not be resolved by a task;

So the recommended approach would be to allow users to create Storm tasks, if there is a problem ("My house is burning"); then a Storm task would be similar to an Issue at d.o (like this one), and the means to resolve the "task" would be to create tickets (help desk creates ticket: "Firefighters have been called")?

Umm... This raises another issue: there is no history for the ticket's status (when had the ticket which status, who changed it when), and the user can not respond to the ticket (e.g. re-open it). Anyway, seems like we have to live with that.