Per Dave Greenberg's suggestion, soliciting suggestions on state changes/plan to complete this MIH (parts 2 & 3 here: http://wiki.civicrm.org/confluence/display/CRM/Self+service+view%2C+update+and+cancel+for+CiviEvent+and+improvements+to+event+badges?focusedCommentId=268271620#comment-268271620)
Cancel (with refund if payment processor allows or not) is fairly straightforward; a cancel with a refund would result in the participant row set to status 'Refunded'; if the refund cannot be processed automatically, email to admin will advise the admin that a manual refund needs to be processed for the initiating participant, pretty much the same as happens now if an admin does a Cancel for a registrant.
Questions arise as to Transfer: I detailed this in the .doc I attached to Issues - the transfer would allow Contact A to transfer their registration to an Event to Contact B (and Contact A would need of course to know Contact B's name and email address, either find them in existing Contacts or enter name/email to create a new Contact). In order to keep track of what happened, I suggested personA's civicrm_participant row be set to status 'Transferred' and a (new) column, transferred_to_contact_id updated with Contact B's contact_id, create new participant row for Contact B and update Contact A's line_item w/ Contact B's participiant_id.
Dave G. suggested the following instead: " Cancel existing participant and line_item records (for Contact A), and create new ones for Contact B. Contact B is going 'for free' in a transfer situation - so no linked contribution record. Could set participant.registered_by_id for Contact B participant record to Contact A (rather than cluttering up schema w/ another FK) - and add a comment in participant.source field: "Transferred from $displayName (and ID, IMO)." Would also be useful to create a new activity - I think we can use the existing 'Change Registration' activity type and set Source to Contact A / Target to Contact B, subject = 'Transfer Event Registration', description = details of transfer"
Any input as to flaws/additions to these plans would be appreciated.
Thank you!
ps the spec I wrote up is attached as a .doc here
