Admin ticketing

[bear454]

Allow admins to 'give' tickets to users, and create a class of tickets that can only be given by admins. This is a great way to handle providing material to sponsor staff.

[codecov]

Codecov Report

Merging #2306 into master will increase coverage by 0.04%.
The diff coverage is 95%.

@@            Coverage Diff             @@
##           master    #2306      +/-   ##
==========================================
+ Coverage   82.98%   83.03%   +0.04%     
==========================================
  Files         145      145              
  Lines        4790     4804      +14     
==========================================
+ Hits         3975     3989      +14     
  Misses        815      815

Impacted Files	Coverage Δ
app/models/ticket.rb	97.95% <100%> (+0.04%)	⬆️
app/models/ticket_purchase.rb	96.77% <100%> (ø)	⬆️
app/controllers/conferences_controller.rb	95.45% <100%> (ø)	⬆️
app/controllers/tickets_controller.rb	92.3% <100%> (+2.3%)	⬆️
app/controllers/admin/tickets_controller.rb	100% <100%> (+3.44%)	⬆️
...controllers/conference_registrations_controller.rb	91.07% <100%> (ø)	⬆️
app/models/ability.rb	96.47% <50%> (-1.15%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4e96f76...3607854. Read the comment docs.

[codecov]

Codecov Report

Merging #2306 into master will increase coverage by 0.04%.
The diff coverage is 95%.

@@            Coverage Diff             @@
##           master    #2306      +/-   ##
==========================================
+ Coverage   82.98%   83.03%   +0.04%     
==========================================
  Files         145      145              
  Lines        4790     4804      +14     
==========================================
+ Hits         3975     3989      +14     
  Misses        815      815

Impacted Files	Coverage Δ
app/models/ticket.rb	97.95% <100%> (+0.04%)	⬆️
app/models/ticket_purchase.rb	96.77% <100%> (ø)	⬆️
app/controllers/conferences_controller.rb	95.45% <100%> (ø)	⬆️
app/controllers/tickets_controller.rb	92.3% <100%> (+2.3%)	⬆️
app/controllers/admin/tickets_controller.rb	100% <100%> (+3.44%)	⬆️
...controllers/conference_registrations_controller.rb	91.07% <100%> (ø)	⬆️
app/models/ability.rb	96.47% <50%> (-1.15%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4e96f76...3607854. Read the comment docs.

[hennevogel]

I don't get it, why do we need a ticket class for this? I have my doubts in this workflow. Can you please describe it in more detail? TIA

[Ana06]

@bear454 can you please provide more details about this? 🙏

[bear454]

I don't know how to explain it much better, other than to rearrange the words a bit.

As an administrator, I should be able to give a ticket to a user.
As an administrator, I should be able to create tickets that general users cannot view or select.

[hennevogel]

As an administrator, I should be able to create tickets that general users cannot view or select.

Why? Why can't you just give them "normal" tickets?

[bear454]

At LFNW, we give tickets to sponsored staff, booth staff, and speakers, which allows for provide them different material at checkin; we also use the tickets in our badge design.

I'm sure you can understand that you wouldn't want the general public to be able to choose "speaker gift" ticket, for example.

[hennevogel]

So the ticket is different to distinguish people at checkin, okay. Do you use 'free' tickets too? I would rather do this with User roles so once you give people a staff role, their TicketPurchase takes this into account. Same for speakers probably.

[bear454]

Do you use 'free' tickets too?

No, we don't use 'free tickets' or 'registration tickets'.

[bear454]

I would rather do this with User roles so once you give people a staff role, their TicketPurchase takes this into account. Same for speakers probably.

I could see creating a dynamic role for speakers, but I don't have any way to tie users to sponsored staff; we don't use the 'booth' feature.

[bear454]

• Is there an objection to having an admin interface for 'giving' a ticket? We currently have admin interfaces for creating users, sponsors, registrations, but not tickets.
• Is there an objection to having tickets that aren't public? We have a non-public state for schedules, registration, all the splashpage components.

[hennevogel]

but I don't have any way to tie users to sponsored staff;

Well an admin can either 'give' them a 'special non visible' ticket, or they could assign them the role staff which would influence their ticket purchase (like discount 100%), their checkin process (like label the ticket) and anything else we could come up with in the future.

[hennevogel]

But if you need this as it is right now, we can merge it. It's just that we still run on sqlite in test and I can tell you where this will end up 😉

[sbernhard]

I really like the way this feature works. Sponsers or companies having a booth often gets free tickets.

[cycomachead]

I second this feature. This includes a solution for #2567. Hiding and showing tickets in general is useful, especially since we'll have early registrations and some temporary tickets.

The conference we are running this summer will likely also gift tickets as a result of sponsorships or for a few community members. The fact that this workflow is explicit is a bonus, to me. The clarity around tickets that are normally X being counted as 0 is helpful, too, from an audit and budget perspective.

[cycomachead]

This now needs to be updated, but that's pretty quick.

snap-cloud/snapcon@231b2a6

Merged this in my fork and it's working well!

[cycomachead]

After using this for a conference, the workflow works pretty well! But, this leads to a somewhat weird scenario when a user has an unpaid ticket. Sometimes we want to give a sponsored ticket to someone who started to go through the purchase process and when this happens it requires console access to first delete their ticket. I wonder if it makes sense to have a "replace" option, or if an unpaid ticket exists to just update it to paid with a value of $0.

[cycomachead]

I'm now a couple days out from running the 4th event where we've successfully used this. One thing I just realized is that the #give method in this PR doesn't trigger the follow to create a physical ticket, and send a confirmation email. Both those seemed like useful things as we had a couple people that were confused.

Simple fix: snap-cloud/snapcon@9ae89b5 (ignore accidentally removing the .visible filter in ticket_purchases)

I will say, aside from the few people who attempt to buy a ticket then we need to give them one, this has worked quite well for my uses. Here's all of them:

• I give all the conference admins registration tickets so they don't need to worry. (This is because in my fork I just check for registered? to a conference, though I support I could do registered? or admin role...) Still, in other events I've worked with the team still have tickets.
• I give volunteers tickets (same deal as above)
• We have people pay on behalf of others. So someone will be 10 non-reg tickets and give us the list of emails of people to buy tickets for.
• This makes it easy to give scholarship tickets. These are people who are often just attending, but requested a reduced ticket price.
• Hiding/Showing tickets is useful for "early bird" pricing and admin-only tickets.

I all these cases, I'm using registration tickets, since the common case is for someone to buy a reg ticket. It's quite nice that I and a couple others on our team can just drop in an email address to make sure someone is ready go.