This week I hoped on back into a project that I did during my internship here, i.e the Competition Registration System (CRS). Basically, some changes and enhancements are needed to be made, and the registration period for the competition starts next month.
Some enhancements include splitting up the composer’s name and the repertoire to two separate text fields instead of one, since a lot of registrants forgot to put the composer’s name last year. Last year’s registration also had the continuous problem of registrants giving invalid duration time for the repertoire, even when we have specified the valid format. Thus, the duration is now a drop down selection instead of a text field, which values contain valid time formats. Finally, registrants must now give the participant’s contact email for direct correspondence, e.g: sending a reminder email before the competition.
After creating the mock products containing those enhancements in their WooCommerce store last week, I proceeded to make the necessary changes to the codebase of CRS. It just needs to read in new values from the JSON payload, so implementation was rather quick and simple. Of course, I had tested to see if I had made any broken changes. It is very tempting to refactor a lot of things in the codebase. I keep questioning myself, why I did it that way in the first place, when there is a much better and simpler way to do it as I realize now. But I learned to prioritize, so only if there is ample amount of time later, I may do it.
Another enhancement to CRS would be to integrate POP3 email checking. This is what I had done for my previous project as well. This feature is for the purpose of periodically having a POP3 server pull mail from a dedicated mail inbox, where the emails, with registration slips attached, are sent out to the registrants are BCC-ed to this email address. The UUID of the order is placed in the ‘From’ header of the email. Hence, CRS would retrieve the mails from the POP3 server, delete those mails once retrieved and cross check with the orders stored in the database, to determine if the email has been sent successfully.
The Orders table in the database now has a new boolean field to indicate whether the email for that particular order was sent successfully. By default, it is false(0). CRS would retrieve a list of orders, where that boolean field is still false(0). During the cross checking process, if there is an email containing the UUID for an order, then that order would be updated such that the boolean field is now true(1). Otherwise, there is a window period to determine if the sending of email is long overdue, and if it is, CRS would send an alert to the appropriate recipient.
I have not tested the POP3 procedure thoroughly, but I guess that would be next week’s agenda. I also need to put the participant’s contact email in the TSV output, which will contain a list of all the registered participant’s for a particular venue and competition. Stay tuned.
0 Comments