fixed db dumper link

Author: dunkOnIT

guides/misc_notes.md

@@ -0,0 +1,20 @@
+---
+title: Creating React Components
+parent: Guides
+layout: default
+---
+
+## Creating Competitions With Database Entries
+
+1. Create an entry in the Competitions table
+    1. Find an existing competition in the database that you want to use as a reference/basis and export it as CSV
+    1. Make changes to the CSV as required
+    1. Remove the headers from the CSV and save it
+    1. When in the Competition table in phpmyadmin, click "Import" and upload the file
+2. Create delegate report entries for the relevant comp
+    1. In the delegate reports table, export the row relating to your template competition
+    1. Edit the CSV to have the correct competition_id, and duplicate the row for any additional comps you created
+    1. Run "SELECT MAX(id) FROM `delegate_reports`" in phpmyadmin to get the max id of the table - make sure that your id columns start from the MAX(id)+1 and increment
+    1. Import to the delegate_reports table
+3. Add competition_events (similar process to creating delegate reports)
+4. If needed - add competition_organizers and competition_delegates, again using a similar process to the delegate_report imports

knowledge_base/_payments.md

@@ -0,0 +1,59 @@
+---
+title: Payments
+parent: Knowledge Base
+layout: default
+---
+
+NOTE: This page is still under construction - Paypal is not yet implemented in the live website. 
+
+The WCA website primarily uses Stripe for its payment processing, but WST is in the process of adding Paypal as an additional payment processor, on top ofa more generalized payments adapter which should make it easier to add more payment services in future.
+
+## Generic Payments Workflow
+1. A competition must have a `ConnectedPaymentAccount` in order to accept payments from a specific payment provider
+    1. This is a polymorphic association, meaning that we can created multiple payment provider models (`ConnectedStripeAccount`, `ConnectedPaypalAccount`, etc) which an organizer can establish an association with, by linking their `Competition` via a UI we provide.
+    1. The `ConnectedPaymentAccount` will have the details of the organizers 'merchant' account with the given payment provider, allowing us to provide payment links to the user
+1. Once a user registers and moves onto the payment step, we create a `PaymentIntent` object indicating their desire to pay with the selected payment provider
+    1. Currently, organizers can only link one payment provider. In future, users may be able to choose the which payment provider to use if both are 'connected' to the `Competition`
+    1. This `PaymentIntent` will be matched with an underlying `PaymentRecord` from the payment provider if possible (`StripeRecord::payment_intent` in the case of Stripe, `PaypalRecord::order` in the case of Paypal)
+    1. Note that the creation of the `PaymentIntent` happens BEFORE the user attempts payment - it is created as soon as we know they MIGHT want to pay
+1. The user initiates payment, triggering either a push-based or pull-based process depending on the provider
+    1. Pull-based: We inform the provider that the user would like to pay, and 'capture' the payment (Paypal uses this system - we 'pull' the payment from the user/provider) (OR IS THIS AN OPTIONAL STEP IN THE GENERIC PAYMENT PROCESS?)
+    1. Push-based: The user interacts directly with the payment provider, and the payment provider informs us of the outcome of the payment (the payment provider 'push'es a notification of the payment outcome to us)
+1. We record the outcome of the payment
+    1. This often involves matching up 'atomic' records of payment from the payment provider (Stripe: 'charge', Paypal: 'capture') with our internal `PaymentIntent`.
+    1. First we create new `PaymentRecords` for the relevant atomic unit and create relationships between them and their parent `PaymentRecord`
+    1. Then, we call a method which updates the WCA `PaymentIntent`
+    1. If the payment was successful, the `PaymentIntent` will create a `RegistrationPayment` object. This is the record which is used to determine is a user has paid for their registration.
+
+
+## Stripe Implementation
+
+## Paypal Implementation
+
+_Paypal is currently in a proof-of-concept phase in its implementation - the following reflects expedient design rather than good design, and there is room for improvement._
+
+A Paypal payment consists of the following steps:
+1. An Order is created on the Paypal website - this includes information such as what is being purchase, in what currency and for what amount. 
+2. The Payer approves the order - they are redirected to a Paypal web interface, where they are shown the details of the order and given a payment method to select. FUNDS DO NOT FLOW AT THIS STAGE
+3. A "Capture" request is raised against the Paypal API - this is what initiates the funds transfer (ie, the Merchant is "capturing" the funds which the Payer has approved to pay in Step 2). 
+
+### Under the hood, this works as follows: 
+1. We use the Paypal SDK to display a "Pay with Paypal" (or similar) button to our users
+2. The user clicks this button
+3. The Paypal SDK triggers a `createOrder` function defined in our frontend. This sends a `/create-order` request to our backend API, including details like currency code and amount
+4. Our backend API calls the Paypal API and creates an Order
+5. If creating the order was successful, we return the payload we received from the Paypal API to the frontend
+6. On receiving the response to its `/create-order` request, the Paypal SDK then opens a Paypal-controlled window for the user to approve the payment
+7. Once the user approves the payment, the Paypal SDK triggers an `onApprove` function defined in our frondtend. This sends a request to the `/capture-payment` endpoint on our backend. 
+8. Our backend fires a request to the Paypal API looking to capture the payment
+9. If payment is captured successfully, we return the success response body from Paypal to the frontend
+10. On receiving the success response, the Paypal SDK closes the Paypal window, and returns control to our frontend, which should display a success message to the user.
+
+### Rails Payment Logic
+
+The above described how we interact with the Paypal API to facilitate a payment between a Merchant and a Payer. We still need to record the payment as having been made on our website, though. Currently, we are adapating our implementation to the existing payments logic, which works as follows:
+1. `paid_entry_fees` is defined in the `Registration` model as the sum of the `RegistrationPayments` associated which `belong_to` the `Registration`
+2. Among other things, a `RegistrationPayment` stores the details of the payment (amount, currency code), and it has a polymorphic association to other objects on `:receipt`
+3. During Step 5 above, we create a `PaypalTransaction` object which represents which represents a "product" we are giving the Payer the opportuntiy to pay for.
+4. Upon successful capture of a payment in Step 8 above, we create `PaypalCapture` object, which `belongs_to` `PaypalTransaction` in a `has_many` relationship.
+5. We then call the `record_payment` function of the Registration, and pass in the amount paid and the `:receipt` object (`PaypalTransaction` in this case). This will create a `RegistrationPayment` object associated to the `Registration`, completing our backend payments workflow.

knowledge_base/competition_form.md

@@ -0,0 +1,27 @@
+---
+title: Competition Form
+parent: Knowledge Base
+layout: default
+---
+
+The competition form has 2 components:
+1. React frontend
+2. Rails backend
+
+To create a competition, the frontend sends a POST request to `/competitions`, which is handled by the `create` method in `competitions_controller.rb`. This is one of the default routes created by `resources :competitions` in `routes.rb`, which is why it is not explicitly defined in that file.
+
+## Adding a Field to the Competition Form
+
+1. If necessary, create and run a migration to add it to the Competition model
+    1. Add the field(s) to cloneable/uncloneable attributes
+    2. Add the field(s) to the dev database dumper
+    3. Add any validations needed for these fields - strongly recommended to add tests against these validations as well
+2. Make the fields available in the competition form by field names to:
+    1. `competition.rb#to_form_data`
+    1. `competition.rb#form_data_json_schema`
+    2. `competition.rb#form_errors`
+    3. `competition.rb#form_data_to_attributes`
+3. Add the fields to the competition form by:
+    1. Locating the relevant component in `app/webpacker/components/CompetitionForm/FormSections`
+    2. Create fields by analzying and copying/editing the existing fields
+    3. Ensure that the necessary keys are created in en.yml (viewing the competition form where your fields have been added will tell you which keys are missing - these can take a while to update)

knowledge_base/wca_data_overview.md

@@ -39,7 +39,7 @@ The "developer database export" confusingly enough, is **also** publicly accessi
 
 ### Are you investigating bugs in the developer export?
 
-See [lib/database_dumper.rb](https://github.com/thewca/worldcubeassociation.org/blob/master/WcaOnRails/lib/database_dumper.rb) and the [relevant test](https://github.com/thewca/worldcubeassociation.org/blob/master/WcaOnRails/spec/lib/database_dumper_spec.rb) and the [corresponding rake file](https://github.com/thewca/worldcubeassociation.org/blob/master/WcaOnRails/lib/tasks/db.rake).
+See [lib/database_dumper.rb](https://github.com/thewca/worldcubeassociation.org/blob/main/lib/database_dumper.rb) and the [relevant test](https://github.com/thewca/worldcubeassociation.org/blob/master/WcaOnRails/spec/lib/database_dumper_spec.rb) and the [corresponding rake file](https://github.com/thewca/worldcubeassociation.org/blob/master/WcaOnRails/lib/tasks/db.rake).
 
 There are two commands to deal with the developer database export: