We've got a ways to go here. All card content changes are logged and in principle reversible, but:
- there's no way to do bulk rollbacks
- there's no interface for restoring trashed cards
- changes to fields other than content (eg type, name...) are not logged.
There's some design work for #3, but it's a good chunk of work. #2 is easier but not designed. #1 is neither easy nor designed...
re #3, see track name and type changes
--Ethan McCutchen.....2013-03-25 18:29:43 +0000
Thank you Ethan for such really fast answer.
Maybe a dirty hack: I think for ad 1) we could rely on the database engine. Of course, you would need to detect running DB. If you would have interface which would mysqldump (pg_dump). The question is whether you want to do this kind of interfacing to the DB. Anyways, it would be a way to store a "state" of wagn and return to it.
Anyways it would be good to have something like system snapshot to have means to return validated state. The idea is to have wagn work as
automata. e.g. you would have a saved states and current state. Anytime you would like would current state became a stored state.
ad 2) That would be covered by ad 1)
ad 3) Wouldn't that slow down wagn? If everything was stored then the slowdown could be considerable. Maybe if there would be a way to switch it off.
--Tukanos.....2013-03-26 10:28:39 +0000
1. While we don't have anything specific to Wagn, we can and do export and restore make total (file and db) backups on Wagns on Cloudstore. It basically just zips up a db dump and the files, but it's remarkably easy to work with. Most relevant point of that is that this relieves most of *our* pressure to build something custom, though that's not much help for people running their own installations... But that's predominantly low-level folks anyway, and in most cases the db dump is really all you need to get back to a good state. (and is advisable to do often!)
2. I would worry about slowing down Wagn if we were tracking views, but not from tracking name and type changes. Card updates actually turn out to be a comparatively small portion of calls, and given our recent efficiency gains, I'm confident this would be pretty low cost for the value.
3. I should clarify about the "no interface". If you delete a card named "Axe" and then create a new card named "Axe", the old revisions show up in the history and can be restored. So there is, in that sense, very minimal interface, but no way to query trashed cards.
--Ethan McCutchen.....2013-03-26 16:29:30 +0000
re the permission inheritance, you should have a checkbox to inherit (below individuals) on any plus card.
--Ethan McCutchen.....2013-03-26 16:31:35 +0000
ad 1 + 2) thank you for clearing this :)
ad 3) Wouldn't there be a way to have in the DB a notice that this card was rendered successfully in this version. If things go wrong and you get an exception you could offer the user to return to the older revision as a solution for now. I don't know how much redesign would that mean for you.
ad) I'm function blind, can't find the checkbox for permission inheritance -
--Tukanos.....2013-03-27 16:49:01 +0000
hmm, I think that must have been recently fixed? It works for me, and that interface has been worked over. (Actually improving it still...)
I don't understand your comment on #3, perhaps because I don't see how successful rendering is related. There is currently a trash flag in the cards table. If it's on, there's not a way to see the card or know it's there, but that's because we haven't built interface for it, not because there's a db issue. You can still access old revisions by re-creating a card of the same name, but you have to know the name.
So the short of it is that if we design good interface for exploring trashed cards it can probably done. The hard part may be insuring that we don't confuse our caching system, but even that is probably resolvable without too much grief.
--Ethan McCutchen.....2013-03-27 17:39:33 +0000
I see, this was not available to version 1.10.6 I have upgraded to the lastest version 1.10.10 which indeed has the checkbox and much more :). That brings me to one more question is there a detailed change log (I know I can check github's source codes...) between the versions? (Like the checkbox change we were discussing) Maybe there is one but I fail to find it.
The ad 3) I will try to show you what happened to my wagn:
When I try to access history I can also an error:
Anyways, back to the the map question. My original idea was to create a complete map of cards, connections and permissions.
This would create a state similar to virtual machines' snapshots. You would have a state of wagn to return to. I imagine this would
make configuration of wagn way faster as you would just try it if this works for you or not, without using ordinary db tools. I can imagine
this is not a priority right now :).
--Tukanos.....2013-03-28 16:44:37 +0000
As far as your bug, the first thing I would try is clearing the cache. If that doesn't work, then you may have a data issue. It appears to be looking for a card revision id 5764 that doesn't exist.
Got to run to Wagn Circle call now (can you join us?) but I can give more detail if needed later.
As for the state question, I think the import/export ideas we're working on would largely address this need. More on that soon, too!
--Ethan McCutchen.....2013-03-28 16:50:26 +0000
I tried to clear the cache but it does not help :(. I don't know what happened, the card was there and then it wasn't :). Well I will recover it from backup. I'm just wondering what happened with the card as it went completely hawok. I will be better prepared for the next time.
I would love to join the circle, unfortunately I don't have time at the time you gather. I usually try to watch it on the saved videos!
Anyways back to the topic. I thought little bit about the storing the map. Maybe that s not even needed what would be enough is a way how to undo the last action.
If you configure your wagn and make a mistake and want to return back you need to go to your backup.