-
Notifications
You must be signed in to change notification settings - Fork 0
02 Integration
Our repository and work is not complete, and will need to be fixed, modified, and transferred from our blank CiviCRM and Drupal site/database running on our own AWS EC2 instance to Autism Ontario's private environment. We believe this process should follow a fairly straightforward structure:
- Add repository to server environment (assumed to be AWS environment).
- Implement the organizational changes on CiviCRM needed to run the volunteer portal (e.g. adding the Volunteer subtype for Individual).
- Modify the API calls calling from ReactJS to CiviCRM to use new variable names.
- Fix known errors in the project and test to remove other errors. Improve on other details as desired.
- Deploy code to production under proper domain name by redirecting from main site.
Firstly, you will have to clone this repository (or fork it) and make your changes there. The ReactJS was written without a dedicated backend, and communicates with CiviCRM over APIs. The code should be able to run fine without a backend other than the data provided through the APIs, but for some design improvements it may be useful to run it using a dedicated backend, such as NodeJS.
The project relies on certain objects and fields being stored on CiviCRM. The portal needs to keep track of which users are volunteers and staff, what kind of staff they are, certain fields in their applications, etc. These subtypes and custom field types need to be created in CiviCRM such that the portal may make use of them. You can read more about the needed data structures in section 03 - CiviCRM Configurations.
As far as we understood custom variables in CiviCRM appear as custom_X where X is a sequential number when being called or returned by the CiviCRM API v3 (which we used due to compatibility issues with Drupal8 ). This makes API calls quite unclear and makes it such that if any of your custom variables are deleted and then recreated they will have a different label in the API calls in ReactJS. You can see these API calls here. When you recreate the custom variables they will have different labels in the API (and possibly different names and types, depending on how you want to structure your fields) compared to our APIs, and thus will need to update all the APIs in the repository to use the new name. This is incredibly slow, but we could not find a work around. Our advice is to create some sort of global table that translates from the custom_X labels to the real labels.
The project was made to prototype a possible solution, but definitely is not ready to be used in a production environment. Many short-cuts were taken to improve testing and now improving security, cleaning code, and comprehensive testing would need to be done. The known issues, as well as suggestions on other improvements and possible problems can be found in the 04 - Known Issues.
After creating the necessary resources in CiviCRM, redoing the APIs, and rigorously testing the code, it's time to take the code to production. We envisioned a button on the main website in the volunteer portal to redirect to that site which is taking real traffic.