RFC: Policy for Changing Event Registrations and Orders

[losolio]

1. Introduction

This RFC document outlines the policy for changing event registrations within the event management system. It encompasses modifications, cancellations, and refunds related to event registrations.

2. Overview

The EventInfo, Registration, and Order models are involved in defining and managing the event registration. The following sections describe the policies related to various actions, considering different statuses and types of the event, registration, and order.

3. Registration Changes Policy

3.1 Edit / cancellation of registration

• Before Last Cancellation Date: Participants may cancel their registration and edit all products.
• After Last Cancellation Date: Cancellations will set the registrationStatus to Cancelled, but no refunds will be issued.

Allowed customization hours

We will add a new variable AllowedRegistrationEditHours which sets the time the participant are allowed to edit his registration and products belonging to the registration. It should be counted from RegistrationTime. Even if the cancellation/modification are requested from the user after LastCancellationDate it will be allowed, but not if the event has started.

Admin policy

System admins and organization admins are allowed to refund orders at any time.

3.2 Refund Policy

If the participant is cancelling before the LastCancellationDate, all products should be set to 0. A refund is only needed if the order status is either 'Invoiced' or 'Paid'. I order is verified or draft, the automagic function could just remove the lines from the order.

Cancellations after the LastCancellationDate will not be eligible for a refund. - If a user attempts to cancel after the LastCancellationDate, they should be informed of the refund policy (frontend responsibility) and given an option to proceed with the cancellation without a refund or to contact support for further assistance.

4. Order Changes Policy

The order policy should be handled by the automagic function and ensure that the orders are edited according to this policy of the order status:

• Draft or Verified: Orders can be modified freely.
• Invoiced: Modifications will require a new order with negative quantity to remove products

5. Technical Implementation

• Utilize the properties of the EventInfo model such as LastRegistrationDate and LastCancellationDate to enforce deadlines.

6. Conclusion

This policy aims to provide a clear framework for managing changes to event registrations. It seeks to balance the flexibility required by participants with the need to maintain order and fiscal responsibility.

[losolio]

@yura-b @meinte - feel free to add comments and ask questions! It will be mainly backend work.

[losolio]

The user of the portal would like to see more flexibility with the not mandatory products, so that they could be added/removed until 2 week before the events starts.

In the future we might add more fields to products. possibly LastCancellationDate and LastRegistrationDate. Typically restaurant accepts extra persons attending until a few days before, but only allow cancellation 2 weeks before. So the default LastCancellation date if nothing is set, could be 14 days before the event starts. Also LastRegistrationDate could be 2 weeks before by default.

[meinte]

Question - are these new variables, such as lastregistrationdate, lastcancellation, etc - properties of a venue, or an organization? I can imagine every organization would be able to set these configurations on an organization level, as a default, with the possible addition of fine-tuning per event. I'm not sure what is more closely related to actual use cases right now.

[losolio]

Thanks for the comment @meinte , the properties are set on each event! I am not sure if they are exposed on the API for now..