Does state_machine + paper_trail make sense?

[Gurpartap Singh]

Hi,

This would be my first encounter in setting up an established state machine protocol in a model. Before I continue, I would also like that the model is versioned and persists even after deletion. For this, I'm considering the paper_trail gem. However, this brings me to a question, does state_machine play well with paper_trail's version revert (undo and redo)? I'm at this question, since I believe, state_machine would have it's specific mechanism to make sure whether it can go back or not. (But I guess undo/redo is an action at a different layer).

So, do they make sense to be used together?

--

Gurpartap Singh

[Gurpartap Singh]

I'd also like to add that I mainly want to benefit from paper_trail's soft deletes and auditing, instead of version reversion. But I'd like it to be possible, which is why I'm asking. :)

(I know there's an audit-trail gem for state_machine but paper_trail's versioning gives an intact snap shot of the object from past.)

--

Gurpartap Singh

[Gurpartap Singh]

Just realized that paper_trail doesn't make the deletes soft but retains the version in it's separate table. So, whatever, I can live with that.

[Gurpartap Singh]

Been trying it. No conflicting behavior yet. So far so good.

[Aaron Pfeifer]

Hey Gurpartap,

This is an interesting question.  I don't know the paper_trail gem very well, but I wouldn't expect any conflicts here.  state_machine really only restricts state changes when done so through the invocation of an event.  Outside of that, state_machine will only have validations that ensure that the record is valid in a given state.

My guess, however, is that paper_trail's version revert feature since rolls back the values of the record's attributes without running any validations.  If you do run into any conflicts, definitely let us know!

-Aaron