| *** jelkner has joined #schooltool | 00:03 | |
| *** Aiste has quit IRC | 00:50 | |
| *** jinty has quit IRC | 01:02 | |
| *** kjcole has joined #schooltool | 03:47 | |
| *** kjcole has quit IRC | 03:51 | |
| *** Fujitsu has quit IRC | 04:33 | |
| *** Fujitsu has joined #schooltool | 04:39 | |
| *** Fujitsu has quit IRC | 04:55 | |
| *** Fujitsu has joined #schooltool | 04:57 | |
| *** Bhaskar has joined #schooltool | 05:07 | |
| *** Bhaskar has quit IRC | 05:51 | |
| *** Bhaskar has joined #schooltool | 06:06 | |
| *** shubacka has joined #schooltool | 09:01 | |
| Bhaskar | how can we make schooltool easier installation for ordinary people, can anyone suggest me? | 09:03 |
|---|---|---|
| Fujitsu | Your best bet is probably to wait until Schooltool is in a production-ready state, thus having a proper installation/packaging mechanism. | 09:07 |
| Bhaskar | well | 09:15 |
| *** Aiste has joined #schooltool | 10:41 | |
| *** lisppaste5 has quit IRC | 11:06 | |
| *** lisppaste5 has joined #schooltool | 11:10 | |
| *** thisfred has joined #schooltool | 11:56 | |
| *** ignas has joined #schooltool | 12:59 | |
| *** Bhaskar has quit IRC | 13:10 | |
| *** vidasp has joined #schooltool | 13:19 | |
| *** Fujitsu has quit IRC | 14:21 | |
| *** Fujitsu has joined #schooltool | 14:24 | |
| *** kitblake has left #schooltool | 14:44 | |
| *** jinty has joined #schooltool | 15:20 | |
| *** vidasp has quit IRC | 15:48 | |
| *** alga has joined #SchoolTool | 16:07 | |
| *** th1a_ is now known as th1a | 16:18 | |
| ignas | hi | 16:30 |
| th1a | hi ignas | 16:30 |
| ignas | congratulations ;) | 16:30 |
| th1a | Thanks. | 16:30 |
| th1a | No jfroche? | 16:32 |
| ignas | nope, can't see him | 16:32 |
| th1a | How'd the meeting go on Friday? | 16:32 |
| ignas | i don't really know | 16:33 |
| th1a | Did you talk to them on Skype? | 16:33 |
| ignas | all i know is that schooltool was not very prepared for a new person class at that moment | 16:33 |
| *** jfroche has joined #schooltool | 16:33 | |
| th1a | Aha. Hi jfroche. | 16:33 |
| ignas | and now it should work i think (i have commited/merged a lot of stuff on friday) | 16:33 |
| jfroche | hello there | 16:33 |
| th1a | I was just asking about how it went on Friday. | 16:34 |
| jfroche | sorry, have trouble with my hood | 16:34 |
| jfroche | th1a: went ok | 16:34 |
| ignas | th1a: so lyceum branch has an example of schoolbell person subclass being used as the person | 16:34 |
| jfroche | did you get info from them ? | 16:35 |
| th1a | As opposed to using demographics? | 16:35 |
| ignas | th1a: yes | 16:35 |
| ignas | th1a: you can still use demographics person, just that you'll have to inherit from demographics person then ... | 16:35 |
| ignas | or you can use facilities defined in demographics to create a person of your own | 16:35 |
| jfroche | ignas: do i have to hardcode my class in the factory or i have to create a new factory ? | 16:36 |
| ignas | new factory | 16:36 |
| ignas | and register it in overrides.zcml | 16:37 |
| jfroche | ok | 16:37 |
| ignas | so that it would overlay the old factory | 16:37 |
| ignas | no evolution though | 16:37 |
| ignas | so you sohuld start with a fresh database | 16:37 |
| jfroche | ok | 16:37 |
| jfroche | saw it's on trunk now | 16:37 |
| ignas | selecting person class is something that should be done when starting schooltool for the first time | 16:37 |
| ignas | yes it's on trunk | 16:38 |
| ignas | trunk still uses demographics by default i think | 16:38 |
| ignas | but functional tests for all modules are demographics free | 16:38 |
| th1a | ignas: selecting in ZCML? | 16:38 |
| ignas | th1a: yes, if all you want is to select demograhpics person or simple person | 16:38 |
| ignas | if you want a custom person you'll have to write some python code | 16:39 |
| th1a | OK. | 16:39 |
| th1a | So how'd it go overall jfroche? | 16:39 |
| jfroche | th1a: inherit from Person is something that we missed on friday | 16:39 |
| ignas | the only way they could try out their changes was in an unpluggable manner | 16:40 |
| ignas | changing the real person, and modifying the real authentication utility | 16:41 |
| jfroche | so we had a quick look at the existing z3 plug to ldap | 16:41 |
| jfroche | and i showed Ian to install schooltool on a Apple computer (from scratch) | 16:41 |
| jfroche | th1a: did you get news from him after the meeting ? | 16:42 |
| th1a | I don't think so, but I had a large pile of email, so I might have missed it. | 16:42 |
| jfroche | th1a: i gave a draft of the 2007 plan to Nicolas but i don't have news | 16:43 |
| jfroche | do you want the draft like that ? | 16:43 |
| jfroche | and try to ask him to push him ? | 16:43 |
| th1a | I'd like to take a look at it, sure. | 16:43 |
| ignas | jfroche: send a copy to me as well | 16:44 |
| jfroche | ok | 16:44 |
| th1a | How does the existing Z3 LDAP support look? | 16:46 |
| jfroche | it seems good but i don't see clearly how to plug it into schooltool yet | 16:46 |
| th1a | Did you get the feeling they'll have the technical chops to pull this off? | 16:47 |
| jfroche | i can do it quickly by inheriting from Person and changing authentication there but i feel like this is not the right place to code authentication | 16:47 |
| th1a | Right, but getting it working "incorrectly" is a good proof of concept. | 16:48 |
| ignas | jfroche: why not just override the authentication utility ? | 16:49 |
| jfroche | yep i think that's what we will do now that there is a nice way to inherit from Person | 16:49 |
| *** mgedmin has joined #schooltool | 16:49 | |
| jfroche | ignas: for the moment user password is in the Person | 16:50 |
| ignas | jfroche: just don't use it :) | 16:50 |
| jfroche | what should i do with things like setPassword ? | 16:50 |
| ignas | authentication code can do whatever it wants :) | 16:50 |
| ignas | remove them from the standard person interface | 16:50 |
| jfroche | then we don't need to inherit from Person anymore | 16:51 |
| ignas | make the password setting view specialize on the set password interface instead of IPerson | 16:51 |
| ignas | jfroche: if you don't want to have all those custom traversers defined for IPerson | 16:51 |
| ignas | then - yes | 16:51 |
| ignas | but i'd rather not | 16:51 |
| ignas | of course you might just write a new class | 16:52 |
| ignas | and make it implement IPerson | 16:52 |
| ignas | or what's left of it | 16:52 |
| jfroche | ok | 16:52 |
| ignas | and copy+paste the zcml class declaration | 16:52 |
| jfroche | merges will become nightmarres no ? | 16:53 |
| ignas | nah | 16:53 |
| ignas | not any more than usual | 16:53 |
| ignas | as long as you'll do it cleanly | 16:53 |
| ignas | first - refactor the person so that only things that are really essential are left in "IPerson" | 16:54 |
| ignas | then add a module for ldap integration | 16:54 |
| ignas | with it's own person | 16:54 |
| ignas | and test it live with a modified site.zcml, or in functional tests (with a separate layer) | 16:54 |
| jfroche | ignas: can i make it so that i just inherit from Person in a new ldap package, use this one and just don't write an empty method for setPasswords &co ? | 16:56 |
| th1a | Ultimately, would something like this be able to be set in schooltool.conf -- can conditional ZCML work off declarations in the conf file? | 16:56 |
| ignas | jfroche: well, you can do that, but i won't let you merge it to trunk :) | 16:56 |
| jfroche | ignas: :) | 16:57 |
| ignas | th1a: hmm, difficult to do, but possible, the problem is that Person specific functionality lives not in plain zcml but in overrides | 16:57 |
| ignas | th1a: so a setting would have to dispatch between some zcml files | 16:58 |
| ignas | should talk to jinty about that | 16:58 |
| ignas | as that affects deployment as well | 16:58 |
| th1a | Just to be clear here, it isn't jfroche's job to implement this, but I guess we do have some responsibility to provide them a clean path to implementing this. | 16:58 |
| th1a | Otherwise we'll just get something we can't use. | 16:58 |
| th1a | (by "this" I mean LDAP support) | 16:58 |
| ignas | th1a: either we work on making it easy to integrate, or we work on integrating it ourselves | 16:59 |
| jfroche | th1a: i got a mail from Ian saying: "Actual schooltool LDAP authentication implementation will be done at the | 16:59 |
| jfroche | PyCon sprint, provided the promised code changes in schooltool itself | 16:59 |
| jfroche | to ease replacing of that PersonFactory have been completed. | 16:59 |
| jfroche | " | 16:59 |
| ignas | th1a: i am not sure which one is easier | 16:59 |
| * jinty thinks | 16:59 | |
| ignas | seems like pycon is going to be fun :) | 16:59 |
| jfroche | th1a: no need for hotel, we won't sleep :) | 17:00 |
| th1a | I hope I haven't conned myself into paying them to have us do the work ;-) | 17:00 |
| th1a | It might be helpufl to define the use case for the sys admin who wants to use LDAP. | 17:01 |
| jfroche | th1a: if i understood it correctly, Jens won't be at Pycon | 17:01 |
| jfroche | but he will be available online | 17:02 |
| th1a | So according to what ignas said earlier, LDAP support or not will, at least for now, need to be set in the initial configuration of a SchoolTool instance. | 17:03 |
| ignas | yes | 17:03 |
| th1a | We're not even going to worry about changing on the fly (yet). | 17:03 |
| ignas | yes | 17:03 |
| th1a | In the future, whould we need more than some kind of auto-evolution script to make the changes dynamically? | 17:04 |
| th1a | I mean, it is not impossible forever? | 17:04 |
| ignas | th1a: it is possible, but very expensive | 17:05 |
| ignas | can't tell for sure without real usecases | 17:05 |
| th1a | Well, the use case basically is, "I've been using SchoolTool for 2 years, and now my school has an LDAP server I need to connect to." | 17:06 |
| th1a | Now, one thing to take into account is that the id's in the LDAP server might need to be mapped to the existing SchoolTool id's. | 17:06 |
| ignas | th1a: have you seen any systems that can do that ? | 17:07 |
| th1a | (note that I'm not saying we need to be able to do all this smoothly now, but I'd like to have a path to get there) | 17:07 |
| ignas | i mean - shutdown, change configuration, start up | 17:07 |
| ignas | and ta-da - you have ldap integration | 17:07 |
| th1a | Perhaps I have overly high expectations. | 17:07 |
| th1a | jfroche: How does it work in Zope2? | 17:08 |
| th1a | You replace the user folder, essentially, right? | 17:08 |
| jfroche | th1a: changing data storage on Person infos from zodb to ldap isn't that smooth | 17:08 |
| jfroche | th1a: yes but everything has to be in ldap and you have to do the mapping to some of the informations | 17:09 |
| mgedmin | if you replaced the user folder in zope 2, I'd expect you to also lose all the information about all the users in that folder | 17:09 |
| th1a | mgedmin: Yes, that makes sense. | 17:09 |
| th1a | OK, so lets only worry about the "starting with LDAP" case. | 17:10 |
| th1a | One question is whether or not the LDAP module is part of the standard distribution of SchoolTool and you turn it on with a switch, | 17:11 |
| th1a | or if it is an add-on. | 17:11 |
| jinty | I think that in general a zcml include should not do irreversible things by just merely being included in zcml | 17:12 |
| ignas | jinty: well, person class switch is a nasty thing :/ | 17:12 |
| jinty | zcml include should just make functionality available which can be configured in the config file | 17:12 |
| ignas | jinty: and i have yet to think of a way to make it work better, without spending too much time on it | 17:13 |
| jinty | for example, skins | 17:13 |
| ignas | it effectivelly changes the class that will be used when creating a person | 17:13 |
| jinty | I'm more just saying how I would like things to work, from a sysadmin point of view | 17:13 |
| ignas | and you can't switch all the old persons from one class to another ... | 17:13 |
| jfroche | th1a: ldap support is a really good advantage (mainly for big schools/universities) but question is "do we have to set our priorities on giving a path for ldap support NOW ?" | 17:13 |
| ignas | jinty: turning on/off timetables, courses, sections etc through zcml would do nasty things too | 17:14 |
| jinty | yeah, I'd imagine the impelemtation is difficult | 17:14 |
| th1a | jfroche: Well, I didn't expect that this would turn things so upside-down. | 17:14 |
| jinty | but I think we need to put in place a policy for what add-ins should and shouldn't do | 17:14 |
| ignas | jfroche: a nice advantage is something that works, not just integrates :) | 17:15 |
| ignas | my point being - ldap is like demograhpics | 17:15 |
| ignas | you mus include it on first startup and then it works | 17:15 |
| ignas | that won't take away too much resources from our side | 17:16 |
| ignas | and will work for people who need ldap integration | 17:16 |
| jinty | ignas: perhaps we can have 2 classes of add ins, one which must be there at first startup, and one which can be turned-on/turned-off | 17:16 |
| ignas | jinty: hmm, i don't think we have any addons that can be safely turned off, especially with their complex relationships | 17:17 |
| ignas | notes and commendations might be "switchable off" | 17:17 |
| * jinty want's skins to be add-ins, and to be selectable through the UI | 17:18 | |
| th1a | Can LDAP and non-LDAP persons co-exist on one instance. | 17:18 |
| th1a | ? | 17:18 |
| ignas | th1a: I am afraid they can, but that is a side effect | 17:18 |
| jfroche | it would be dangerous | 17:18 |
| th1a | It is probably a feature in some cases. | 17:18 |
| ignas | th1a: you can have Person A as a demographics person, and persons B, C, D as LDAP persons | 17:18 |
| ignas | th1a: it is dangerous, unstable, and it can set your cat on fire | 17:19 |
| ignas | you can't assume that LDAP person will have same attributes as a different kind of person | 17:19 |
| ignas | one of them has middle name, another one doesn't | 17:19 |
| th1a | It is times like this I think all this stuff about component architecture and interfaces is a bunch of crap. | 17:20 |
| ignas | how do you perform a "Search" on Persons ? | 17:20 |
| ignas | th1a: you don't have to deal with the code ;) so i don't think there is much use for you out of the CA | 17:20 |
| th1a | Isn't the point of an interface that we define IPerson and then the LDAP person has to provide that? | 17:21 |
| ignas | yes and no | 17:21 |
| ignas | IPerson means - you have timetables, calendars can be in groups, courses etc. | 17:22 |
| ignas | but PersonContainer still has to display a useful table of persons | 17:22 |
| ignas | not a largest common denominator (a.k.a. IPerson) | 17:22 |
| ignas | but something school specific | 17:22 |
| ignas | what is the point of a custom person if it looks all the same in the UI :) | 17:23 |
| th1a | I want an LDAP person to look the same as a ZODB person. | 17:23 |
| ignas | and how does ZODB person looks like ? | 17:24 |
| ignas | like a schoolbell person, Demographics person, lyceum person, or Belgium Person>? | 17:24 |
| th1a | There are two separate issues here. | 17:24 |
| th1a | 1) authentication | 17:25 |
| th1a | 2) other directory data. | 17:25 |
| th1a | I think we need to make sure to keep them separate. | 17:25 |
| jfroche | th1a: Ian would like both of them | 17:25 |
| th1a | A Person that uses LDAP instead of ZODB for authentication should otherwise act exactly the same as other Persons. | 17:26 |
| ignas | When a new person is being authenticated (one that has no object in ZODB) authentication utility must create a new object. And yes a plain Demographics person can be used. | 17:26 |
| th1a | If you want to add additional data about a person from LDAP, that's your general exensibility case. | 17:26 |
| ignas | but i don't think anyone would do that | 17:26 |
| th1a | You need to make a custom person that matches your LDAP schema. | 17:27 |
| th1a | Right? | 17:27 |
| ignas | most probably you will want to | 17:27 |
| ignas | not that you must | 17:27 |
| ignas | so yes, it is possible to use LDAP for authentication only | 17:27 |
| ignas | and in such case - you could turn off LDAP | 17:27 |
| ignas | and it would work | 17:27 |
| ignas | on the other hand - if you want data to be synchronized with LDAP - you will need a new person class | 17:28 |
| th1a | I'd like to think you could add your LDAP data into a custom annotation rather than subclassing. | 17:28 |
| ignas | th1a: if you don't want to do anything with it, except for viewing it on a per person basis, then yes you could | 17:29 |
| th1a | OK, perhaps this is a basic question then... | 17:29 |
| th1a | What do we expect a generic PersonContainer table to be able to access? | 17:29 |
| th1a | Answer: not necessarily much. | 17:30 |
| ignas | Answer - columns defined in PersonFactoryUtility | 17:30 |
| th1a | Or is that irrelevant? | 17:30 |
| ignas | as there is only 1 FactoryUtility active per application | 17:31 |
| ignas | the Generic PersonContainer list is very universal | 17:31 |
| ignas | but if you suddently want to switch among more than one PersonFactory - it becomes tricky | 17:31 |
| ignas | but still workable out | 17:31 |
| ignas | ok, not very workable out | 17:32 |
| ignas | same person listing code is used in a lot of places | 17:32 |
| ignas | Attendance, relationships, person lists | 17:32 |
| th1a | Shouldn't the person listing code be limited to what's in IPerson? | 17:32 |
| th1a | Then it can handle any IPerson? | 17:32 |
| ignas | if we don't care about school needs, or about programming time (not showing relevant information or overriding a lot of views) | 17:33 |
| th1a | But viewing a list of persons is perhaps not as common as it seems. | 17:34 |
| jfroche | IPerson is used in a lot lot of places | 17:34 |
| ignas | attendance, group members, section members, selecting instructor | 17:34 |
| ignas | gradebook | 17:34 |
| th1a | Yes, Persons are obviously important to a school ;-) | 17:35 |
| ignas | all of these places deal with PersonClass (it's Student information System) :) | 17:35 |
| th1a | I'm saying you don't need to access all the particulars of each school's demographic schema just to make a list of students. | 17:36 |
| ignas | yes, you don't have to | 17:36 |
| ignas | i still don't understand the usecase | 17:37 |
| ignas | having authentication and full ldap integration separately -- this one is doable | 17:37 |
| ignas | switching between full ldap integration and no ldap integration -- this one is expensive | 17:38 |
| th1a | OK. Forget switching. | 17:38 |
| th1a | I'd like to see two things: | 17:39 |
| th1a | * you can add LDAP authentication to any kind of Persons with minimal fuss. | 17:39 |
| th1a | Actually, that's all I care about personally. | 17:40 |
| jfroche | but Ian wants more | 17:40 |
| th1a | Yes. | 17:40 |
| th1a | Now, what he wants to store isn't really demographics at all, right? But assessment data. | 17:40 |
| ignas | th1a: doable, when do you want it ? | 17:41 |
| th1a | ignas: I'm paying Ian's guys to do it this month. That's the whole idea ;-) | 17:41 |
| th1a | But clearing the path for them is a good idea. | 17:41 |
| ignas | hmm | 17:42 |
| jfroche | he wants demographics data inside ldap too as far as i understood | 17:43 |
| ignas | how much clearing do we want ? | 17:43 |
| ignas | th1a: one can think of 90% of the whole as "clearing" | 17:43 |
| th1a | Yes, I suppose most of the job is rearranging things rather deep in SchoolTool. | 17:44 |
| ignas | citing fowler - "refactor to make implementation of the feature easy, and then implement the feature" | 17:44 |
| jfroche | he wants demographics info in ldap but also security related info such as groups | 17:44 |
| ignas | th1a: not very deep, but very precise ... | 17:44 |
| th1a | Well, the most sane way to approach this might be to just accept we're all going to have to do this together at PyCon. | 17:45 |
| ignas | hmm :/ | 17:46 |
| ignas | the only problem i have with this is that it's not the direction i need ... | 17:46 |
| th1a | Yes. | 17:47 |
| ignas | i mean having a custom person - i needed it anyway, so the question was - how soon to do it | 17:47 |
| ignas | translations - i need them anyway | 17:47 |
| ignas | person group information stored in ldap - ? | 17:47 |
| th1a | RIght. | 17:48 |
| th1a | Beyond that, getting back to where we started, making LDAP do this stuff isn't nearly as hard as figuring out how to make this plug/unplug with SchoolTool. | 17:49 |
| ignas | i hope they are fast learners :) | 17:49 |
| th1a | I guess one additional piece of context is that I personally only really care about the basic authentication step. | 17:49 |
| jfroche | th1a: i can play with authentication inside ldap with Jens remotly | 17:51 |
| th1a | To me it would be ok if we ended up with some LDAP-SchoolTool modules that required some manual ZCML jockeying to get working. | 17:51 |
| *** thisfred has quit IRC | 17:52 | |
| th1a | That had to be installed before anything else was done. | 17:52 |
| th1a | Does that sound reasonable? | 17:53 |
| th1a | In terms of keeping this task sane? | 17:53 |
| ignas | yes, sounds sane | 17:53 |
| jfroche | yep that's good | 17:54 |
| * ignas warns that he is going to be very egoistic when negotiations about the scope of the task will begin in pycon | 17:54 | |
| ignas | helpful | 17:54 |
| ignas | but egoistic | 17:54 |
| th1a | We should definitely have the scope of the task very clearly defined by then. | 17:54 |
| th1a | Before PyCon. | 17:55 |
| *** aelkner has joined #schooltool | 17:56 | |
| jfroche | th1a: i can look at ldap authentication from now on with Jens or i wait for pycon ? | 17:56 |
| th1a | Well, keeping a conversation going about the design is important. | 17:57 |
| th1a | I don't necessarily want you writing a lot of code that only applies to this. | 17:59 |
| ignas | commit at least something :) so i could comment on how to plug it into schooltool conveniently | 17:59 |
| ignas | the first implementation can be hardcoded in a branch | 17:59 |
| th1a | Do we need an LDAP branch? | 17:59 |
| th1a | Yes. | 17:59 |
| ignas | yes | 17:59 |
| jfroche | yep i ll do it in a ldap branch | 17:59 |
| jfroche | i do it dirty, ignas make it look clean :) | 17:59 |
| ignas | nope :P | 18:00 |
| ignas | i will give you hints | 18:00 |
| ignas | and you will make it clean | 18:00 |
| th1a | OTOH, jfroche, if working on this is giving you a good start on getting deeper into SchoolTool, you can keep going for that reason. | 18:00 |
| jfroche | ignas: sure | 18:00 |
| jfroche | th1a: yep it could help | 18:01 |
| jfroche | and could help Jens also | 18:01 |
| th1a | If the collaborative angle is giving you momentum, don't kill it. | 18:02 |
| th1a | OK. We're way over. | 18:03 |
| th1a | Anything else pressing? | 18:03 |
| ignas | not really, tomorow i am going to US embassy, and to Lyceum | 18:03 |
| *** thisfred has joined #schooltool | 18:04 | |
| th1a | Hopefully my government will be nice to you. | 18:04 |
| th1a | Have a good week, folks. | 18:05 |
| * th1a drops the bag of gravel. | 18:05 | |
| ignas | bye | 18:05 |
| jfroche | th1a: and congratulations !!!! | 18:07 |
| th1a | jfroche: Thanks! | 18:07 |
| *** wdickers has joined #schooltool | 18:09 | |
| *** shubacka has quit IRC | 18:18 | |
| wdickers | tha1: you there? | 18:21 |
| wdickers | *th1a | 18:21 |
| Lumiere | hi wdickers | 18:33 |
| wdickers | hey, in the XML for Sif_Events, do you know what the StudentPersonal's RefId should be? | 18:34 |
| Lumiere | ! me | 18:34 |
| wdickers | Or the name element's type and format? | 18:34 |
| wdickers | I copied the codes from the spec's telephone example, but it seems to be invalid | 18:34 |
| *** wdickers has quit IRC | 18:41 | |
| *** ignas has quit IRC | 19:29 | |
| *** jfroche_ has joined #schooltool | 19:39 | |
| *** jfroche has quit IRC | 19:55 | |
| *** thisfred has quit IRC | 20:09 | |
| *** aelkner has quit IRC | 20:57 | |
| *** alga has quit IRC | 21:11 | |
| *** mgedmin has quit IRC | 21:15 | |
| *** alga has joined #SchoolTool | 21:23 | |
| *** jfroche__ has joined #schooltool | 21:25 | |
| *** jfroche_ has quit IRC | 21:41 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!