18062 1 true 2009-08-10T10:48:39-04:00 65780 28 loopback-transitions-dont-appear-to-update-rails-record 37 13288 resolved 2009-10-07T13:20:34-04:00 21335 Kenneth Kalmer onitony Aaron Pfeifer http://pluginaweek.lighthouseapp.com/projects/13288/tickets/28 It seems that if a State Machine instance performs a transition that loops back into it's previous state, the record is not saved (because no fields have been modified?). The desired behaviour though, is for updated_at to update, to note the time the transition took place (same as it happens in non-loopback transitions). It seems that if a State Machine instance performs a transition that loops back into it's previous state, the record is not saved (because no fields have been modified?). The desired behaviour though, is for updated_at to update, to note the time the transition took place (same as it happens in non-loopback transitions). <div><p>It seems that if a State Machine instance performs a transition that loops back into it's previous state, the record is not saved (because no fields have been modified?). The desired behaviour though, is for updated_at to update, to note the time the transition took place (same as it happens in non-loopback transitions).</p></div> 18062 0 It seems that if a State Machine instance performs a transition that loops back into it's previous state, the record is not saved (because no fields have been modified?). The desired behaviour though, is for updated_at to update, to note the time the transition took place (same as it happens in non-loopback transitions). <div><p>It seems that if a State Machine instance performs a transition that loops back into it's previous state, the record is not saved (because no fields have been modified?). The desired behaviour though, is for updated_at to update, to note the time the transition took place (same as it happens in non-loopback transitions).</p></div> false 2009-08-10T10:48:39-04:00 65780 --- {} 28 loopback-transitions-dont-appear-to-update-rails-record 0 13288 new 2009-08-10T10:48:41-04:00 65780 onitony onitony Aaron Pfeifer http://pluginaweek.lighthouseapp.com/projects/13288/tickets/28 18062 0 Thanks for the report and nice catch. This would definitely be a problem if the ORM only saves a record when the field has been really been changed. I'll work on getting a fix applied over the next day. <div><p>Thanks for the report and nice catch. This would definitely be a problem if the ORM only saves a record when the field has been really been changed. I'll work on getting a fix applied over the next day.</p></div> false 2009-08-10T12:31:24-04:00 65780 --- :state: new 28 loopback-transitions-dont-appear-to-update-rails-record 0 13288 open 2009-08-10T12:31:29-04:00 18062 Aaron Pfeifer onitony Aaron Pfeifer http://pluginaweek.lighthouseapp.com/projects/13288/tickets/28 18062 0 (from [bcaafa8eb3308c78c64a404e9c3ca0ccf2c4bb5f]) Fix loopbacks not causing records to save in ORM integrations if no other fields were changed [#28 state:resolved] http://github.com/pluginaweek/state_machine/commit/bcaafa8eb3308c78c64a404e9c3ca0ccf2c4bb5f <div><p>(from <a href= "/projects/13288/changesets/bcaafa8eb3308c78c64a404e9c3ca0ccf2c4bb5f" title= "Changeset [bcaafa8eb3308c78c64a404e9c3ca0ccf2c4bb5f]">[bcaafa8eb3308c78c64a404e9c3ca0ccf2c4bb5f]</a>) Fix loopbacks not causing records to save in ORM integrations if no other fields were changed [<a href="/projects/13288/tickets/28" title="Ticket #28">#28</a> state:resolved] <a href= "http://github.com/pluginaweek/state_machine/commit/bcaafa8eb3308c78c64a404e9c3ca0ccf2c4bb5f"> http://github.com/pluginaweek/state_machine/commit/bcaafa8eb3308c78...</a></p></div> true 2009-08-10T21:59:11-04:00 65780 --- :state: open 28 loopback-transitions-dont-appear-to-update-rails-record 0 13288 resolved 2009-08-10T21:59:12-04:00 18062 Aaron Pfeifer onitony Aaron Pfeifer http://pluginaweek.lighthouseapp.com/projects/13288/tickets/28 18062 0 Aaron The patch also creates another issue with ActiveRecord. I've attached a fix to this ticket. Unfortunately I didn't have the time to dissect your test cases and update the tests for ActiveRecord, but I did write a test file that you can drop into the root of the state_machine project and run. The test file is gisted here: http://gist.github.com/204224 The long and the short of it is that when combined with the acts_as_audited plugin (http://github.com/kennethkalmer/acts_as_audited) the state changes are impossible to track. Inside write(), the call to state_will_change!() forces the changes hash to have the new state as the before and after values, which is not desirable at all. The audits, which work by way of sweeper or callback doesn't gain access to the original state before the transition. Best <div><p>Aaron</p> <p>The patch also creates another issue with ActiveRecord. I've attached a fix to this ticket. Unfortunately I didn't have the time to dissect your test cases and update the tests for ActiveRecord, but I did write a test file that you can drop into the root of the state_machine project and run.</p> <p>The test file is gisted here: <a href= "http://gist.github.com/204224">http://gist.github.com/204224</a></p> <p>The long and the short of it is that when combined with the acts_as_audited plugin (<a href= "http://github.com/kennethkalmer/acts_as_audited">http://github.com/kennethkalmer/acts_as_audited</a>) the state changes are impossible to track. Inside write(), the call to state_will_change!() forces the changes hash to have the new state as the before and after values, which is not desirable at all. The audits, which work by way of sweeper or callback doesn't gain access to the original state before the transition.</p> <p>Best</p></div> true 2009-10-07T13:20:32-04:00 65780 --- {} 28 loopback-transitions-dont-appear-to-update-rails-record 0 13288 resolved 2009-10-07T13:20:34-04:00 21335 Kenneth Kalmer onitony Aaron Pfeifer http://pluginaweek.lighthouseapp.com/projects/13288/tickets/28 bc21e0c5e80bc5ff3a518bab329dbb6c990967d6 text/plain 2009-10-07T13:20:32-04:00 0001-state-attribute-should-only-be-marked-as-dirty-if-it.patch 288778 1118 21335 http://pluginaweek.lighthouseapp.com/attachments/288778/0001-state-attribute-should-only-be-marked-as-dirty-if-it.patch