Bug 1034727 - Snapshot time not retained after reopen.
Summary: Snapshot time not retained after reopen.
Keywords:
Status: CLOSED EOL
Alias: None
Product: JBoss BPMS Platform 6
Classification: Retired
Component: jBPM Designer
Version: 6.0.0
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: ---
: ---
Assignee: Tihomir Surdilovic
QA Contact: Jiri Locker
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-11-26 12:05 UTC by Marek Baluch
Modified: 2020-03-27 19:13 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2020-03-27 19:13:14 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Marek Baluch 2013-11-26 12:05:53 UTC
Description of problem:
A user can specify the time after which he wants the editor to create a snapshot (when the process has been modified). When he attempts to change the time (e.g. to 30s) then when the process is reopened the time will be again 1 minute which is default.

I have one more idea for improvement. When the user hits 'configure snapshot interval' then the window could show the currently set interval.

Comment 1 Tihomir Surdilovic 2013-11-26 17:37:08 UTC
I cannot reproduce this problem. If I set it to 30 seconds interval that is the interval local history will be triggered. Note that unless you make a change to the process even local history is triggered, no snapshot will be created (there was another BZ for this). To test you can set it to 30 seconds, and move a node around the canvas, then open to view all snapshots. it updates then on 30 seconds, once an update is made, close the view and move a node again, open view and test again it will take 30 seconds to update the next one.

Comment 2 Tihomir Surdilovic 2013-11-26 17:41:19 UTC
Regarding after a process has been reopened. We do not keep this settings in a cookie currently. I don't see much value on this since the default is set to a low number (1 min). Adding ability to track each individual process local history time I think is overhead that is not really needed.

Comment 3 Marek Baluch 2013-11-26 18:01:28 UTC
I was just about to attach a video :-).

I saw this is a possible enhancement. That's why I put severity to 'low' and added the 'FutureFeature' keyword to indicate that this is not a bug but an enhancement. I don't know any other way to indicate a feature request or enhancement at this point. If there is one I will gladly follow it.

If you don't intend to implement it (for 6.0 or any other future release) then please close as WONTFIX. MODIFIED does not apply in this case as no work has been done on this BZ.

Thank you.

Comment 4 Marek Baluch 2013-11-26 18:03:08 UTC
My bad - I didn't intend to close it as it's not my decision to make. I was just reviewing states. Setting back to ASSIGNED for Kris or Tihomir to properly close this issue.

Comment 5 Kris Verlaenen 2013-11-26 18:38:33 UTC
I set devel_ack- to indicate we won't be addressing this for 6.0.  No need to close it at this point, we can decide to pick it up in a future release.


Note You need to log in before you can comment on or make changes to this bug.