If "create new revision" checkbox is selected when editing a timetracking, the Project, date, timestart, timeend, duration, and billing fields are all not saved correctly. Timetracking lists do report the timetracking's duration toward the "total" field at the bottom. Reverting revisions does not restore the improperly saved data, and neither does deleting all other revisions.

I also verified that this issue affects whatever version / cvs checkout is currently operating the demo site.

Comments

higherform’s picture

higherform commented

Correction, those fields are blanked upon editing an existing timetracking, with the "Create New Revision" checkbox checked. It does not matter if the Create New Revision checkbox was selected on initial timetracking create or not.

higherform’s picture

higherform commented

This issue also affects invoiceitems. (not yet verified on demo site). It appears to blank the amount and total amount fields. Invoiceitem with revision then does not show up on lists or on the "print" report, but the total amount still counts towards the invoice total.

higherform’s picture

higherform commented

This issue also affects invoices. (not yet verified in 6.x-1.19).

Magnity’s picture

Magnity commented
Version: 6.x-1.9 » 6.x-1.21
Priority: Critical » Normal

Verifed that this is a bug on the current release (1.21).

Also changing status as per criteria in #435504: TODO BEFORE STORM 1.22

homoludens’s picture

homoludens commented
Version: 6.x-1.21 » 6.x-1.x-dev
Component: Code » Miscellaneous
Status: Active » Needs review

I have found error.

This is original function:

function stormtimetracking_update($node) {
  _stormtimetracking_beforesave($node);

  db_query("UPDATE {stormtimetracking} SET
            organization_nid=%d, organization_title='%s',
            project_nid=%d, project_title='%s',
            task_nid=%d, task_title='%s', task_stepno='%s',
            ticket_nid=%d, ticket_title='%s',
            trackingdate=%d, timebegin='%s', timeend='%s', duration=%f, billable=%d WHERE vid = %d",
            $node->organization_nid, $node->organization_title,
            $node->project_nid, $node->project_title,
            $node->task_nid, $node->task_title, $node->task_stepno,
            $node->ticket_nid, $node->ticket_title,
            $node->trackingdate, $node->timebegin, $node->timeend, $node->duration, $node->billable, $node->vid);
}

This is modified which is working with revisions.

function stormtimetracking_update($node) {
  _stormtimetracking_beforesave($node);

  db_query("UPDATE {stormtimetracking} SET vid =%d,
            organization_nid=%d, organization_title='%s',
            project_nid=%d, project_title='%s',
            task_nid=%d, task_title='%s', task_stepno='%s',
            ticket_nid=%d, ticket_title='%s',
            trackingdate=%d, timebegin='%s', timeend='%s', duration=%f, billable=%d WHERE vid = %d",
            $node->vid, $node->organization_nid, $node->organization_title,
            $node->project_nid, $node->project_title,
            $node->task_nid, $node->task_title, $node->task_stepno,
            $node->ticket_nid, $node->ticket_title,
            $node->trackingdate, $node->timebegin, $node->timeend, $node->duration, $node->billable, $node->old_vid);
}

Change is that there weren't saving of revisions. Was not planed at all - so formally this is not bug report it is a feature request.
Luckily solution is easy: node object which is passed to stormtimetracking_update() has properties $node->vid and $node-old_vid.

We use $node-old_vid to find existing node revision, and we use $node->vid to create new - updated one.

I haven't looked at other modules, but I'm expecting that the solutution is the same.

I, also, haven't tested this too much, so please review, test and report.

And some usefull links:
http://api.drupal.org/api/function/node_example_update/6
http://api.drupal.org/api/function/node_example_insert/6

maybe we should chage update function to work like this example.

Magnity’s picture

Magnity commented

Will that save previous revisions too, or just the most up to date one? I suspect that an insert operation is needed if the data is being saved for all revisions.

Magnity’s picture

Magnity commented
Status: Needs review » Fixed

Committed change to update function to work similar to the node_example_update and node_example_insert - the if/else construct. That method was already used in some of the modules anyway.

Status: Fixed » Closed (fixed)

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