| **** BEGIN LOGGING AT Tue Oct 5 11:40:53 2004 | ||
| -->You are now talking on #schooltool | 11:40 | |
| -->gintas (~gintautas@office.pov.lt) has joined #schooltool | 12:26 | |
| -->gregweb (~gregweb@93.250.77.83.cust.bluewin.ch) has joined #schooltool | 12:26 | |
| <--gintas has quit (Read error: 60 (Operation timed out)) | 13:01 | |
| mgedmin | SteveA: have you got a spare minute? | 13:03 |
|---|---|---|
| SteveA | hello | 13:04 |
| SteveA | I will have in a bit | 13:04 |
| mgedmin | ok | 13:05 |
| mgedmin | we're refactoring roles and relationship types in schooltool to be ordinary objects rather than interfaces extending ISpecificURI | 13:06 |
| mgedmin | and we stumbled upon a WHUI: role/relationship type hierarchy | 13:06 |
| mgedmin | I'm now wondering whether that hierarchy is necessary | 13:07 |
| mgedmin | since the ISpecificURI design originally came from you | 13:07 |
| mgedmin | I want to ask whether you have any use cases for specializing existing roles/relationship types | 13:08 |
| SteveA | flat *is* better than nested | 13:39 |
| mgedmin | so, no use cases then | 13:43 |
| mgedmin | good | 13:43 |
| SteveA | I have not been using schooltool personally or on any projects | 13:51 |
| SteveA | so, I think you and tom know about most of the use-cases there are | 13:51 |
| mgedmin | back when ISpecificURIs were designed no one had been using schooltool, and all use cases were fictional | 14:10 |
| mgedmin | I was wondering whether you had any ideas about a feature like this being necessary for extensibility or whatnot | 14:11 |
| mgedmin | I just want to rip out a feature that was never used and that would make the code simpler if removed | 14:11 |
| SteveA | it may come in handy when you want to customize a third-party add-on | 14:11 |
| SteveA | that defines relationship types | 14:12 |
| SteveA | but, moving to zope3 with zcml might provide good hooks too, in the overriding of zcml | 14:12 |
| SteveA | who knows? | 14:12 |
| SteveA | but, anyway, whui is whui | 14:12 |
| mgedmin | ok | 14:21 |
| mgedmin | adding hierarchy is not that difficulyt | 14:21 |
| mgedmin | the only question was whether to do that now, or postpone it until we actually need it | 14:21 |
| mgedmin | I postponed it | 14:21 |
| -->gintas (~gintautas@office.pov.lt) has joined #schooltool | 14:27 | |
| -->thisfred (~thisfred@a213-84-57-72.adsl.xs4all.nl) has joined #schooltool | 15:06 | |
| <--Voff_ has quit (Remote closed the connection) | 15:06 | |
| -->Voff_ (~Voff@33.192.181.62.in-addr.dgcsystems.net) has joined #schooltool | 15:14 | |
| -->gregweb_ (~gregweb@73.123.203.62.cust.bluewin.ch) has joined #schooltool | 15:42 | |
| <--gregweb has quit (Read error: 110 (Connection timed out)) | 15:51 | |
| <--Voff_ has quit () | 15:52 | |
| -->th1a (~hoffman@pool-64-223-50-152.prov.east.verizon.net) has joined #schooltool | 16:20 | |
| th1a | Good morning folks. | 16:22 |
| <--gintas has quit (Read error: 54 (Connection reset by peer)) | 16:22 | |
| -->gintas (~gintautas@office.pov.lt) has joined #schooltool | 16:23 | |
| -->pips (~chatzilla@73.123.203.62.cust.bluewin.ch) has joined #schooltool | 16:29 | |
| ---sabdfl is now known as bradb_ | 16:39 | |
| mgedmin | good afternoon ;) | 16:50 |
| mgedmin | be back in ~3 hours | 16:50 |
| ---Disconnected (). | 16:50 | |
| **** ENDING LOGGING AT Tue Oct 5 16:50:51 2004 | ||
| **** BEGIN LOGGING AT Tue Oct 5 20:19:55 2004 | ||
| -->You are now talking on #schooltool | 20:19 | |
| th1a | alga & mgedmin: I need some feedback on acceptance tests. | 20:22 |
| mgedmin | ok | 20:22 |
| th1a | Here's what I put for default groups: | 20:22 |
| th1a | The HTML forms for application object creation will include checklists of relevant groups. All new objects will be transparently (via REST or browser) added to groups that correspond to their type (e.g., resources will be added to the resource group). | 20:22 |
| mgedmin | checklists? | 20:26 |
| mgedmin | do you mean a bunch of check boxes? | 20:27 |
| mgedmin | or did you mean a drop-down list? | 20:27 |
| th1a | Check boxes. | 20:27 |
| th1a | Sorry. | 20:27 |
| mgedmin | how do we know which groups are relevant? | 20:28 |
| th1a | Since there will pretty commonly be multiple groups. | 20:28 |
| th1a | Well... that's a good question. | 20:28 |
| mgedmin | or do you mean that there will be checkboxes for all groups, and relevant groups will be those that the user checks? | 20:28 |
| th1a | Ideally when a person is added the user won't be presented a list of groups like "projectors" and "classrooms." | 20:29 |
| mgedmin | yes | 20:30 |
| mgedmin | actually we originally imagined a group tree with persons as group members | 20:30 |
| mgedmin | we did not think that creating groups for resources would be common | 20:30 |
| mgedmin | now we do have a special 'locations' group that contains all resources which are classroom, halls etc. | 20:31 |
| mgedmin | it is used only to provide a drop-down list for locations in calendar events | 20:31 |
| th1a | Yeah. We probably need to have more specially defined groups. | 20:33 |
| mgedmin | we have facets | 20:34 |
| mgedmin | e.g. we have a TeacherGroup facet | 20:34 |
| mgedmin | when you put this facet on a group | 20:34 |
| mgedmin | then all persons added to this group become teachers | 20:35 |
| mgedmin | that is, get a teacher facet added to their data | 20:35 |
| th1a | Is that how locations work, too? | 20:35 |
| mgedmin | well, no | 20:35 |
| th1a | That's just a group. | 20:35 |
| mgedmin | it's a group with a special name | 20:35 |
| mgedmin | actually, the teachers group is also a group with a special name | 20:36 |
| mgedmin | when we authorize operations to users | 20:36 |
| mgedmin | if we want to see whether a user has teacher privileges | 20:36 |
| mgedmin | we check if he is a member of /groups/teachers | 20:37 |
| mgedmin | facets are primarily for storing additional information | 20:37 |
| *mgedmin is thinking | 20:38 | |
| mgedmin | I'm not sure if it would be a good idea to say "this person is a teacher iff there's a teacher facet added to the person" | 20:40 |
| mgedmin | I think people can manage their own facets, so it would be a security problem | 20:41 |
| th1a | Perhaps when groups are created the user should define what types and groups can be members of the groups. | 20:41 |
| alga | no they don't! | 20:42 |
| alga | at least they shouldn't | 20:42 |
| <--bskahan has quit (Read error: 104 (Connection reset by peer)) | 20:42 | |
| th1a | Why not? | 20:42 |
| alga | a student shouldn't be able to activate or deactivate his student info facet | 20:43 |
| alga | if he's a student, he must have this facet | 20:43 |
| th1a | Oh, don't manage their own facets. | 20:43 |
| mgedmin | I think alga was refering to my statement, not yours | 20:43 |
| alga | and the system should enforce that | 20:43 |
| th1a | I agree with alga. | 20:43 |
| th1a | You can't manage your own facets. | 20:43 |
| -->bskahan (~bskahan@dsl093-119-225.blt1.dsl.speakeasy.net) has joined #schooltool | 20:43 | |
| alga | right, sorry for confusion | 20:43 |
| mgedmin | yes, I was mistaken\ | 20:45 |
| alga | well, conceptually facets are a system thing | 20:45 |
| alga | and those special facets on groups are the canonical way to add them to objects | 20:46 |
| alga | th1a: we only have 3 kinds of objects currenly | 20:47 |
| mgedmin | I've an idea | 20:47 |
| alga | but perhaps it is a good idea to limit membership to only objects having some special facet | 20:47 |
| mgedmin | we may have two trees: a tree of person groups, and a tree of resource groups | 20:48 |
| alga | say, we want a group that only teachers can be members of. | 20:48 |
| mgedmin | I do not think that we ever want a single group to contain both persons and resources | 20:48 |
| alga | I agree | 20:48 |
| th1a | That's probably the case, but it would be helpful to enforce limits on which groups could be added to a given group. | 20:50 |
| th1a | You might have a group which you intend to only include teachers. | 20:50 |
| bskahan | and a way to associate a group of resources with a group of people | 20:50 |
| th1a | Preventing the user from accidentally adding a student to that group would be helpful. | 20:50 |
| mgedmin | there are different kinds of relationships | 20:51 |
| mgedmin | currently you can write a plugin for schooltool, register a new relationship kind | 20:51 |
| mgedmin | and then say that resource "Room 101" is a venue of "Group 3c" | 20:51 |
| mgedmin | now we have two kinds of relationships that come out of the box: membership and teaching (you can associate a group with a teacher for that group) | 20:52 |
| mgedmin | I'd like to go back to the start of this discussion | 20:54 |
| mgedmin | <th1a> The HTML forms for application object creation will include checklists of relevant groups. All new objects will be transparently (via REST or browser) added to groups that correspond to their type (e.g., resources will be added to the resource group). | 20:54 |
| mgedmin | Why do we need a resource group? | 20:54 |
| mgedmin | We have a container (/resources) that is sort of like a group | 20:54 |
| th1a | It is a little redundant. | 20:54 |
| mgedmin | only you cannot add arbitrary things to it | 20:54 |
| th1a | But we need some default group for navigational purposes. | 20:54 |
| mgedmin | and you cannot remove things from it without also removing them from the whole system | 20:55 |
| mgedmin | we will give access to /resources in the web interface | 20:55 |
| mgedmin | I think the UI can be made to be very similair to the UI of a group | 20:55 |
| th1a | If you have a better idea for default groups, I'm game. | 20:55 |
| mgedmin | my idea is to simply implement the story that we already have -- provide nice UI for /groups, /persons, and /resources | 20:56 |
| mgedmin | they are already very like groups, and they contain all objects of the appropriate kind | 20:56 |
| th1a | So not worry about a default group but offer checkboxes of groups to add the object to when you create it. | 20:56 |
| mgedmin | ok | 20:57 |
| th1a | ok. | 20:57 |
| th1a | Otherwise is the form of the acceptance test what you had in mind? | 20:58 |
| mgedmin | more or less, yes | 20:58 |
| th1a | What do you need more of? | 20:58 |
| mgedmin | removing the appropriate default group clause ;) | 20:59 |
| th1a | Right. | 20:59 |
| mgedmin | and either removing the "relevant groups" part or defining what groups are relevant | 20:59 |
| th1a | OK. | 20:59 |
| mgedmin | I suppose we could add a new story for adding group types, and once we have them only display certain groups in the add form | 20:59 |
| mgedmin | or we could only show groups that are connected to the group tree | 21:00 |
| th1a | It seems like a good excercise. Clarified some issues. | 21:00 |
| mgedmin | (the "locations" group which contains resources is not connected to the tree) | 21:00 |
| mgedmin | also, I'm now wondering how many groups there can be | 21:00 |
| th1a | I think all the groups should be attached to the tree. It is extremely confusing to not be able to browse to a group. | 21:01 |
| mgedmin | if there can be hundreds of them, then maybe multi-selection list is better than hundreds of checkboxes | 21:01 |
| mgedmin | from a purely UI perspective | 21:01 |
| th1a | Yeah. | 21:01 |
| th1a | I do think that defining the members which groups can be added to a group is a good idea. | 21:02 |
| th1a | That cuts down the list of relevant groups very well. | 21:02 |
| th1a | And prevents mistakes. | 21:02 |
| mgedmin | that sounds like a new story | 21:02 |
| th1a | Sure. | 21:02 |
| mgedmin | and it is not very clear to me | 21:03 |
| mgedmin | currently we often determine what a person is by looking at which groups he belongs to | 21:03 |
| th1a | It is a little hard to word... | 21:03 |
| mgedmin | those extra facets (teacher facet, student facet) are a side efect of belonging to a certain group | 21:03 |
| mgedmin | when you add a person to a group, he gets an extra information facet | 21:04 |
| mgedmin | when you remove a person from a group, the extra info facet is deactivated | 21:04 |
| th1a | So I would be able to create a group "discipline team" and designate that only members of the teacher group could be part of the discipline team. | 21:04 |
| mgedmin | yes | 21:05 |
| th1a | Or I could make a group "remedial reading" that could only include members of my 3rd period class. | 21:05 |
| mgedmin | I think the simplest way to do that now would be to write a plugin | 21:05 |
| mgedmin | listen on "member added" events and veto them when the member does not match some criteria | 21:05 |
| mgedmin | at least that's what we thought events could be used for | 21:05 |
| th1a | I'll write the story. | 21:05 |
| *mgedmin is talking about internal program events, not calendar events | 21:05 | |
| th1a | Right. | 21:05 |
| mgedmin | if we want to enable users to set such limitations on group membership | 21:06 |
| th1a | Have you thought more about the idea of moving the teacher role into a plugin? | 21:06 |
| mgedmin | a bit, yes | 21:06 |
| th1a | I think it is important to do those group membership limitations. | 21:06 |
| th1a | Makes the UI easier in the long run. | 21:07 |
| mgedmin | if we want to enable users to set such limitations on group membership, without writing extra code, then we need to think about some UI to describe the criteria | 21:07 |
| th1a | You know which groups a person can be added to and vice versa. | 21:07 |
| mgedmin | or perhaps you need to think about some UI ;-) | 21:07 |
| th1a | I think you'd just select which groups' members could be added from a list of all the groups. | 21:09 |
| mgedmin | ok | 21:11 |
| th1a | Do you think moving the teacher role to a plugin is worth doing? | 21:20 |
| mgedmin | yes, but I'm not sure it's worth doing right now | 21:23 |
| th1a | OK. | 21:23 |
| mgedmin | but maybe it is -- schoolbell does not need teachers | 21:23 |
| mgedmin | I guess I'll dwell upon it a bit more | 21:23 |
| th1a | I would like to have a well documented example plugin soon regardless. | 21:24 |
| -->pips (~chatzilla@235.209.203.62.cust.bluewin.ch) has joined #schooltool | 21:42 | |
| ---pips is now known as pips_away | 21:43 | |
| th1a | Perhaps it makes more sense to just say that the membership of a group is limited to members of its immediate parent. | 21:55 |
| alga | hmm | 21:55 |
| th1a | That doesn't seem quite right... | 21:57 |
| th1a | Well, the interface is probably more complicated that I was giving it credit for. | 21:59 |
| th1a | Maybe it needs to be more of an interactive tree. | 21:59 |
| th1a | Ug. I'm confusing myself. | 22:00 |
| alga | well, see you tomorrow | 22:01 |
| th1a | OK. I'll work this out. | 22:01 |
| alga | I'm finished with the schoolbell translation, btw | 22:01 |
| th1a | Excellent. | 22:01 |
| alga | just add "domain schoolbell" to schooltool.conf | 22:01 |
| th1a | You guys aren't planning on starting repeating events tomorrow, are you? | 22:01 |
| alga | I've already started reading/making sense of the iCalendar spec | 22:02 |
| alga | It would be good to figure out what we want done and how it should look | 22:02 |
| alga | well, tomorrow | 22:03 |
| <--alga has quit ("leaving") | 22:03 | |
| mgedmin | see you | 22:04 |
| ---Disconnected (). | 22:04 | |
| **** ENDING LOGGING AT Tue Oct 5 22:04:45 2004 | ||
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!