| *** bska|mobile has joined #schooltool | 00:14 | |
| *** bskahan has quit IRC | 00:17 | |
| *** Aiste has quit IRC | 00:24 | |
| *** bska|mobile has quit IRC | 00:44 | |
| *** Aiste has joined #schooltool | 13:04 | |
| *** ignas has joined #schooltool | 13:14 | |
| *** ignas has quit IRC | 13:35 | |
| *** SteveA_ has quit IRC | 13:38 | |
| *** ignas has joined #schooltool | 13:55 | |
| *** SteveA has joined #schooltool | 14:01 | |
| *** bskahan has joined #schooltool | 14:08 | |
| *** Aiste has quit IRC | 14:19 | |
| *** ignas has quit IRC | 14:37 | |
| *** Aiste has joined #schooltool | 14:40 | |
| *** Aiste_ has joined #schooltool | 15:19 | |
| *** Aiste has quit IRC | 15:38 | |
| bskahan | is there any benefit to exposing last modifying principal and last modified time in the UI? | 15:48 |
|---|---|---|
| bskahan | I'm leaning towards exposing it for events in group calendars and exposing it for persons,groups, resources, and events if the principal is manger | 15:49 |
| bskahan | I'd say exposing it generally might be good, except that the username is ugly | 15:49 |
| bskahan | sb.person.bskahan | 15:49 |
| * bskahan assumes everyone checks IRC logs | 15:50 | |
| *** Aiste_ has quit IRC | 15:51 | |
| *** Aiste has joined #schooltool | 16:07 | |
| *** ignas has joined #schooltool | 16:11 | |
| *** SteveA_ has joined #schooltool | 16:30 | |
| *** SteveA has quit IRC | 16:41 | |
| *** gintas has joined #schooltool | 17:04 | |
| *** SteveA_ has quit IRC | 17:37 | |
| *** SteveA has joined #schooltool | 18:15 | |
| Velmont | bskahan: What about making it depend on a variable? So that one can choose if one want to see it. (If that is doable :] ) | 19:10 |
| bskahan | Velmont: that's doable | 19:17 |
| bskahan | I'd rather avoid a preference option if possible though | 19:17 |
| bskahan | rather put it in the places where people need it by default | 19:17 |
| bskahan | th1a: will a section ever be a section of multiple courses? | 20:10 |
| th1a | Yes. | 20:10 |
| bskahan | ok | 20:11 |
| bskahan | thanks | 20:11 |
| th1a | I mean, it isn't a huge burden to allow it, is it? | 20:11 |
| bskahan | no, not at all | 20:11 |
| th1a | One of the primary advantages of using our directed graph model is that it is easy to allow multiples of all this kind of stuff. | 20:12 |
| * bskahan nods | 20:12 | |
| th1a | Whereas in your database tables, it is a pain. | 20:12 |
| bskahan | if it was a use case that would never happen then a course could be a container of sections rather than a group of sections | 20:12 |
| bskahan | neither is easier and making it a group of sections is more flexible | 20:12 |
| th1a | This is the kind of edge case we want to allow. | 20:13 |
| bskahan | ok | 20:13 |
| th1a | Non-traditional schools are a target audience. | 20:13 |
| bskahan | there won't be UI for doing at this point... | 20:14 |
| bskahan | well | 20:14 |
| bskahan | that's not true | 20:14 |
| *** mgedmin has joined #schooltool | 20:14 | |
| th1a | It isn't a big deal UI wise at this point. | 20:15 |
| *** gintas has quit IRC | 20:18 | |
| bskahan | Sections can be subclasses of Group, they get stored in the GroupContainer | 20:24 |
| bskahan | all participants in the section, meaning teachers and students, get membership in the Section | 20:25 |
| bskahan | then I'll add new SectionInstruction and SectionParticipant relationships to seperate out the teachers from the students | 20:26 |
| bskahan | adding a user to the SectionInstruction relationship with SectionInstructor Role would a "Teacher" annotation to the person | 20:27 |
| bskahan | and the opposite for "Student" | 20:27 |
| bskahan | that's an RFC, if anyone was wondering who I'm talking to ;) | 20:28 |
| bskahan | UI wise, this poses only one problem, if someone uses the generic membership forms to add a person to a group as member | 20:30 |
| *** tvon has joined #schooltool | 20:30 | |
| FarcePest | membership relationship is seperate from teacher/student relationship? | 20:30 |
| bskahan | membership is generic | 20:30 |
| bskahan | the alternate way is to just make everyone a member and use annotations only to decide who is a teacher and who is a student | 20:31 |
| th1a | bskahan: catching up... | 20:31 |
| bskahan | that sounds better | 20:31 |
| bskahan | th1a: you can skip it, writing it out made me realize it was crack | 20:31 |
| FarcePest | heh | 20:31 |
| th1a | Make sure and give me a chance to think about the terminology -- or at least be prepared to change it. | 20:32 |
| bskahan | you can change it, I was just trying to decide how I would know who was in charge | 20:33 |
| th1a | Actually, I'm going to go get lunch and hit some baseballs, and then I'll really, truly, for real work on the glossary for few hours. | 20:33 |
| * bskahan cheers | 20:33 | |
| bskahan | I won't have to commit my """Course TODO: add description from glossary""" docstrings | 20:33 |
| * tvon thinks relationships is better than annotations | 20:36 | |
| tvon | easier to get the info (as opposed to looping through all members of the group), and what would the annotation hold? | 20:37 |
| bskahan | *sigh* | 20:39 |
| tvon | heh | 20:39 |
| bskahan | tvon: you may be right, once I started writing, I realized that the teacher would have to have a teacher annotation for each class | 20:40 |
| tvon | You'd still need a relationship for each class though, wouldn't you? | 20:40 |
| bskahan | the annotations could be a dict though | 20:40 |
| tvon | true | 20:40 |
| tvon | relationships seem more fitting though | 20:40 |
| bskahan | its alot more code | 20:41 |
| bskahan | I'm not sure if there are any real world benefits to one way over the other | 20:41 |
| tvon | it seems to me to be a fairly exact example of what relationships are for | 20:42 |
| tvon | and wouldn't it be a lot easier to go between the two if they were linked with relationships instead of the info being stored just in a dict on the teacher? | 20:43 |
| bskahan | using 3 types of relationships doesn't fix the issue of people being added as members | 20:43 |
| bskahan | know what I mean? | 20:44 |
| tvon | no | 20:44 |
| bskahan | the section will show up in the Group forms, so you could add someone to the section | 20:45 |
| bskahan | as a member, but without setting their student/teacher status | 20:45 |
| tvon | Do they have to use the exact same form? | 20:46 |
| tvon | (as normal groups) | 20:46 |
| bskahan | there will be a different for specifically for Sections | 20:46 |
| bskahan | but i believe they will show up in the generic group form | 20:47 |
| tvon | because of the zcml? | 20:47 |
| bskahan | because of the way that group form works | 20:48 |
| bskahan | but, UI asside, I need a way to prevent people from being added as members directly | 20:48 |
| tvon | won't that have to change anyways? | 20:48 |
| bskahan | sure | 20:49 |
| bskahan | a slightly related question, should we create a direct relationship between student and a teacher if the teacher teaches the student? | 20:53 |
| *** joanna has joined #schooltool | 20:53 | |
| tvon | mhm... maybe, unless it's reliable to go from student->class->teacher of class | 20:54 |
| tvon | probably should | 20:54 |
| bskahan | we can always trace relationships through sections to find all the students teachers, or the other way | 20:54 |
| * bskahan agrees | 20:54 | |
| tvon | sections are like individual classes, right? | 20:55 |
| bskahan | section = "the algabra class that meets at 11am" | 20:55 |
| *** joanna has quit IRC | 20:55 | |
| tvon | course == "Earth Science" and section == ... yeah | 20:55 |
| tvon | k | 20:55 |
| tvon | then yeah, I don't think the direct relationship is needed | 20:56 |
| bskahan | sections are defined by (teacher, time, course) iirc | 20:56 |
| bskahan | you don't think the direct relationship is needed? | 20:56 |
| bskahan | I guess finding the student's teachers is less common than finding the students sections | 20:57 |
| tvon | if each section is going to have members with student and teacher relationships, then I think a direct relationship is redundant | 20:57 |
| bskahan | ok | 20:57 |
| bskahan | I think that't the way it goes then | 20:57 |
| tvon | cool | 20:58 |
| tvon | damn, see Joe Hildebrand's thing on AOL and jabber? | 20:59 |
| tvon | erm.. not as exciting as I thought.. nm | 21:00 |
| mgedmin | th1a, when do you arrive to oxford? | 21:23 |
| bskahan | mgedmin: is there any way to constrain membership in a group? | 21:30 |
| mgedmin | yes | 21:32 |
| mgedmin | you can write an event subscriber that raises exceptions | 21:32 |
| bskahan | thanks | 21:33 |
| bskahan | I hadn't thought of that | 21:33 |
| mgedmin | see enforceMembershipConstraints in schoolbell.app.membership | 21:33 |
| *** tvon has quit IRC | 21:42 | |
| *** tvon has joined #schooltool | 21:52 | |
| *** bskahan has quit IRC | 21:59 | |
| *** bskahan has joined #schooltool | 22:01 | |
| bskahan | http://tool-man.org/examples/dragging.html | 22:07 |
| bskahan | that would be cool for DayView | 22:07 |
| *** ignas has quit IRC | 22:08 | |
| *** mgedmin has quit IRC | 22:30 | |
| *** tvon has quit IRC | 22:34 | |
| *** Aiste has quit IRC | 22:35 | |
| *** bskahan has quit IRC | 22:42 | |
| *** SteveA has quit IRC | 22:50 | |
| *** SteveA has joined #schooltool | 22:51 | |
| *** SteveA has quit IRC | 23:00 | |
| *** SteveA has joined #schooltool | 23:07 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!