Extend API to "get first N attendees who booked package X"

[RakanHowls]

Whenever we have some special item with limited availability (eg. the EF 28 - LED Badges), it is important to find out the first N attendees who booked a certain package.

Example: Towards the end of EF 28, we had less LED badges available than people who booked a super-sponsor package. The decision was made that the first N attendees who booked the package should get a reservation on the LED badge. This was basically turning the date-based reservation deadline into a count-based reservation threshold.

During EF 28, the only way to solve this was by repeatedly storing all supersponsors in a local file, and stopping when the threshold was reached. (status history was unavailable) This is bad for many reasons....

Simply checking the first N attendees with a package would not fit the requirement, since eg. reg number 1 could be the N+1-st upgrade.

Ideas for implementation:

• Additional search option on the /find API's "AttendeeSearchSingleCriterion" to directly get the first N attendees who booked package X
  (and / or)
• Additional field with a counter and / or date in the "package_list" entry of "AttendeeSearchResult" that specifies in which order / when the package was added.

[Jumpy-Squirrel]

As discussed in channel, this is complex for a number of reasons.

What if that attendee was cancelled in the meantime? Then reactivated? Do we want to go by booking timestamp or by payment timestamp? Especially in combination with the "allow multiple instances of a package" feature request, it amounts to adding a fully searchable history of package changes. And that is a lot of complexity.

So let me propose a different solution that may still give you what you want. We already have a historization of all changes of the due amount - the dues transactions in the payment service, which is the leading authority on dues and payments, being the source of our accounting. We can add an informational field to every dues transaction and record how it was calculated (which packages, how often, at which price, which additional booking amount). This would be exposed by the payment service API as an information only field.

See eurofurence/reg-payment-service#137