Create a Guests plugin which is basically a subset of the Bands plugin

[RobRuana]

This may be better implemented by refactoring the Bands plugin.

Requirements

• Here is a link to the current google form for guests

• create the unique guest/events link when we create the group & indicate it's a Guest group

• show only guests filter/check-box

• can we have a "Guest Agreement" section/function? we upload a word doc or paste in text, they have a place to sign

• Indicate if parking is included

• Guest panel specific info:

  • needs "collaborative panel" stuffs
  • needs moderator field
  • needs preferred timeslots
  • needs "special info" field
  • need to have guests able to "save and add another panel" option, up to 3 max
  • need to have a Tech Requirements section on the "add a panel" form, needs input from TechOps to verify that we're covering what THEY need to know

• uber needs to make the block when the guest panels are approved (title, descriptions, length, group)

• don't allow overlap between panelists

• can we a "remaining hours available" counter displayed on the schedule for filling-in purposes? can calculate [(length of all blocks)+30 minutes*(# of blocks) for used time], take it out of total available panel room time

• new Email category: Guest/Events Completed schedule. Include each panel & details from the schedule for the guest/events groups (title, description, length, room, date, time); MUST be approved before sending.

• button on the group to send Group schedule - shows on group page only if schedule is marked Final (?)

Non-guest uber requests

• can we get a "merge attendee" function? should allow you to pick which one to keep, refund badge fee, etc
• can we get a button to resend emails for registration, finalized schedule?

[kitsuta]

+11111 for refactoring the bands plugin

[kitsuta]

OK, thinking about how to do this, we can refactor the bands plugin into a "special group" plugin. It has the following workflow:

1. An admin creates a group and marks it with a Special Type (right now, just Band or Guest) OR uses the plugin to make the group directly.
2. There's a checklist for the group to fill out that gets sent (and re-sent, and re-sent again...) to their leader. This is the trickiest bit, because the checklist will have different steps per group type... we'll I guess need a ChecklistStep object that understands what type(s) of group it shows up for.
3. Honestly that's kind of it

The other component of this can I think be done with a modification to the Panels plugin -- a way for a guest to 'apply' for a panel that gets automatically approved. I don't know very much about the panels plugin but it seems like that may be the key difference between the guest workflow and the panelist workflow for one's panels.

[thaeli]

+allthethings for generalizing the Bands plugin and adding some links to the Panels plugin.

…

On Thu, Sep 7, 2017 at 4:56 AM, Victoria Earl ***@***.***> wrote: OK, thinking about how to do this, we can refactor the bands plugin into a "special group" plugin. It has the following workflow: 1. An admin creates a group and marks it with a Special Type (right now, just Band or Guest) OR uses the plugin to make the group directly. 2. There's a checklist for the group to fill out that gets sent (and re-sent, and re-sent again...) to their leader. This is the trickiest bit, because the checklist will have different steps per group type... we'll I guess need a ChecklistStep object that understands what type(s) of group it shows up for. 3. Honestly that's kind of it The other component of this can I think be done with a modification to the Panels plugin -- a way for a guest to 'apply' for a panel that gets automatically approved. I don't know very much about the panels plugin but it seems like that may be the key difference between the guest workflow and the panelist workflow for one's panels. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2489 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXeehndP1kthKWKwwcBNKO-20DNwWXeks5sf6-xgaJpZM4Nhs8z> .

[kitsuta]

This is largely complete. For the guest-facing side, most of all what we need right now is to hammer out the specific wording desired (for things like the guest agreement page) and have the guest department test it and make sure they're happy with the workflow.

After that is going to be addressing the event-creation-related items. I don't really have a clear idea of how the Panels department currently schedules panels, but when I was investigating the plugin, it seemed to be a fairly manual process -- I don't even see a way to put an existing, approved panel on the schedule with the title + description automatically linked. If this really isn't possible, that'll definitely be the 'lowest-hanging fruit' as far as what we can do to make everyone's lives easier.

As for the item "don't allow overlap between panelists," the schedule currently highlights events in red and allows you to view how a panelist is double-booked. I expect this level of flexibility is even better than outright denying the ability to double-book a panelist, since it would let admins move around events without 'getting in their way'.

We'll also want to discuss the emails in further detail, since they should be straightforward to implement and it's all about the specifics of what conditions they should send under, who they should be sent to, and what wording they'll have.