Multiple orders per user per event

[harrislapiroff]

I am still able to edit the attendee on a pass after it has been refunded.

Also, I'd prefer that refunded passes don't continue to show up on new orders.

[melinath]

I think it's important to keep a full record of a user's transaction history. However, there very well might be a more intuitive way to organize the shopping UI.

[harrislapiroff]

Also it still doesn't make any sense to edit a refunded pass and it's confusing to get presented with both passes as an option for editing when checking out. I'm picturing this scenario:

I order a pass, realize, for whatever reason, that something is wrong with the pass. I contact the organizers and they kindly refund the pass and instruct me to go back to the store and purchase the correct one. I add the correct pass to my cart, press "Next step >" and am presented with two passes that I need to assign attendees to. ????

[melinath]

Um, no. You shouldn't need to assign the refunded pass. But it should still show up on the summary of your transactions for the event.

[harrislapiroff]

@melinath Can we come up with a solution to this? I'd like to propose the following:

We restructure the Order model behavior like so:

An order is only "open" until payment is completed. Once payment is completed, that order is "closed" and items cannot be added to it or removed from it. The organizer can still refund items and the attendee can still edit their data (though we should talk more deeply about this at a later date; it's hard as an organizer to make sure your printouts, etc. have the most up-to-date records if the data keeps changing).

If a user wishes to purchase more items, a new blank order gets created. There can be multiple orders per user per event. From their own management page, the user can browse the items they have purchased, but they can also browse their "Orders" as separate receipts for each transaction.

[harrislapiroff]

And also, refunded orders should not display editing forms and icons in that browsing mode.

[nmorduch]

Mm that sounds nice.

[melinath]

I'd be down with more transactional orders slash multiple orders per event. We would then also need to have a checkout view before the summary view.

[melinath]

I think we can probably just allow multiple orders per user per event, and create a new order if all their order are already checked out. I.e. I think we can implement this with changes to business logic only rather than to code / database, which is good.

[melinath]

This will actually require a database change, potentially. Right now, the Order model is used both for recording payments and also as the go-to place to find whether a person has registered for an event. I.e. the order code is the person's information for the event. It's intended to be an option for how people go about picking up their registration packets (as opposed to by name). That doesn't work if there's multiple orders. So we need a sub-model of some kind. I'd suggest either Cart or Receipt. Thoughts?

[nmorduch]

I think it's actually a little weird to have one order code that can go for multiple people. What if you have an attendee code instead, to mark you as having registered?

[melinath]

That is also a thing we could do, but it would be a separate ticket. This ticket is about having multiple "rounds" of purchasing rather than lumping all the purchase / refund data into one bucket.

[melinath]

Though the order code is also nice because it gives anonymous users a link to their order info.

[nmorduch]

I wrote a whole thing and then I think I realized that basically rather than having Orders and Carts, I think you should have Accounts and Orders. And you can have an "account" even if you're an anonymous registrant.

[melinath]

So Account would essentially be what Order is now?

[nmorduch]

I'm not sure I understand what Order is well enough to answer that. But probably? Except the Account should also be the same as like literal accounts as we already have.

[melinath]

@nmorduch It sounds like you're saying that Account would be what people use to log in. Is that accurate? Or just similar to that?

[nmorduch]

Yeah. But right now they're pretty closely tied anyway, so I don't know that it would cause problems to give some of the Order's function to Account

[melinath]

@nmorduch It might help if I explain the function of the involved models.

Person is our user model. It handles authentication and site-global data storage. Event is, of course, the model that handles data related to events. Order is (currently) an accounting of the relationship between an Event and a Person. So it holds the registration information for that person for that event. Some of this is global to the event (such as who the person is, if there is a person attached) and some of this is partitioned off into other models (Attendees, Payments, Refunds, etc.)

The issue then is that every time you check out, it would be useful to keep a record of what happened with that checkout so that the user can go back and look at that individually. So we still need a model to encapsulate the relationship between a user and an Event (which is what Order does right now) but we also need a separate model to keep track of what was bought when and why.

Hmm... here's a thought. Maybe we could just add an M2M field from Transaction to BoughtItem? If transactions were self-aware about what items were related to them, it would give more information to event organizers and it would allow for receipt-style display of items.

[nmorduch]

I guess I think that the relationship between a user and an Event should be determined by attendees?

But your last solution sounds sensible and not-terribly-inelegant.

[melinath]

Isn't this resolved now? The self-aware transactions landed. If there are specific other issues, I think they should be split into other tickets.

[nmorduch]

I think you're probably right.

[harrislapiroff]

Is this resolved? The primary reason I wanted multiple orders is because I didn't want to see items from previous orders while I was in the process of ordering something new because that's confusing. Maybe that's a separate issue, but it definitely has not been fixed.

[harrislapiroff]

And also to be able to access each order as a separate receipt, basically.

[nmorduch]

Then we probably want issues for those things.

[harrislapiroff]

I guess I'm confused because I thought that's what this ticket was and it doesn't seem resolved to me.

[nmorduch]

Specifically:

• Differentiate in UI btw prev and current orders
• Provide user w/ list of orders they have made

[harrislapiroff]

see comment earlier in the thread: https://github.com/littleweaver/django-brambling/issues/260#issuecomment-67785983

[harrislapiroff]

I'll create separate tickets, but unless people really disagree with me, I'd like to see those issues be given some attention, because I thought that was what was getting resolved here.

[nmorduch]

I think that this was just too big an issue after we discussed it a lot. So part of it got fixed and part of it didn't. Separate issues, now that we have capability to address them, will be helpful.

[melinath]

@harrislapiroff Those got lost because the discussion spiraled off that topic. I agree they're important. That's why they need separate tickets.

[nmorduch]

But yes, we'll give them attention :heart:

[harrislapiroff]

Sorry I'm being grumpy about this. Those features were the exclusive reason I created this ticket, so it's irritating and surprising to me that they got lost in the shuffle. But I know I'm being unreasonable and I can see why that happened.

[nmorduch]

I'm going to make an issue specifically about the summary page, because I think that was part of what I wanted to do with it before and forgot.