Model Structure Changes

[carlosdp]

The Events structure works exactly as we need it to, we just need to nest it under the Schedule component so that we can group events effectively.

This is the structure I am thinking of:

MODEL: Schedule -belongs_to :owner, :polymorphic: true -has_many :events

Event -belongs_to :schedule (no longer User, relation through Schedule) -has_many :event_attendees (as is)

This is the simplest part of this milestone.

[achivetta]

So, what exactly is a schedule? And why do we need them?

[carlosdp]

A Schedule is the controlling container for events. It can belong to Users and Groups/Shows and contains the conflict-checking procedures.

[achivetta]

Is it an actual database table?

Can a group or user have more than one schedule?

[carlosdp]

It is its own model, yes. In the current design, each entity only has one Schedule. I know what you are getting at, but keeping this system separate of any entity is the easiest way to go about this. There are several ways to do it without this model, but considering that at the User level, for example, you have to check User created events and also the events being attended for conflicts, the extra table is warranted in the stead of a few longer steps in the chain.

[achivetta]

Can an event in a user's schedule have event_attendees?

[carlosdp]

Yes, though I do not see a case in which people will use that right now, that could change. The events in a User's schedule should be conflicts such as classes or recitals that would conflict with a show/project.

[carlosdp]

Changing this design. After discussing what we are actually going to work on this summer, this kind of separation between the systems is no longer justified.

Instead, we'll move the event logic to a "Shared" module (this could actually be potentially made into a gem...) and keep the current structure with minor changes if necessary in terms of adding more information and poly relations.

The only current change is:

MODEL:

Event belongs_to :owner, :polymorphic: true

[achivetta]

I like that approach a lot better.

I was also going to ask: does it make sense to reuse Event for storing conflict data, or is a FreeBusy type approach better? I'm not sure how much baggage Event brings for managing attendees.

After discussing what we are actually going to work on this summer

Which is? :)

[carlosdp]

I think that using Events seems the right way to go. The intention with this is that an SM, for example, should be able to schedule rehearsals far in advance and then be notified if an actor adds an event to their schedule which conflicts with one of them and allow them to change either the time or the attendees. With this model, they just put in everything they are doing or even potentially import an iCal. FreeBusy might require too much thought and actors won't put every conflict as it comes up.

As for what we are actually working on, the document I put out earlier was just everything I could come up with in the hopes people would come up with similar ideas or new ones by seeing what is possible. In the end though, we didn't get that kind of response so we are approaching people individually. Doci and I choose a few things that were paramount mostly because they solve problems that came up multiple times this year such as scheduling, load-in/strike planning, pubcookie auth, something to help with design collaboration (not sure what), and something like a wiki (have to consult more with the TC and such). Inventory/resource management is important too, but it's not really a new thing, just a change in how we think of checkouts and a bit of a UI revamp.

[achivetta]

FreeBusy might require too much thought and actors won't put every conflict as it comes up.

I guess my point was exactly the opposite. I have enough trouble keeping my own calendar up-to-date. You expect me to also enter my calendar on Scotch? I'd just import my iCal, but some things are there are private ("Appt at Abortion Clinic") and others aren't really conflicts. A free-busy interface (think doodle) has the potential to be much faster to fill out.

As for what we are actually working on

Right, so I guess my question was: where should I be looking to stay up-to-date on what you actually are going to try to do this summer? Both from the perspective of my own interest and helping out.

pubcookie auth

We intentionally decided not to do this before. But, as far as I understand it, it shouldn't be pubcookie anymore but rather Shibboleth. (Thankfully, as Pubcookie was always a pain to setup.) But, we decided not to use any Andrew auth because alumni should still be able to login. (How would Alex DiClaudio login? or Katie Humbert this past semester?) If the new system will act as e.g. an OpenID provider, great, otherwise...

Also, has this actually been a problem for anyone? There have been problems with people's credentials, but that's just a problem with our migration from SOTW 1.0 passwords.

[docimou]

where should I be looking to stay up-to-date on what you actually are going to try to do this summer?

I think that ScotchNet doc should be good for now? I mean, we're adding things as we discuss them. Also we'll working on and constantly updating the issues, I presume.

we decided not to use any Andrew auth because alumni should still be able to login.

I think that's a good point. We want alumni to be able to still log in, especially if we ever plan on implementing something specifically for them (to, like, stay updated... and stuff.)

Also can we never do facebook integration? I mean, I guess we will if there's really good reason, but...

[carlosdp]

Maybe I wasn't clearly presenting the concept, but an SM doesn't see the actor's individual schedules, they only see that they are unavailable at that time. (Essentially, they see a FreeBusy view) However, I would not model it near Doodle since I for one am never actually truthful when I use Doodle, I always choose the times I want to do a thing, not necessarily all the times I am free.

Putting in classes and practices recurring thoughout the semester shouldn't be a challenge (letting people define recurrence thoughout semester, year, and minis) and actors are already required to give their conflicts to the SM, this just lets them do it in a standardized way and takes the grunt work from the SM.

Yea, Shibboleth is what they have moved to for the most part, but they still use pubcookie for a few things and still support it. I'd never set one up before so I didn't know which was easier. The reason I want to use this auth is that people are already using their andrew's and I feel like many of them use the same password as their andrew auth due to the fact that it basically implies it and I feel like we shouldn't really be storing that ourselves. It's also one less password to remember and we wouldn't run into the few times where people lose their password.

That is something like why I wanted to make a separate "view" of the site like alumni.snstheatre.org where alumni see a different overview of SnS operations instead of seeing the same old view they have always seen. Alumni should have a special status on the site, and this also enables us to give them lifetime access outside of the normal auth system.

Andrew auth just helps us lock down the site more, which is something we desperately need to do. Right now, a new user sees just as much as a veteran SnSite (SnSian?). Members who have been active in shows need to feel that they are part of something in order to retain more members and opening new doors on the site as they become more involved is one way we can help with that.

But lest, if it becomes to much of a hassle for the worth, we can just stay with the same auth and lock it down just fine. It's an improvement, not a necessity. However, no matter what, I really want to get rid of the whirlpool encryption. That thing is just going to get annoying as the web team membership shifts over time.

[achivetta]

On May 24, 2012, at 8:25 PM, Carlos Diaz-Padron reply@reply.github.com wrote:

It's also one less password to remember and we wouldn't run into the few times where people lose their password.

There's an "email me my password" feature and I've only heard of it not working once.

That is something like why I wanted to make a separate "view" of the site like alumni.snstheatre.org where alumni see a different overview of SnS operations instead of seeing the same old view they have always seen. Alumni should have a special status on the site, and this also enables us to give them lifetime access outside of the normal auth system.

There are non-active alumni and then there are people like Katie this past year who are still actively participating in shows. This doesn't solve Katie's case and that's where requiring an active andrew account would be a problem.

Andrew auth just helps us lock down the site more, which is something we desperately need to do.

Really? Has this actually been a problem?

But lest, if it becomes to much of a hassle for the worth, we can just stay with the same auth and lock it down just fine. It's an improvement, not a necessity.

My recommendation would be to optionally allow users to login with Shibboleth, but don't require it.

However, no matter what, I really want to get rid of the whirlpool encryption. That thing is just going to get annoying as the web team membership shifts over time.

You'll be potentially locking out a lot of people if you do that. It's better than if we had done it a year ago, but still not a great situation.