Specifications for Online Registrations and Application forms: Difference between revisions

From OpenPetra Wiki
Jump to navigation Jump to search
 
(2 intermediate revisions by the same user not shown)
Line 6: Line 6:
* 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.
* 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 later and continue working on his application, partner decides when to send off the application.
* Partner can come back in a years time to register for another conference, and does not need to enter all his data again, only updates his data.
* 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.
* Other references 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?
* 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
* 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)
* 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)
Line 15: Line 15:
* Application forms are coded with yml for ext.js, generateWebforms
* Application forms are coded with yml for ext.js, generateWebforms
* Import into local Petra 2.x or OpenPetra, using CSV files or web services
* 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?
* 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
* see [[Implementation of Online Application Forms with OpenPetra]]

Latest revision as of 14:38, 5 November 2010

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
Retrieved from ‘https://wiki.openpetra.org/index.php?title=Specifications_for_Online_Registrations_and_Application_forms&oldid=958’