Discuss anything related to web development but no technical support questions


Post by Maxim Gorkovsky »

We see the problem, I opened a ticket to track this: https://app.assembla.com/spaces/bryntum/tickets/3143

I can suggest to clear undo/redo queue on every sync/load request. Call stop/start on undo manager instance to achieve that.

Post by lbouth »

Hello,

I had the same problem. It's because the record to restore has an Id. So the store with an ajax proxy doesn't send the request 'create' to the server. Moreover, the Record is marked as deleted...

One way to fix this can be :
Ext.override(Robo.action.flat.Remove, {
  undo: function() {
  var me = this;
  var records = me.records;
  for (var i = 0; i < records.length; i++) {
    records[i].data.Id=null;
    me.store.insert(me.index+i, records[i].data);
  }
  }
});

Post by mats »

This won't be easily solvable with current design I'm afraid.

Different scenarios:
1. Pure client side undo, no sync to server:
Undoing a task deletion will provide correct results, any linked assignments and dependencies will still be restored correctly.

2. "Syncing to server"
If a task is removed, and synced to server an undo will mean its id is no longer possible to restore (assuming database table uses an auto increment column for the id field.
2a. Simple case: If just an isolated task is removed + synced, it can be correctly restored by an Undo operation which removes the 'id' from the data
2b. Complex case. If a task is removed which has dependencies or assignments linked to it, restoration won't be trivial. Special treatment would be required to correctly link dependencies when such a task is recreated - setting its new phantomId where applicable.

Currently we cannot support the case where a sync is made, this has to clear the undo queue.

Post Reply