Specifications for Online Registrations and Application forms

From OpenPetra Wiki
Revision as of 14:38, 5 November 2010 by Pokorra (talk | contribs) (→‎Thoughts about the implementation)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Purpose

In order to save time and effort for the local office staff, people that used to fill out paper forms should be able to fill out web forms, and send the result electronically. For the office staff it has to be easy to import this data into the production OpenPetra.

Wish List

  • Send an email to the partner and to the office, with an attached PDF, to inform about the application being sent off
  • Support a workflow where approval of the application happens only after the printed and signed PDF arrives at the office, and the office confirms the application. The office must be able to deny an application as well.
  • Partner can come back later and continue working on his application, partner decides when to send off the application.
  • Partner can come back in a year's time to register for another conference, and does not need to enter all his data again, only updates his data.
  • Reference persons should be asked to sign the application, or to add a comment about the applicant. This could be done with a secure link, but how to verify that it was the reference person who approved the application? send an email only to that person?
  • Application forms must be translatable
  • for international events, each country needs a localised version of their application form (different prizes, different payment methods, different questions about journey to the event etc)

Thoughts about the implementation

  • OpenPetra webserver serving the Online Application
  • Application forms are coded with yml for ext.js, generateWebforms
  • Import into local Petra 2.x or OpenPetra, using CSV files or web services
    • Upload/resync partner keys and application status (denied/accepted) to Web OpenPetra
  • Assistant functionality: probably not implemented in javascript, but separate forms, so that changes get stored in the database immediately?
  • for the office: online reports about applications. reason: quicker to update than each Petra installation