Aller directement à la fin des métadonnées
Aller au début des métadonnées

This make it happen project covers a number of improvements to CiviEvent which have been requested multiple times, and will help take CiviEvent features to the next level.

1. Flexible customizable event badges with bar code or QR code

  • Currently CiviEvent supports only a few hard-coded event badge styles. There is no way to control the content, add bar codes or QR codes, specify font size/selection, or control layouts without writing PHP code. The new functionality provides support for configuring and saving  is detailed out here as items #1 and #2.

Est #1 : 50 hours
NOTE: This portion of the MIH is funded

2. Self-service view and update of event participant information (no fee changes)

  • Allow event participants to view and edit selected portions of their registration info (data in the associated profile fields only). This would not cover changes affecting event fees and is restricted to events which provide online event registration - since we don't have profiles for offline-only registration. This should be configurable per event (Allow self-service upates to participant info).
  • Provide option to TRANSFER registration to another person. This would be an explicit link or button which sets a flag and clears the contact-specific fields in the form.
  •  Participants can access change form via:
    • link from the contact dashboard (authenticated users)
    • link from event info page (authenticated users)
    • link from confirmation email (anonymous or authenticated - using authentication hash)
    • event info page may also include input field for anonymous users to enter their email address - and then we can send them email with authenticated hash link

3. Self-service cancellation of event registration

  • Conditionally allow participants to Cancel their event registration. This should be configurable per event (Allow self-service cancellations).
  • Automated refund via payment processor can be supported (configuration option) for processors where we already support recurring contribution cancellation.
  • Participants can access cancellation form via:
    • link from the contact dashboard (authenticated users)
    • link from event info page (authenticated users)
    • link from confirmation email (anonymous or authenticated - using authentication hash)
    • event info page may also include input field for anonymous users to enter their email address - and then we can send them email with authenticated hash link

Est # 2 & 3 : 55 hours

Étiquette
  • Aucun
  1. Jun 18, 2013

    shawn holt dit :

    You might consider adding ability to pay for an event that was marked "Pay Later."  It appears to be quite close to what you are working on and I believe it addresses some common use-cases.  The biggest one is RSVP.  Often an event is announced in advance but payment is not required.  This could be to gauge interest, or the event details have not been finalized.  Perhaps the fee hasn't yet been decided.  Allowing anonymous users to pay for an event with payment pending would be a solution for this.  It also allows "pay later" participants who are late with a check to pay by cc or paypal. It's easy to set up a contribution page, but there is no way to match it to the event.   

  2. May 15, 2013

    One should also be able to cancel registration and not receive a refund, have rules to receive a partial refund, or even receive only a credit for future events.

    I agree with Shawn, that would have helped out a lot for our last event.

  3. Jun 21, 2015

    Is this still an active/desired MIH?   I'm addressing 2 & 3.  Re: transfer registration to another person - that person can be a Contact already in the DB or a new Contact; should just name & email suffice, or name/email/mailing address/city/state/postal code?  What about time allowed before cancel/transfer, should that also be configurable (ie, up to n day(s), n hour(s) before event)?  If payment processor doesn't support auto-refund – Cancellation email should be CCed to CiviCRM Admin to manually deal w/refund or cancellation of charge.

    1. Jun 22, 2015

      There is currently no work in progress as far as I know on items 2 and 3 on this page. Both 'features' would be good additions to CiviEvent - so it's great that you are planning on pushing this forward. Regarding your specific questions:

      • Data for transfer-to participant : a simple solution would be to use the same primary profile as event uses in first position for event registration. By default this is email only, but of course can vary as admin's configure the profile. RE: new vs. existing - makes sense to me to use the existing dupe matching process for this - i.e. the person doing the transfer enters name, email etc. and CiviCRM automatically checks via Unsupervised Dedupe Rule to assign registration to existing contact or create a new one.
      • RE: 'time allowed before event start to transfer / cancel' - this is probably needed for both transfer and cancellation. Maybe use a date-time field for both and if NULL, the operation is not allowed. NOTE: Since this implies a schema change, we'll need to get issue(s) filed in JIRA with details, and at least draft PR's for master in place in the next few weeks if you want this to be part of the 4.7 release cycle.
      1. Jun 24, 2015

        This should be a separate form, not an Extension -but like Cart - where the user can either login/authenticate and navigate to the form or, get to it from a link with hash code from a event registration confirmation Email.  If user is registered for > 1 event, s/he could select all or one at a time - and  select an action (xfer or cancel) - more like in Find Participants. If Xfer, then transfer by entering name/email to xfer to (and find or create contact based on name/email).  Transferee and transferrer should get confirmation of xfer email; cancellation should generate email to user and admn. Re: Activity:  I 'd assume this doesn't require a new 'type' of activity but is another 'event registration' activity where the activity subject will suffice to log the action? 

        1. Jun 24, 2015

          Agreed should be separate form. I'd suggest that link to this form is specific to one participant record (one event registration) - rather than adding the complexity of handling multiple events (at least for phase 1).

          Regarding "find or create contact based on name/email" - keep in mind that it's generally not ok to expose a list of contacts in the DB to (possibly) untrusted users so building a search or autocomplete tool into this UI which queries all existing contacts is probably not desirable. This is why I suggested that match to existing contact would happen programmatically via dedupe rule.

          It would be advisable for you to create an issue in JIRA (Issue Tracker) for this improvement with detailed UI, workflow and schema changes - and then you draft Pull Requests can be posted against that and reviewed.

          1. Jun 25, 2015

            I will add to Issue Tracker - re: UI/workflow/schema changes, I looked at some of the items in the CiviCRM Wiki requirements and specifications - format mostly text, not always accompanied by screen shots (I don't have any at this point!) - I can use MS Word and boxes if that suffices for proposed UI.

            fwiw I have added a custom TPL before to override core behaviour, but not a new one that would be part of the core, I am looking at this (Six simple steps to creating a settings page for your module or custom forms) for a guidline (just for QuickForm/tpl,and not settings functionality) - the ref here (QuickForm Reference) talks about creating Pear QF but doesn't address building a .tpl to work with it)

            1. Jun 25, 2015

              You'll be creating a new .tpl with same name / corresponding path as your .php file. Maybe use a simple existing core form as a model (e.g. CRM/Group/Form/Edit.php and CRM/Group/Form/Edit.tpl). If you need additional guidance, IRC or StackExchange is a better channel than this wiki page.

            2. Jul 02, 2015

              JoeMurray dit :

              FYI, for mockups we generally use https://balsamiq.com/products/mockups/

              1. Jul 02, 2015

                Thanks, Joe 

          2. Jun 26, 2015

            Re: registration transfer - if contact_id in civicrm_line_item is 'transferred' from contactA to contactB, and contactB's id is simply replaced in civicrm_participant, that will make reconciliation with online reg. payment inconsistent. While the payment processor won't 'care', accounting will be screwed up in Civicrm as it would look like contactB paid but civicrm_line_item would have contactA's particpant_id

            In order to prove payment for the event, contactB should get a new civicrm_participant record whose participant_ID should be placed in the civicrm_line_item from contactA's registration. And the civicrm_participant record for contactA should be set to a new status, 'Transferred', with a  new column added to civicrm_participant - 'transferred_to_contact_id', to follow what happened.

            1. Jun 26, 2015

              Thinking out loud...

              Cancellation - cancel both participant and line_item rows. Contribution and financial transaction statuses remain 'Completed'

              Cancellation with refund - same as above, but set contribution status to Refunded (actual refund 'transaction' may or may not happen automagically).

              Transfer - 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." 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.

              Given that there's some complexity in figuring out the optimal way to handle this - I think it best if you post the gameplan on the blog and request some feedback.

              1. Jun 29, 2015

                Thanks Dave - I think your suggestions esp. re: Transfer (and assuming new participant and line_item data for Contact B can be copied from A's but using B's contact, participant_id, and use registered_by_id to document Contact A did the transfer)  I put this in the blog here: https://civicrm.org/blogs/zorga-lina/civievent-self-service-canceltransfer-participant

                1. Jul 02, 2015

                  JoeMurray dit :

                  I agree with this approach too.

              2. Jul 01, 2015

                 For events allowing registration of 'additional Participants',  all participants ( the 'primaryParticipant' and all additional participants) should get the link to cancel/xfer, right? I will just add that to the spec I put in Issues 

                1. Jul 02, 2015

                  JoeMurray dit :

                  This is a nice feature. I can see when multiple people from an org are signed up for an event, it's not uncommon for there to be some later changes on who goes or how many go, and letting those signed up as participants do it would be convenient. 

                  There are some complications, however. The additional participants may not have emails or even names associated with them in CiviCRM in some cases (eg buying a multi-person line item, like a table). I wouldn't try to create functionality to associate CMS users with them as part of this enhancement. If there is an ability to login as that contact, then that contact can cancel or transfer the registration; otherwise not.

              3. Jul 02, 2015

                Re: transferring civicrm_line_item - that table doesn't seem to have a status, so I gather it derives it's 'status' from the row in linked entity_table, participant/contribution). So once I cancel ContactA 's participant row, it seems I'd need to replace entity_id w/ContactB's participant_id - or 'soft delete' the original line_item, though again I don't see a column for that.  In reports I've created for people at my org. I check the participant status when reporting on line_item data.  A hard delete wouldn't fly! Adding a status to line_item would mean  more code updates in the rest of the system. If I'm wrong about the schema, let me know, thanks!

                1. Jul 02, 2015

                  Lesley - For TRANSFERS, my initial inclination would be to leave the existing line_item(s) alone - since they are linked to a participant row (via entity_table/entity_id) which is now cancelled. Then insert new line_item(s) linked to the new participant row. New line_item(s) are also linked to the existing contribution row (via contribution_id), since that contribution represents the payment for the transferred registration.

                  Joe / Eileen - does that makes sense to you all?

                  1. Jul 02, 2015

                    I agree - leave the line_items for ContactA as is (cancelled by association w/cancelled participant ContactA) ; create new line_item(s) for ContactB. 

                    Another thought - validation needs to verify that ContactB is not already registered for this event, or another event whose start_datetime -end_datetime overlaps this event datetime 

                    1. Jul 03, 2015

                      JoeMurray dit :

                      As standard behaviour CiviCRM doesn't prevent people from registering from simultaneous events. They might want to go to part of each, or there might be odd use cases where it makes sense in some other way. I'd prefer to make this sort of a validation rule into a custom extension if your organization needs it.

                      CiviCRM does prevent multiple registrations by the same person in the same event, so that validation needs to be implemented. Good catch.

                      1. Jul 03, 2015

                        Okay, I will just validate whether  they are already registered for this event. I know that Event Registration doesn't prevent registering for overlapping events now and thought it might make sense to do that.  I also see that in the case of a conference you may register for 2 events at the same time and if the first one doesn't seem so hot you'd be able to go to the other one

                  2. Jul 03, 2015

                    JoeMurray dit :

                    Yes, cancelling old and creating new line_items makes sense to me as a way to implement transfer of ticket from A to B when line_item is for a single ticket.

                    IIRC, when additional participants are added in the UI this results in one line item per participant. If so, then so long as the code properly handles the distinctions between first and additional participants it should be fine. Dave, am I on the right track here?

                    One area that should be out of scope is for unnamed participants, like when a line_item indicates that 8 participants are sharing a table.

                    1. Jul 03, 2015

                      If the line_item indicates, say, 8 participants (price set allows selection of number of tix rather than value), the 'holder' of the registration is still one registrant whose contact_id is linked to the line_item. S/he can transfer that registration to another person, it doesn't affect the 7 others. Perhaps I can say that in any registration scenario where a participant doesn't get her/his own confirming email s/he can't do the self-svc cancel/transfer

                      1. Jul 06, 2015

                        Agreed. Only individuals represented by a participant record should be eligible to do self-service cancel or transfer.

                        1. Jul 06, 2015

                          JoeMurray dit :

                  3. Jul 10, 2015

                    Dave,  I used a call to Participant::sendTransitionParticipantEmail to send a conf. email to transferrees - with an additional argument - that sends the Events Confirmation Invite (as opposed to the 'Event Confirmation online/offline' email) - as the Event 'transitioned' to a new participant.  

                    In both that template and the online Event Conf. template, I expect to add conditional script for the 'self svc' link +hashcode (conditional on the event 'allow self-svc' flag).   My question is whether those template changes would be part of the patch/updated code or included as part of install instructions?

                    thanks!

              4. Jul 10, 2015

                In order to not modify Participant.php (which logs Activities for registration), after a Transfer I could retrieve the Activity created for the (new) participant created by transferring the event, and then call createFollowUpActivity to document the transfer in civicrm_activity - otherwise, I would need to modify the Participant::create or add a new version of it, I think.

                Another question- the 'Transferee' should get a Confirmation email with a link that would allow her/him to do a self-cancel/transfer again, since the Event is flagged as allowing that, right?

                And finally - do think think it's better to modify the Confirm email (to allow for the self svc link) rather than create a new template?

                Thanks

                1. Jul 10, 2015

                  JoeMurray dit :

                  Which Participant.php are you meaning - a form one or a BAO one? I would guess you are intending to create a new Form, and then use the API which would access the BAO.

                  Assuming this is a core enhancement then I would modify Participant.php to do the necessary.

                  Yes, the contact who receives the transferred participant signup should get a confirmation email (as they aren't transfered, I don't like the idea of calling them a transferee). The current confirmation email template should be changed so that for events that allow self-transfers some text and a link about this should be included. Similarly for events that allow self-cancellations. 

                  I would look at the template to decide if it was appropriate for a transfer signup. My sense is that all the financial info etc in original email should be sent to transferee, so the same template would make sense.

                2. Jul 10, 2015

                  Regarding points 2 and 3 above ... I think it makes sense to use the standard online event confirmation message template / contents for the new (transferred to) participant. So that output would also conditionally include the self svc transfer / cancel link if applicable at that point for the event. I think it's fine to add conditional logic of the existing Confirm message template (rather than create a new message template.

                  Regarding install / upgrade for message templates...

                  • The pattern for message template upgrades is to insert the new version of the message template contents. Refer to /CRM/Upgrade/4.6.alpha4.msg_template directory and reference to include in /CRM/Upgrade/sql/4.6.alpha4.mysql.tpl for an example.
                  • The pattern for message template changes for installs is to update the corresponding files in /xml/templates/message_templates
                  1. Jul 18, 2015

                    While it makes sense on the face of it, the standard Confirmation message carries data that I won't have after the initial event confirmation - e.g. billing name and address, transaction date/no. - and the 'transfer' confirmation email has just enough (the event, event datetime, event location, name & email of participant) to tell the transferree what s/he needs to know.  The use cases are different for the 'initial' confirmation, and a confirmation email after transfer, when the transferee details aren't known

                    Thanks for info re: msg templates

                    1. Jul 15, 2015

                      You mean this page: https://github.com/civicrm/civicrm-core/tree/master/CRM/Upgrade/4.6.alpha4.msg_template for updates to the .tpl file(s)  and this https://github.com/civicrm/civicrm-core/blob/master/CRM/Upgrade/Incremental/sql/4.6.4.mysql.tpl

                      for the database update?  I don't quite understand why that SQL line has a file extent of .tpl, it looks like it's just standard SQL.

                      1. Jul 15, 2015

                        Yes - you need to follow that convention for upgrades to add or modify message templates. And the /Incremental/sql files (may) contain a combination of standard SQL and smarty expressions. Reference info here: Upgrade Reference

                        1. Jul 16, 2015

                          Thanks - I see that some of what I'd expect to see in a template file is actually stored in the civicrm_msg_template table (like the subject).  Regarding generating  checksum url - I would set it up like the url in the confirm invite msg_html field, w/a contact.checksum and use that for the url/link I generate in the conf. email...and add a new field to civicrm_msg_template for this link field

                        2. Jul 18, 2015

                           I added a new column to civicrm_msg_template for the 'self service'  link; it is not visible to edit; should it be inserted into the message body, so that Utils/Mail::send will put it in the confirmation body?  It isn't an attachment, so the self-service link should be inside <body></body>, right?

                          1. Jul 20, 2015

                            Lesley - Why can't you use the same exact mechanism for self-service link as is used for the evetn Confirmation Invite flow? You can construct the 'selfServiceUrl' in the template in the same way was $confirmUrl is constructed. You can have a conditional IF to include that link based on passing in a boolean smarty variable to the message template. Why do we need a new column in the table?

                            RE: where the link goes, it's definitely part of the message content and belongs inline in the BODY.

                            1. Jul 20, 2015

                              Hi Dave - Right, NO need for a new column in the message_template/table, I was confused.. If I could have deleted my last comment I would have. I will insert a new 'if..(allowed_self_svc_cancel and diff (event.start_date, now) <event_selfsvc_timelimit ...} in both confirmation_online_html.tpl and _text files as part of the update (and I found the token contact.checksum will generate the 'cs=...' part of the URL).

                            2. Jul 22, 2015

                              Re: email to 'admin' to alert them to a cancellation (and need for refund), I didn't see a template for something like this in System Workflow - should I create a User-driven template and include that (as .tpl) or simply format a  message in PHP for the cancellation post-processusing the configured 'from email address' and address it to the 'contact email address' from the 'Organization Address and Contact Info' profile, to say that 'display_name's participation in 'event.title' was cancelled, the participant needs to be refunded.

                              1. Jul 22, 2015

                                I'd suggest triggering send of the existing "Events - Registration Cancellation Notice" in postProcess - with a hard-coded CC to the event's 'cc confirmation' email address if present, else organization contact email address (as you indicated).

                                I don't think we need to say anything about 'participant needs to be refunded' since we don't know if that's the policy for that event / situation.

                                1. Jul 22, 2015

                                  Thanks, good idea - I am sending the Event Reg.Cancel and will CC the event's 'conf email' if set, and otherwise org. contact email.

                                   

                                2. Jul 23, 2015

                                  When I submit this it will include 2 new forms & template files, updates to Event Mgmt (fields for allowing self svc, time_limit for self svc), Event DAO updates, update to Event menu xml, confirmation templates and database updates.

                                   Should I create a web test using Selenium?  Other unit tests? I didn't add to or modify core API, and when I submit to GitHub 'lint' style and js tests will be run. Do I just create a PR off the main branch for this as I had for other updates?

                                  1. Jul 24, 2015

                                    Selenium web tests would be very good to include. If there are changes or additions to BAO(s) - unit test(s) should be added or updated.

                                    PR against 'master' branch please.

                                    1. Jul 24, 2015

                                      No BAO changes - only DAO  - re:Selenium, that requires Drupal, right? (using WP for my frontend)

                                      1. Jul 24, 2015

                                        Yes - Selenium test suite currently only runs on Drupal + CiviCRM. Would be great to extend it so it can run on WP. Might 'only' need params / switch for login / logout and a few other methods in CiviSeleniumTestCase.php - in case you're interested in exploring that.

                                        1. Aug 16, 2015

                                          Committed updates ('add'ed new .php and .tpl files in Event/Form) did push to master and then reqested PR - should I not see in my branch?

                                          1. Aug 19, 2015

                                            Lesley - I'm not seeing a Pull Request (PR) posted for this on Github. Can you do one and then add link to the JIRA issue (https://issues.civicrm.org/jira/browse/CRM-16761). If you need get stuck w/ doing the PR - best to jump on IRC.

    2. Jul 02, 2015

      JoeMurray dit :

      With respect to payment processor support for auto-refund: we should break this out from support for cancelling recurring payments, as it is a different functionality. Eileen is currently doing a significant rewrite of payment processor stuff with a small team of helpers, so it would be good to have her spec this out.

  4. Jul 02, 2015

    JoeMurray dit :

    You may want to create additional permissions for a) cancelling a participant and b) if you decide to support it, refunding, where refunding involves a payment through a different means that a reversal of an electronic payment previously received. Whenever money is being sent out of an organization there is a possibility of fraud, so it can be useful to have a different person involved. For example, to ensure that a staff member's friend doesn't get to attend for free.

    Cancelling a payment is one type of 'refund' from a bookkeeping perspective. This is simple and appropriate when the payment can be immediately reversed through the same payment method, eg refunding through the payment processor. FYI, there are other types of refunds that are sometimes required that are more complex from a bookkeeping perspective. For example, if a refund has to be made through a check, the funds to be refunded may need to be put into an accounts payable account until the next check run.

    Not wanting to overcomplicate your use case and initial implementation, but here are some additional possible features, perhaps for a future phase:

    •  Having the ability to charge a fee for cancellation/refunds. This is commonly done to cover bank charges, and to discourage cancellations since expenditures might be made in anticipation of attendance, eg on food.
    • Having a cut-off date for cancellations for an event.
  5. Jul 02, 2015

    Thank you Joe - hopefully Eileen McN. will weigh in - so, in a first pass at this, perhaps I should just implement 'cancellation' as it is now - that is, update the participant's status, log the Activity, and email admin and participant to confirm the cancellation and ensure that a refund is processed if appropriate. The org. I work with has to manually process refunds/cancellations through Authorize - and of course it'd be necessary to verify that payment went through before processing a refund. If payment was by check, then it seems refund must be manual.  Re: charging for a refund - good point, as not only the bank charges but staff 'effort'/time or material cost is possibly involved. Could that be a 'price' that is conditional? (e.g., is there a capability for things like 'late payment' fee? Not being au courant on financial things - would the participant not have to submit her/his CC # (again) to process the cancellation fee or would it just be 'subtracted' from the refund total?

    Re: cut-off time/date, I do have that in my spec. Cancel/transfer must be done 'n H/D' before event.start_datetime - that, and a boolean 'self-canceleable' field need to be added to Event object.

  6. Jul 02, 2015

    JoeMurray dit :

    Let me see if I can put together a Refund API to assist you. 

    For initial phase, it sounds like you need to be able to process refunds manually for both Authorize.net and checks. We may be able to leave processing reversal automatically through payment processors to a later phase - Eileen would be better informed about how many of our plug-ins could support this.

  7. Jul 12, 2015

    The discussion we have had about automagical cancellation is that there would be an api that wraps the payment.refund api - called something like payment.processrefund. It would look something like

     

    function _api3_payment_processrefund($params) {
    $payentProcessor = Civi\Payment\System::singleton()->getByID($params['payment_processor_id']);
       if (!$paymentProcessor->supports('refunds)) {
            throw new API_Exception('refunds not supported');
       }   $result = $paymentProcessor->doRefund($params);    
       civicrm_api3('payment', 'create', $result);
    }

     

     

    Each payment processor would implement (or not) the refund functionality by adding the functions supportsRefund & doRefund

    1. Jul 16, 2015

      Thank you Eileen - I am planning at this point to just try to wrap up cancel/xfer functionality where cancel sends email to the originating participant and sys. admin, to manage refunds manually and add on if/when the first version is accepted


Creative Commons License
Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-Share Alike 3.0 United States Licence.