Proposal for funded work to improve several core features (CiviEvent and CiviCase)
#1 and #2 Custom Event Badges with Bar Codes
Users will be able to configure, name and save an unlimited number of event badge templates using the steps below. The workflow for printing event badges will be the same as it is today. For a batch of badges … Find Participants > Select N Participants > Print Event Name Badges (action) > Select from list of user-configured event badge templates (layout) and select from a list of supported badge label styles (e.g. Avery 5391, Avery 8395, etc.). Your client can select the 3 styles to be supported initially.
Configuring Event Badge Templates
Saved event badge templates will control the content and layout for an event badge (similar to step 4 in the EventBrite process: http://help.eventbrite.com/customer/portal/articles/426329-print-name-badges). For each template, the user will select the data they want to appear on each line along with font style, color and size. The will be able to pick from a list of core and custom contact and participant fields. In addition they can specify that they want a barcode included for a given 'line'. Bar code will be composed from first name+last name+contactID+participantID.
Users will be able to 'design', name and save any number of templates.
We will research allowing the template layout to also include an uploaded logo. We will want to provide a fixed set of options as to logo placement (top, bottom, left …) relative to data lines - your client should provide input on this.
Est: 50 hrs for implementation without logo support
This includes 5 hrs researching logo and image handling. We will get back to you with additional cost estimate for this feature.
#3 Activity Reference
Activity Reference will be a new type of custom field that can be used to extend Activities. Configuration of the custom field allows user to filter the activities available in the auto-complete select widget by:
* one, several or any activity type
* limit to other activities in the current case (Y/N)
Est: 40 hrs (includes required extensions and tests to the activities API).
#4 Relative Dates for Case Activities
We'll use the 'reference activity' properties already defined in the existing Standard Timeline for each case activity (CaseType.xml files). The timeline already provides a way to say 'activity x date is set relative to the date of the reference activity'. We would extend this by adding a 'dynamic' property at the case type level. If true, any change to an activity date would trigger a method which would determine what other activities in the case need to have dates updated based on "rippling" through the scheduled activities in the case.
The changes would ripple forward or backward (but not bi-directionally) based on whether reference_offset values were positive or negative. This would allow for the 'change deadline' use case you've described (changes ripple backwards in that case).
This approach would not support changing the rules on the fly for a given activity - relative date rules are fixed in the .xml file for each case type.
(Lobo and I rediscussed the alternate approach of a single 'schedule controller' (e.g. Deadline activity) - and we think the above design is more flexible and works nicely for cases where the end-point (e.g. Deadline) is the schedule control, AND for case where an activity midstream changes which can ripple forward in the timeline (e.g. a software release cycle - alpha is released 1 week late which then pushes out dates for beta and stable releases). This also fits nicely with our current model where any activity can be a reference activity.
Est: 40 hours