overhaul card history

+status

open

+priority

low

+tag

history

cards

Design

+issues

Currently, we only track content changes, and the history provides limited functionality.

+solution

These may be broken into several separate tickets, but let's list what we'd like to see. Logging:

log cardtype change
log name changes
log deletion/recreation

Changes tab:

shift from current one-version-at-a-time to listing all versions back through time, both content and above-listed changes
diff between arbitrary versions
also list settings changes? (these are logged in the relevant cards, including permissions after we setting-ize permissions) Maybe only +*self settings changes? Hrm.

also see show history of inclusions and forms

I think we are getting to the point that this should be done soon. In the long run, we want a deeper refactor of revisions, but at a minimun we need to add a) type and name changes to revision history, and b) grouping changes in revisions to a single model event. All we really need here is a field with the revision_id of the 'head' change of the event (event_id maybe?) and then do the revision search/list per each event_id which could have many revision_ids. It may also be useful to be able to join several model level events to the same event_id based on being close in time and from the same user/session.

--Gerry Gleason.....2013-06-08 18:00:12 +0000

can you connect this argument to a biz/community rationale? I really want this, but it's not a priority I'm hearing from clients / users.

--Ethan McCutchen.....2013-06-08 21:27:36 +0000