Waitlist: Subevent-Picker, Subevent starttime

[pc-coholic]

This adds the starting time to the list of a subevent to the list of waitlist entries as well as the rich/select2 subevent-picker.

The top one in the "send as many vouchers out as possible" seems to be integrating quite nicely, the one just above the waitlistentries however refuses to play nicely, especially when the product/itempicker has very, very long entries. I tried to replicate the filterbar-behaviour of the order overview, but with no success...

Perhaps someone else wants to take a swing at the layout options here?

Ref: Z#2372969

[codecov]

Codecov Report

Merging #2009 (c084b91) into master (53070f5) will decrease coverage by 0.04%.
The diff coverage is n/a.

❗ Current head c084b91 differs from pull request most recent head 2f8e6a2. Consider uploading reports for the commit 2f8e6a2 to get more accurate results

@@            Coverage Diff             @@
##           master    #2009      +/-   ##
==========================================
- Coverage   79.30%   79.25%   -0.05%     
==========================================
  Files         333      333              
  Lines       41579    41636      +57     
==========================================
+ Hits        32974    33000      +26     
- Misses       8605     8636      +31     

Impacted Files	Coverage Δ
src/pretix/base/exporters/orderlist.py	43.69% <0.00%> (-1.43%)	⬇️
src/pretix/base/notifications.py	87.27% <0.00%> (-0.49%)	⬇️
src/pretix/base/models/orders.py	90.35% <0.00%> (+0.09%)	⬆️

[wiffbi]

I added some col-classes around the filter-elements similar to the order overview page. Is that what you were after? Sadly the col-classes for bootstrap are very rigid so with large screens it gets very large whereas even with the col-lg-* classes it can get very narrow. Probably css-flexbox would be a better option here regarding space usage, but currently it’s not available in the styles and I do not want to add it just for this. Maybe later at some redesign?

[wiffbi]

P.S.: I think the auto-submit that happens on the filter dropdown of subevents is not ideal. But the auto-submit on the sending-vouchers form actually a bit frightening. I know, it does not do much harm, but still, as a user I do not expect neither of those dropdowns to auto-submit.

[pc-coholic]

P.S.: I think the auto-submit that happens on the filter dropdown of subevents is not ideal. But the auto-submit on the sending-vouchers form actually a bit frightening. I know, it does not do much harm, but still, as a user I do not expect neither of those dropdowns to auto-submit.

You are quite right - I did not think about this...

Which makes me wonder: Should we just scrap this change for now and just manually add {{ e.subevent.date_from|date:"TIME_FORMAT" }} to the two original pickers? @raphaelm?

[raphaelm]

Which makes me wonder: Should we just scrap this change for now and just manually add {{ e.subevent.date_from|date:"TIME_FORMAT" }} to the two original pickers? @raphaelm?

Well, generally I think all subevent pickers should be select2, so I'd be in favor of fixing this properly.

Why does the auto-submit happen, can we maybe just get rid of that? It's maybe something we build for some filter form somewhere without a button? For filter forms it's sometimes quite useful, but it shouldn't happen in any other forms obviously. We also have other select2 components (e.g. creating a voucher manually) where it doesn't happen.

[wiffbi]

Auto-submit happens due to a CSS-class .simple-subevent-choice on the select. I made auto-submit optional by removing this class from the select and only attaching it, when requested by adding a context var to the include like so (or having a truthy var auto_submit in the current context):

{% include "pretixcontrol/event/fragment_subevent_choice_simple.html" with auto_submit=True %}

P.S.: And also updated all occurrences where that fragment_subevent_choice_simple was included and needed that auto-submit.

[raphaelm]

This looks done, can you rebase against master to check if that fixes the test? :)