| **** BEGIN LOGGING AT Mon Oct 4 12:21:28 2004 | ||
| -->You are now talking on #schooltool | 12:21 | |
| <--hazmat has quit (Connection timed out) | 12:30 | |
| -->hazmat (~hazmat@c-24-15-10-12.client.comcast.net) has joined #schooltool | 12:47 | |
| <--gregweb has quit ("User pushed the X - because it's Xtra, baby") | 12:53 | |
| -->gregweb (~gregweb@18.241.203.62.cust.bluewin.ch) has joined #schooltool | 13:03 | |
| <--hazmat has quit (Connection timed out) | 13:17 | |
| -->hazmat (~hazmat@c-24-15-10-12.client.comcast.net) has joined #schooltool | 13:41 | |
| -->alga (~alga@office.pov.lt) has joined #SchoolTool | 14:02 | |
| -->gintas (~gintautas@office.pov.lt) has joined #schooltool | 14:04 | |
| -->Voff_ (~Voff@33.192.181.62.in-addr.dgcsystems.net) has joined #schooltool | 14:38 | |
| <--hazmat has quit (Connection timed out) | 15:06 | |
| -->hazmat (~hazmat@c-24-15-10-12.client.comcast.net) has joined #schooltool | 15:11 | |
| <--gintas has quit (Read error: 110 (Connection timed out)) | 15:15 | |
| -->pips_ (~chatzilla@18.241.203.62.cust.bluewin.ch) has joined #schooltool | 15:16 | |
| -->gregweb_ (~gregweb@18.241.203.62.cust.bluewin.ch) has joined #schooltool | 15:33 | |
| <--hazmat has quit (Connection timed out) | 15:35 | |
| -->hazmat (~hazmat@c-24-15-10-12.client.comcast.net) has joined #schooltool | 15:42 | |
| gregweb_ | somebody there? | 15:50 |
|---|---|---|
| gregweb_ | Marius? | 15:50 |
| mgedmin | yes? | 15:51 |
| gregweb_ | Hi Marius? | 15:51 |
| gregweb_ | s/?/!/ | 15:51 |
| mgedmin | hi gregweb_ ;) | 15:52 |
| alga | Hi Gregoire | 15:52 |
| gregweb_ | Q: In the Web UI there are Super-groups, Subgroups, Members and Supervisors. ... | 15:52 |
| gregweb_ | Hi Albertas. | 15:52 |
| alga | supergroups are parent groups | 15:53 |
| gregweb_ | What's the relation between the Supervisors there and the supervisors in the database? | 15:53 |
| gregweb_ | SUpergroups, and subgroups are clear | 15:53 |
| gregweb_ | The questions was badly written, sorry ... | 15:54 |
| alga | supervisors are teachers in the school version | 15:54 |
| alga | somebody who is interested in the group timetable | 15:54 |
| alga | like a manager of a group | 15:54 |
| gregweb_ | Are the supervisors, managers and members a hardcoded? | 15:55 |
| alga | hm | 15:55 |
| alga | a manager is like a permission, a security status | 15:55 |
| alga | membership and teaching are relationships | 15:56 |
| gregweb_ | ok | 15:56 |
| gregweb_ | what is supervisor? | 15:56 |
| gregweb_ | teaching relationship? | 15:56 |
| alga | yes | 15:56 |
| alga | somebody who is at the teacher end of a teaching relationship | 15:57 |
| gregweb_ | are member, supervisor, manager kind of roles? | 15:57 |
| alga | manager, yes | 15:57 |
| mgedmin | manager is a security role | 15:57 |
| gregweb_ | are there other roles? | 15:58 |
| mgedmin | (any user that belongs to the managers group is a manager and has additional privileges) | 15:58 |
| mgedmin | supervisor (aka teacher) is also a security role (users that belong to the teachers group are teachers aka supervisors) | 15:58 |
| gregweb_ | ok | 15:58 |
| mgedmin | supervisor and member are also relationship roles | 15:58 |
| gregweb_ | so there are security roles and relationship role? | 15:59 |
| mgedmin | yes | 15:59 |
| mgedmin | usually when we say "role" we mean relationship role | 15:59 |
| gregweb_ | What the "relation" between the supervisor relationship role and the supervisor security role? | 16:00 |
| mgedmin | same name ;) | 16:00 |
| mgedmin | one says that this user is a supervisor of this group | 16:00 |
| mgedmin | it is mostly informative IIRC | 16:00 |
| mgedmin | I think it is also used to define the school's timetable | 16:01 |
| mgedmin | another says that this user is a supervisor in general | 16:01 |
| mgedmin | and that implies extra privileges (the ability to edit timetables, etc) | 16:01 |
| gregweb_ | The ability for a security role is defined implicit (hardcoded, code or config), I assume? | 16:02 |
| mgedmin | yes, it is hardcoded in the code | 16:03 |
| gregweb_ | What if i like to have a new Secretary role? | 16:04 |
| gregweb_ | as security role. | 16:04 |
| <--hazmat has quit (Connection timed out) | 16:05 | |
| mgedmin | change the code | 16:07 |
| mgedmin | or use ACLs | 16:07 |
| mgedmin | create a group Secretaries | 16:07 |
| gregweb_ | Or shall I define a Secretaries group and some secretaries and then give the secretaries some rights via ACL in a group e.g. Beamers. | 16:07 |
| gregweb_ | You were faster in typeing :-) | 16:07 |
| mgedmin | and grant the appropriate permissions for this group in the ACLs of the appropriate objects | 16:08 |
| mgedmin | ;) | 16:08 |
| gregweb_ | Sorry, there are no resource groups ... | 16:09 |
| gregweb_ | Are ACL to extend the hardcoded security roles? | 16:09 |
| -->hazmat (~hazmat@c-24-15-10-12.client.comcast.net) has joined #schooltool | 16:10 | |
| gregweb_ | grant the appropriate: I understood. | 16:10 |
| <--tvon has quit ("Leaving") | 16:12 | |
| mgedmin | yes: initially we only had a hardcoded security model | 16:12 |
| mgedmin | then we extended it with ACLs | 16:12 |
| <--tvon|x31 has quit (Remote closed the connection) | 16:12 | |
| mgedmin | (which do not cover all parts of the system yet) | 16:12 |
| gregweb_ | ok. | 16:13 |
| gregweb_ | Thanks for your answers, we'll contue to figure out more of schooltool/bell... | 16:14 |
| gregweb_ | stay tuned, hehehe :-) | 16:14 |
| <--pips_ has quit (Read error: 232 (Connection reset by peer)) | 16:42 | |
| <--Voff_ (~Voff@33.192.181.62.in-addr.dgcsystems.net) has left #schooltool | 16:52 | |
| -->pips_ (~chatzilla@18.241.203.62.cust.bluewin.ch) has joined #schooltool | 17:06 | |
| <--hazmat has quit (Connection timed out) | 17:15 | |
| -->hazmat (~hazmat@c-24-15-10-12.client.comcast.net) has joined #schooltool | 17:17 | |
| th1a | We may want to remove the whole "supervisor" thing from SchoolBell's interface, since it is confusing and unnecessary. | 17:21 |
| -->gintas (~gintautas@office.pov.lt) has joined #schooltool | 17:23 | |
| pips_ | hi tom | 17:39 |
| pips_ | indeed it was confusing! :-) | 17:39 |
| th1a | Yeah, there generally isn't really an equivalent role to teacher in groups that aren't classes. | 17:40 |
| gregweb_ | Hi Tom, I'm Gregoire. | 17:41 |
| gregweb_ | I'm working with pips_ | 17:41 |
| th1a | Hi Gregoire. | 17:41 |
| th1a | Is SchoolTool starting to make sense otherwise? | 17:42 |
| pips_ | hmmm | 17:42 |
| th1a | We badly need some developer documentation soon. | 17:44 |
| pips_ | tom: will you be available on irc tomorrow? | 17:44 |
| pips_ | if so, will you log on around this time of the day? | 17:44 |
| gregweb_ | My feeling is: There is much infrastructure (structure) under the hood. But it is *very* hard to discover hab to map the existing structure to the own structures (how it is done here in Switzerland). | 17:44 |
| th1a | Yeah. I'll be here around this time. | 17:45 |
| pips_ | that's great | 17:45 |
| th1a | I have to try to get up earlier now that work has resumed in Europe :-) | 17:45 |
| pips_ | unfortunately I have to go right now... but i will be working with greg all day tomorrow on schooltool | 17:46 |
| pips_ | bye | 17:46 |
| th1a | Bye. | 17:47 |
| <--pips_ has quit ("Chatzilla 0.9.64f [Mozilla rv:1.7/20040707]") | 17:47 | |
| gregweb_ | I'll have to leave also. See you tomorrow. I'll working on the requirements tomorrow morning. | 17:48 |
| th1a | OK. Talk to you tomorrow. | 17:48 |
| gregweb_ | th1a:I assume you'll be interested in such o document. | 17:48 |
| gregweb_ | bye | 17:48 |
| th1a | Certainly. | 17:48 |
| gregweb_ | k | 17:49 |
| gregweb_ | We now know a little about SchoolTool but the details we didn't uncover yet. On the other side you don't have yet an idea of our requirements. I hope with some paper from our side it gets easier to map the requirements. | 17:51 |
| th1a | OK. I hope that our underlying architecture is flexible enough to meet your needs. | 17:52 |
| gregweb_ | the relational approach surely, I suppose | 17:54 |
| gregweb_ | For the rest I'm not yet deep enough in the concept. | 17:54 |
| gregweb_ | So let's see. Bye (definitely). | 17:55 |
| th1a | Bye! | 17:55 |
| <--gregweb_ (~gregweb@18.241.203.62.cust.bluewin.ch) has left #schooltool | 17:56 | |
| th1a | alga gintas mgedmin : when do you want to chat about acceptance tests, etc? | 18:00 |
| mgedmin | yes | 18:02 |
| mgedmin | but we'll have to leave in about 30 minutes | 18:03 |
| th1a | OK. | 18:03 |
| *mgedmin did not notice that you started your question with "when" :-) | 18:03 | |
| mgedmin | ideally I'd like to see a list of verifiable acceptance criteria for each story | 18:03 |
| mgedmin | so that we could go through that checklist and be sure we didn't forget anything | 18:04 |
| mgedmin | e.g. for the "default group" story: | 18:04 |
| mgedmin | - when you add a new user in the html interface, the form should have a drop-down with all group names (and a special "do not add to any group" choice) | 18:05 |
| mgedmin | - when you add a new user in the wxClient interface, it should have a drop down with all lists as well | 18:06 |
| mgedmin | (if you omit this item, then we'll know that wxClient does not have to have this feature) | 18:06 |
| th1a | OK. So not an automated test, but a checklist for humans. | 18:06 |
| mgedmin | yes | 18:07 |
| gintas | automated tests would be too much trouble for a pretty much one-off procedure | 18:07 |
| mgedmin | an automated test would be nice in theory, but I think that can wait | 18:07 |
| th1a | OK. | 18:08 |
| th1a | I'll work on those for the next milestone today. | 18:08 |
| alga | one more thing that bothers me is that it's us who phrase the stories, so your requirements may not even be mentioned there | 18:09 |
| mgedmin | one question about the schoolbell translation story | 18:10 |
| th1a | Right. Well, I'll become more assertive as I get more of a feel for this process. | 18:10 |
| mgedmin | afaiu you want schoolbell to be just a single translation file that changes all the strings shown to the user | 18:11 |
| mgedmin | right? | 18:11 |
| th1a | This has been a kinda weird way to start because I have little feel personally for calendaring. I have much more defined opinions about things more specifically connected to school work. | 18:11 |
| th1a | mgedmin: If we can manage it, that seems like a good way to do it. | 18:12 |
| mgedmin | currently the language is determined from the current locale | 18:12 |
| mgedmin | when there is no translation file for the current locale, then we fall back to internal strings | 18:12 |
| mgedmin | this means that if we provide a SchoolBell translation as a translation file for English, but the servers's locale is French, then schooltool will use internal strings instead of the english translation file | 18:13 |
| mgedmin | this can be fixed by the sysadmin setting the "correct" locale for the schooltool process | 18:13 |
| th1a | Can that be overridden at the application level? | 18:13 |
| mgedmin | or we could add an option in schooltool.conf that overrides language autoselection from locale | 18:13 |
| th1a | Yeah. | 18:13 |
| th1a | I certainly wouldn't want to have to change the server's locale. | 18:14 |
| mgedmin | or we could add a different option that specifies the fallback language when the autodetected language does not exist | 18:14 |
| mgedmin | or both ;) | 18:14 |
| mgedmin | actually, I think the gettext module accepts a list of languages to try | 18:15 |
| mgedmin | so we could have just one option that takes a list of languages | 18:15 |
| mgedmin | another question about the same story | 18:15 |
| mgedmin | if schooltool and schoolbell only differ in translation files | 18:16 |
| mgedmin | perhaps it makes sense to add an option to schooltool.conf that specifies the directory where translation files are kept | 18:16 |
| mgedmin | then we could have both schooltool translations and schoolbell translations for several languages, and keep them in the source repository | 18:16 |
| mgedmin | and switching between SchoolTool and SchoolBell would mean just a change in the configuration file without the need to remove old translation files and move the new translation files over | 18:17 |
| th1a | That sounds good. | 18:17 |
| mgedmin | what about README, the names of executable scripts (schooltool.py vs schoolbell.py), etc.? | 18:17 |
| mgedmin | do we leave that for distributors? | 18:17 |
| mgedmin | that is, people who prepare SchoolTool or SchoolBell packages? | 18:18 |
| th1a | Yeah, I think that's probably ok. | 18:18 |
| mgedmin | ok -- the rest of the differences between schooltool and schoolbell are just in strings | 18:18 |
| alga | Could Brian do the tarball releases as well? | 18:18 |
| mgedmin | so the translation file approach will just work | 18:18 |
| mgedmin | we'll have to make the file name of the logo image a translatable string as well | 18:19 |
| mgedmin | so that schooltool and schoolbell can have different logos | 18:19 |
| th1a | This also helps define what does and doesn't go into the core and what is external. | 18:20 |
| th1a | If it doesn't make sense in SchoolBell, we should make it external. | 18:20 |
| alga | so, all the school problem domain stuff will be in add-ons? | 18:21 |
| th1a | It's a thought. | 18:21 |
| mgedmin | I'd be happy to see actual add-ons for SchoolTool | 18:21 |
| th1a | We really need to write down how it would be done. | 18:22 |
| mgedmin | it would help us see whether the APIs are good for extending SchoolTool | 18:22 |
| mgedmin | we have a lot of abstractions that we have never used | 18:22 |
| mgedmin | I'm now wondering about one of them | 18:22 |
| th1a | I was wondering yesterday if we could tack it onto this milestone somehow. | 18:22 |
| th1a | It needs to be done soon. | 18:23 |
| th1a | I have applications I'd like to write for my school. | 18:23 |
| mgedmin | Teachers are not necessary for SchoolBell (even if we rename them to supervisors), right? | 18:23 |
| th1a | As far as I can tell they aren't. | 18:23 |
| mgedmin | otoh it might be nontrivial to rip them out from the core | 18:24 |
| mgedmin | the built-in security model knows about teachers | 18:24 |
| mgedmin | the whole-school timetable view knows about teachers | 18:25 |
| *mgedmin thinks | 18:25 | |
| alga | that would be a great case for showing how problem-domain plugins should work | 18:28 |
| th1a | I wouldn't want to spend too much time doing a reorganization that doesn't add features, but it seems like it would be useful. | 18:35 |
| mgedmin | right | 18:36 |
| *mgedmin has to go now | 18:36 | |
| mgedmin | we can continue this tomorrow, or later this evening | 18:37 |
| th1a | OK. I'll work on acceptance tests. Yeah. We'll keep discussing it. | 18:37 |
| ---Disconnected (). | 18:38 | |
| **** ENDING LOGGING AT Mon Oct 4 18:38:42 2004 | ||
| **** BEGIN LOGGING AT Mon Oct 4 20:39:48 2004 | ||
| -->You are now talking on #schooltool | 20:39 | |
| *mgedmin is creating schooltool svn accounts for etria folks | 20:46 | |
| -->tvon (~tvon@h-68-166-69-51.mclnva23.dynamic.covad.net) has joined #schooltool | 21:02 | |
| -->Voff_ (~Voff@c-cc4571d5.22207-1-64736c11.cust.bredbandsbolaget.se) has joined #schooltool | 21:38 | |
| th1a | mgedmin: have you thought about having different acl's for browser and XML interfaces? | 21:41 |
| th1a | For example, we'll allow resources to be booked via the web but not iCal. | 21:42 |
| mgedmin | do you think there's a use case? | 21:43 |
| th1a | I'm just thinking about it because I finally have publishing from iCal working (with a few ugly workarounds), but it doesn't check for changes on the server the way Moz does. | 21:43 |
| mgedmin | I see your point | 21:44 |
| th1a | So once you publish from iCal (I'm talking about the app, btw) | 21:44 |
| th1a | any changes you make to the calendar via the web will just be obliterated. | 21:44 |
| mgedmin | in general I think that the user should be able to do the same things with REST that he can do with a browser | 21:44 |
| mgedmin | but publishing the whole calendar via iCal is different from editing individual events via the browser | 21:45 |
| mgedmin | so in this special cae | 21:45 |
| th1a | Yeah. | 21:45 |
| mgedmin | so in this special case separate ACLs make sense | 21:45 |
| mgedmin | but in general I think browser and REST code should use the same ACLs | 21:45 |
| th1a | 90% of the time, yes. | 21:45 |
| th1a | But I don't think we'll be able to allow people to schedule resources by uploading an iCal file because we won't be able to report clashes, as far as I know. | 21:46 |
| mgedmin | alga asks me to tell you that we propose a story for iCal, Evolution and KOrganizer support | 21:46 |
| mgedmin | (working around any quirks these clients may have) | 21:46 |
| th1a | Practically speaking, that's probably very important in terms of adoption. | 21:47 |
| th1a | considering it would only be used internally in special circumstances, would it be hard to have different acl's for browser and REST? | 21:49 |
| mgedmin | no, it would not be very difficult | 21:49 |
| *mgedmin thinks | 21:49 | |
| mgedmin | it could also be different permissions | 21:50 |
| mgedmin | permission to view, edit, add, download iCalendar, upload iCalendar | 21:50 |
| mgedmin | but maybe not | 21:50 |
| mgedmin | currently the iCal RESTive views are smart enough to figure out from the uploaded calendar | 21:51 |
| mgedmin | which events are modified, which ones are deleted, which ones are added | 21:51 |
| mgedmin | and it applies different permissions to different changes | 21:51 |
| th1a | Hm. | 21:52 |
| th1a | I guess it isn't really a question of REST vs. browser, because in this case you want to accept changes published from an iCal file but not the browser or XML over REST. Only iCal over REST. | 21:55 |
| th1a | So yeah, adding download iCalendar and upload iCalendar permissions probably makes sense. | 21:56 |
| mgedmin | you do not think that it it useful to let people only add events via uploading iCal files? | 22:02 |
| <--tvon has quit ("Leaving") | 22:03 | |
| th1a | My only point is that if you use Apple iCal to "publish" a calendar using iCalendar, then if we want to support Apple iCal users, we should lock that calendar so it can only be edited by uploading an iCalendar file. | 22:04 |
| th1a | Otherwise users will be confused when the changes they make through the web disappear. | 22:05 |
| mgedmin | iCal does that? | 22:06 |
| mgedmin | I mean, upload calendars without checking whethey they have changed on the server? | 22:07 |
| th1a | Precisely. Sorry if I didn't make that clear earlier. | 22:07 |
| mgedmin | eek | 22:07 |
| th1a | It gets confusing since the app has the same name as the format. | 22:07 |
| mgedmin | I think the full name of the format is iV | 22:08 |
| mgedmin | iCalendar | 22:08 |
| mgedmin | only everyone abbreviates it as iCal | 22:08 |
| th1a | Yeah. | 22:08 |
| mgedmin | ok, it's getting late | 22:12 |
| th1a | Good night. | 22:13 |
| mgedmin | see you tomorrow | 22:13 |
| ---Disconnected (). | 22:13 | |
| **** ENDING LOGGING AT Mon Oct 4 22:13:27 2004 | ||
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!