When creating a new project, task, ticket or other Storm related node, which is a child of another Storm node, there are some fields filled-out automatically when using links like http://www.example.com/node/add/stormtask?project_nid=825

This will create a Storm Task node and the organization and project will already be selected in the upcoming form from the project_nid=825 parameter. So far so good, this is working.

What's not working is http://www.example.com/node/add/stormtask?task_nid=825 where you want to create a new task which is a child of the existing task 825.

Comments

Magnity’s picture

Where is this linked from?

jurgenhaas’s picture

It used to be in the Task view long time ago and I remembered that logic. In general, creating Stom nodes has always been possible that way by providing the node id of the parent node.

Then, such links are included in Storm Dashboard when looking into Tasks.

Shouldn't it be possible again to create sub-tasks this way, just to be consistent?

Magnity’s picture

Do you know how long ago it was that this last worked?

I'd like to know why it used to work and doesn't now, whether it was an accidental error or if there was a reason for it.

jurgenhaas’s picture

I'm not sure bute it used to work at least when I initially worked on Storm Dashboard which was early September this year.

Magnity’s picture

The argument is parent_nid rather than task_nid - checked in the code. I think parent is a better term than task in this context too, so we'll keep it as is.

Next question - do we need to add a link to add a subtask to the task view?

jurgenhaas’s picture

Great, so I guess the error lies in theme_storm_link(). I'm calling it as theme('storm_link', $parent_type, $type, $nid, 0) and get the wrong URL whenever $parent_type = $type = 'task'.

Answering your second question: yes, I think that would make sense. And if you were going to implement that, you may run into the same issue I guess.

Magnity’s picture

OK I can see that theme_storm_link would give a parameter of task_nid=nid.

So the options are:
1 - Change stormtask_form to recognise task_nid rather than parent_nid
2 - Change theme_storm_link to have a special case for when both source and destination are tasks.
3 - Make this a special case that doesn't go through stormtask.

Option 1 is probably the best. Even though that means losing the distinction on parent / task.

Does that work if you change the name of the variable that is checked in stormtask_form?

jurgenhaas’s picture

To answer your last question first: no it doesn't. Just to make sure I did the right thing, I called http://www.example.com/node/add/stormtask?parent_nid=829 but the form wasn't pre-filled properly.

However, I would have voted for option 1 anyway, because it would be more consistent and works with less exceptions. And to support that thinking: a project is a parent to its tasks, tickets, etc as well but still you don't use parent_nid either.

Or the other way round: use parent_nid always !

Magnity’s picture

There is a further problem with it, and that is that it only works when the selected parent task belongs to the organization and project that is first alphabetically, or the organization/project selected by a different parameter - org or project.

So the fix that is required needs to change to using task_nid, then make sure that the parameter is treated as a "first class citizen" - overriding the project_nid params if present (as the task nid is more granular).

We can't standardise on parent_nid as then we couldn't distinguish between organization_nid, project_nid and task_nid.

jurgenhaas’s picture

Well, I still think you can. If you go for /node/add/stormtask and provide parent_nid=123 then you only need to load the node 123 and find out its type anyway. Using project_nid=123 is kind of redundant information in case that node 123 is a stormproject, because you will find that always from the node to be loaded.

However, I'm fine with the other approach too, no problem.

Magnity’s picture

Status: Active » Fixed

Committed.

Takes argument ?task_nid=??? as per theme_storm_link which is then used to fill the parent nid field, and cascades to the org and project fields too.

You're right, we probably could just use parent_nid, but I think there's nothing lost by having the clarity in the code if nothing else.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.