There is a lot of under the covers metadata that has to be dealt with in migration. Ticket metadata is fairly well defined, as far as we get authorship, assigne, cc's, and modified / creation times for searching and sorting.
Comment metadata is another matter. When we first started down this road the decision was made to not worry about comment metadata and so we end up with something like this:
A static identifier for the username from the system of origin, a timestamp, and the migrated comment.
There is a long road of compromises that has lead to this place but the current state is:
- Users create a new account from existing external sources (ldap and sul)
- Metadata for history across tickets of all systems is then associated with this user when they verify the email that they had in the historical system
- Comments are not updated(1) (i.e. remain static for imported content)
Erik raised the point to investigate this further, and so I have looked into it and Mukunda and I have talked it over. Part of the ongoing confusion and untenable situation we find ourselves in is some people find one group of compromises acceptable, and another group may not. The end result being we keep coming back around and renegotiating the issue -- which is not the fault of either group actually. If we knew comment metadata was a full stop for the project I think we may have gone another route for accounts, although I'm honestly not sure as all methods have their big downfalls. It turns out merging history from accounts in completely unrelated and distinct systems isn't super easy.
So here is the proposal from the phabricator team :)
- We can set ourselves up to fix comment metadata in the nicest of nice ways for users
- We don't know if we can do this first run during the actual initial migration window, the time estimates didn't include this thinking. But certainly shortly thereafter, and maybe say once a week, once a month, or every few months for awhile we can batch process things to an amendable state.
- Part of the 'batch run' thinking is two fold. We are not sure how this will impact trying to do it during normal hours (in theory fine) and part of that is it involves having to invalidate some remarkup caching so that updated things are shown correctly. Anytime you start invalidating cache on a broad scale while users are doing their thing chaos can ensue so at this point the thinking is scheduled off-hours runs.
- After said batch runs user foo will now in theory be seamlessly integrated into Phab with history from source only historically identifiable by their external reference id (fl, bz, rt, etc).
I'm thinking 7 or 8 days of upfront work / testing to get this to a solid state. Part of that is lots of testing of partial cache invalidation, Phab only has tooling to support global but that would be pretty heavy handed.
updated the proposal with current thinking