| *** tiredbones has quit IRC | 00:00 | |
| *** tiredbones has joined #schooltool | 00:00 | |
| *** pcardune has joined #schooltool | 00:06 | |
| pcardune | hi srichter, did you get that email from jeff? | 00:08 |
|---|---|---|
| srichter | pcardune: yes | 00:09 |
| pcardune | did you have any comments about a possible timeline? | 00:09 |
| srichter | not yet | 00:10 |
| srichter | I am very busy, but I think most of it can be done during the summer | 00:10 |
| srichter | the big thing is really all the javascript for the console stuff | 00:11 |
| pcardune | ok, well, the applications are due today so i thought I would ask | 00:11 |
| srichter | actually, the timeline is already past | 00:11 |
| srichter | it was 11 am pacific time today | 00:11 |
| pcardune | am? | 00:11 |
| pcardune | oh... | 00:11 |
| srichter | as far as I remember, yes | 00:11 |
| pcardune | well then nevermind i guess | 00:12 |
| srichter | it was due last night and they changed to 11 am today | 00:12 |
| srichter | yep, I just checked; I cannot add applications anymore | 00:12 |
| srichter | did you not write an application earlier? | 00:13 |
| pcardune | i did, but i hadn't submitted it yet | 00:13 |
| srichter | that sucks | 00:13 |
| pcardune | yep | 00:14 |
| *** pcardune has quit IRC | 00:37 | |
| *** didymo has joined #schooltool | 00:43 | |
| *** lees93 has joined #schooltool | 05:44 | |
| *** didymo has quit IRC | 05:46 | |
| *** lees93 has left #schooltool | 05:46 | |
| *** jinty has joined #schooltool | 06:46 | |
| povbot | /svn/commits: * jinty committed revision 6029: | 07:35 |
| povbot | /svn/commits: schooltool.generations depends on schooltool.demographics. This also un-breaks the nightly tarball build. | 07:35 |
| th1a | Ah, jinty is awake for some reason. | 07:35 |
| jinty | th1a: yeah, I'm getting up at 5am these days;) | 07:35 |
| th1a | I was just trying to register the ST svn trunk in the 2006 series on LaunchPad & I don't seem to have permission. | 07:36 |
| th1a | Oh, and it looks like our translations are in there. | 07:37 |
| jinty | th1a: cool, you uploaded the schoolbell translations to schooltool? | 07:42 |
| th1a | Jordi did. | 07:43 |
| th1a | And it looks like he moved the old translations over. | 07:43 |
| th1a | http://en.wikipedia.org/wiki/User_agent#Example_user-agent_strings | 07:43 |
| th1a | Whoops. | 07:43 |
| th1a | Can't cut and paste from my linux box to my mac. | 07:43 |
| jinty | great, I was feeling a bit sorry for those translators... | 07:44 |
| jinty | :) | 07:44 |
| jinty | LOL | 07:44 |
| th1a | https://launchpad.net/products/schooltool/2006/+pots/schooltool | 07:44 |
| th1a | I have received a battery for my new ThinkPad, but the rest of the computer will take a few more weeks. | 07:45 |
| jinty | and the makefile rules? anyone tried them out yet? | 07:45 |
| th1a | Then I'll be off the Mac. | 07:45 |
| th1a | I don't think so... | 07:45 |
| jinty | really? I thought Mac's were meant to be even more ultra cool than thinkpads... | 07:46 |
| th1a | The thing is my boss started a Linux distribution. | 07:46 |
| th1a | Plus I just want to be able to do more believable Linux advocacy at ed-tech conventions and such. | 07:47 |
| th1a | And I've had my share of problems with Mac hardware anyhow. | 07:47 |
| jinty | you've got ubuntu mac? | 07:47 |
| jinty | you've got ubuntu on the mac? | 07:48 |
| th1a | I couldn't really dual boot. | 07:48 |
| th1a | I can't stand rebooting a computer anymore. | 07:48 |
| th1a | I've got a big old PC running Linux. | 07:48 |
| * jinty is sitting with an acer, and has already lost a few peripherals, may they RIP | 07:48 | |
| th1a | I just bought a giant white box a few years ago and just replace components as the die. | 07:49 |
| th1a | I'm very happy with that approach. | 07:49 |
| jinty | works for me as well, that 500Mhz cpu is still just fine | 07:50 |
| jinty | the most it needs to do is play movies | 07:50 |
| jinty | But I will _*never*_ buy another acer laptop no matter how cheap they are. | 07:51 |
| th1a | Oh, acer laptop. | 07:52 |
| th1a | Yes, laptops come and go as units, unfortunately. | 07:52 |
| th1a | Anyhow, jinty, would you like to try registering the 2006 trunk, or should I just nag SteveA tomorrow? | 07:58 |
| jinty | ah, I didn't realise you were asking me that... | 08:12 |
| jinty | having a look | 08:12 |
| jinty | hmm, th1a, as far as I can see we can't right now. At least not until we have a 2006 branch and ST 2006 packages in ubuntu. | 08:17 |
| jinty | though I did get the svn to point at the trunk. We should change it later | 08:18 |
| th1a | Hm. | 08:21 |
| th1a | Well, the idea is that it'll be available via bzr soon? | 08:23 |
| th1a | Once the Bazaar sucks it up? | 08:23 |
| th1a | Thanks for doing that, jinty. | 08:26 |
| jinty | no worries | 09:56 |
| *** jinty has quit IRC | 10:47 | |
| *** thisfred has joined #schooltool | 11:33 | |
| *** faassen has joined #schooltool | 11:33 | |
| *** Aiste has quit IRC | 11:37 | |
| *** jinty has joined #schooltool | 12:12 | |
| *** Aiste has joined #schooltool | 12:31 | |
| *** mgedmin has joined #schooltool | 12:53 | |
| *** alga has joined #SchoolTool | 13:16 | |
| povbot | /svn/commits: * faassen committed revision 6030: | 13:56 |
| povbot | /svn/commits: Make CSV import of persons also use the demographics package. | 13:56 |
| *** jinty has quit IRC | 14:38 | |
| *** ignas has joined #schooltool | 14:57 | |
| faassen | hm. | 15:01 |
| faassen | what's the policy of using generations? | 15:01 |
| faassen | whenever I do a checkin that changes the data format, do I need to add an evolution script? | 15:01 |
| faassen | because I fear that might end up being a lot of evolution scripts. | 15:02 |
| mgedmin | the official policy is that we support evolution between releases only | 15:03 |
| faassen | hm, ok. | 15:03 |
| mgedmin | if you track the trunk, you're on your own | 15:03 |
| faassen | ah, okay. | 15:03 |
| faassen | that's good to know. | 15:03 |
| mgedmin | on the other hand it is nice to not break people's sandboxes too often | 15:03 |
| faassen | yes. | 15:03 |
| faassen | true. | 15:03 |
| mgedmin | and small evolution scripts may be easier to unit-test than large ones | 15:03 |
| faassen | right, I'm currently not actually evolving anything *to* anything. | 15:03 |
| faassen | just adding an attribute. | 15:04 |
| faassen | which means I'm evolving nothing into something. | 15:04 |
| faassen | anyway, I'll keep that in mind. | 15:04 |
| faassen | I may provide an evolution script. | 15:04 |
| mgedmin | on the gripping hand if the final data structures are not stabilised and are likely to change, it may be better to not write evolution scripts for all the intermediate temporary formats | 15:04 |
| faassen | I did so for my last change, but that was rather a major pain. still, it had to be done. | 15:04 |
| faassen | right. | 15:04 |
| faassen | the data structures aren't exactly stable yet. | 15:04 |
| faassen | so I won't do evolution for the time being. | 15:04 |
| mgedmin | often it is easiest to avoid evolution script altogether by making new attributes class attributes etc | 15:04 |
| faassen | well, this is one example of annotations. :) | 15:05 |
| faassen | they just exist whenever you get them. | 15:05 |
| * mgedmin has to go now | 15:05 | |
| faassen | still, I think that in part papers over the real issue: data models *are* changing. | 15:05 |
| faassen | ok. | 15:05 |
| *** mgedmin has quit IRC | 15:05 | |
| faassen | ignas: do you have time to talk about security ideas? I just wanted to brainstorm a bit about permissions and data types. | 15:05 |
| ignas | yes | 15:05 |
| faassen | ignas: okay, let's talk then. :) | 15:06 |
| ignas | let me just open up the new Acces control chart ;) | 15:06 |
| faassen | okay. :) | 15:06 |
| faassen | where is that? | 15:06 |
| ignas | in schooltool mailing list | 15:06 |
| faassen | oh here, a new one this morning. | 15:06 |
| faassen | anyway, what I was thinking about vaguely.. | 15:07 |
| faassen | let me try to come up with your strategy.. | 15:07 |
| faassen | I mean, try to describe it. | 15:07 |
| faassen | see whether I'm right. | 15:07 |
| faassen | concerning permissinos. | 15:08 |
| faassen | permissions. | 15:08 |
| faassen | you want to know which data types are in the system. | 15:08 |
| faassen | like, Person | 15:08 |
| faassen | or Group | 15:08 |
| faassen | or Course | 15:08 |
| faassen | etc. | 15:08 |
| ignas | yes | 15:08 |
| faassen | and then you define permissions for each: add Person, edit Person, view Person | 15:08 |
| faassen | add Group, edit Group, etc | 15:08 |
| faassen | right? | 15:08 |
| ignas | kind of | 15:08 |
| ignas | not sure yet as i haven't started yet | 15:08 |
| faassen | yes, I know, I wanted to talk to you before you started. | 15:08 |
| faassen | anyway, you'll end up with an explosion of permissions. | 15:08 |
| faassen | a number for each data type. | 15:09 |
| faassen | I'll skip the whole role story as that's irrelevant to what I want to discuss I think. | 15:09 |
| ignas | probably, i think i'll need at least as much permissions as there are green/yellow cells in the table | 15:10 |
| faassen | anyway, I'll call this model the Document Library Model | 15:10 |
| ignas | maybe less maybe a bit more | 15:10 |
| faassen | as we did approximately that for the doclib. | 15:10 |
| faassen | there's also the Silva model for permissions. | 15:10 |
| faassen | where basically we have few permissions to care about. | 15:10 |
| faassen | basically as many as we have roles, almost. | 15:10 |
| faassen | ViewSilvaContent, ReadSilvaContent, ChangeSilvaContent, ApproveSilvaContent, ChangeSilvaAccess | 15:11 |
| faassen | these map fairly straightforwardly to roles in Silva. | 15:11 |
| faassen | viewer, reader, author, editor, chief editor | 15:11 |
| faassen | where each increased role gets more of the permissions. | 15:11 |
| faassen | I just wanted to throw that in, even though right now I don't think it's applicable to Schooltool. | 15:12 |
| faassen | as you need a more fine-grained story. | 15:12 |
| faassen | but I just wanted to posit the alternative model there. | 15:12 |
| ignas | i see | 15:12 |
| faassen | the benefit is far less permissions to think about. | 15:12 |
| faassen | anyway, now I think there's a third model. | 15:12 |
| faassen | but I'm not sure about it. | 15:12 |
| faassen | which is the Security Policy model. | 15:12 |
| faassen | the idea is we stick to the basic schooltool.view and schooltool.edit permissions. | 15:12 |
| faassen | (what to do for add permissions I'm not sure :) | 15:12 |
| faassen | so we don't have an explosion of permissions. | 15:13 |
| faassen | instead, a security policy basically receives an object and a permission. | 15:13 |
| faassen | and it says 'yes, this user has that permission on the object' | 15:13 |
| faassen | or 'no, the user doesn't have that permission on the object' | 15:13 |
| faassen | and we put the intelligence of figuring out whether someone may edit a person in a rule system. | 15:13 |
| faassen | I think that in some ways life will be easier. | 15:14 |
| faassen | as we *have* a centralized expression of permission rules. | 15:14 |
| faassen | which is the chart. :) | 15:14 |
| faassen | and we don't have to hunt through the entire codebase and change permissions around. | 15:14 |
| faassen | while I expect getting a sound policy up and running early on will be harder. | 15:15 |
| faassen | I think it might be easier on the medium term. | 15:15 |
| faassen | because of that. | 15:15 |
| faassen | okay, now I shall await you response. :) | 15:15 |
| ignas | the downsides i can see are - extending the system - let's say adding something the size of timetables would require to add some rules for the new module | 15:15 |
| faassen | you could make a model where extensions can subscribe into the rule base. | 15:16 |
| ignas | which will require to have a plugable security policy that should be easily extendable through subscribers and stuff | 15:16 |
| faassen | right. | 15:16 |
| faassen | that's a downside. | 15:16 |
| faassen | you could of course have a default policy for unknown objects. | 15:16 |
| faassen | anyway, benefits is: don't have to hunt everywhere and change permissions around. | 15:17 |
| faassen | so simpler to reason about for developer. | 15:17 |
| faassen | centralized rules in chart -> centralized rules in code. | 15:17 |
| faassen | or at least more centralized as when we scatter things like roles and permissions everywhere. | 15:18 |
| ignas | well - chart is data so i would like to keep it in the data (zcml) land leaving the irregular/customizable parts to code | 15:19 |
| faassen | zcml isn't data land. | 15:19 |
| faassen | zcml is hooking things up land. | 15:19 |
| faassen | but you're going to have to root through the entire codebase to add custom permissions everywhere. | 15:19 |
| faassen | and eveyrone is going to have to learn about this. | 15:19 |
| faassen | and that's yet one more thing that is going to make schooltool programming harder. | 15:19 |
| faassen | and you'll have to debug it in all places. | 15:20 |
| ignas | i'd say that cutom security policy you must plug in every time you add a content object is more difficult | 15:20 |
| ignas | while - just assigning it fooDataType (DataType probably being one of already described ones) is easier | 15:21 |
| ignas | though i might be wrong | 15:21 |
| ignas | and no you won't have to debug it | 15:21 |
| faassen | won't you have to basically review all permissions in the whole system? | 15:22 |
| faassen | and change them? | 15:22 |
| faassen | and pick one out of 20 new permissions and put in the right one? | 15:22 |
| ignas | i would need to do that both ways, even with edit/add model, though edit/add model would make the task more straightforward | 15:22 |
| faassen | and then test whether this actually is the proper behavior in the UI? | 15:22 |
| faassen | I mean, you'll have to test it obviously in any case. | 15:23 |
| faassen | anyway, I've also got the impression from Jim that people often try to model their app's security policy into Zope's. | 15:23 |
| faassen | and that they should consider more often new security policies where this isn't needed. | 15:23 |
| faassen | perhaps I shall talk to him and see what ideas he has for designing security in Zope 3. | 15:24 |
| ignas | at the moment i am thinking that it is easier to have a few "dumb" parts that plug into zope security policy rather than a smart know all do all security policy | 15:25 |
| faassen | ignas: well, that's what I did with the document library, but I'm not sure it's a good idea. :) | 15:25 |
| ignas | as it might get complicated when considering permissions for Viewlets and simmilar components | 15:26 |
| faassen | we modeled the application containership story so it would match the security requirements. | 15:26 |
| faassen | well, it isn't complicated to select 'view' and 'edit' out of the list of 2 permissions. :0 | 15:26 |
| faassen | :) | 15:26 |
| faassen | the security system will check on the object the viewlet is working for. | 15:27 |
| faassen | so it'll say 'uh uh, no' | 15:27 |
| faassen | whenever needed. | 15:27 |
| faassen | anyway, take a look at this file: | 15:27 |
| faassen | https://infrae.com/viewvc/documentlibrary/trunk/src/documentlibrary/core/security.zcml?revision=19661&view=markup | 15:27 |
| ignas | anyway - my plan (as suggested by mg) was to make a 2 hour (the time we spent on our last access control spike) spike | 15:29 |
| ignas | trying to implement a custom security policy | 15:29 |
| ignas | and see how it might work | 15:29 |
| faassen | right. I'd be unambitious and make everything public, and then try to restrict specific bits. | 15:29 |
| ignas | how often it is being called and stuff | 15:29 |
| faassen | it'll be called a lot. | 15:30 |
| ignas | IPrincipalRoleMap adapter is getting called like 10-20 times per view | 15:30 |
| faassen | anyway, I didn't know that custom policy spike was already planned. | 15:30 |
| faassen | so perhaps I'm just arguing for something that was already planned. :) | 15:31 |
| faassen | anyawy, look at that file for the doclib, that sort of demonstrates what it tends to look like. :) | 15:31 |
| faassen | the non-security policy approach. | 15:31 |
| faassen | doclib is pure default security policy. | 15:31 |
| faassen | hm, I wonder why viewvc access is so slow right now. | 15:33 |
| ignas | faassen: couldn't you like split that file into associated modules ? like having Document permissions and Document grants in the Document zcml file and only having Roles described in the main zcml file ? | 15:34 |
| ignas | as from my point of view - you either put the code that maps Principal -> canDo/can't Do in some subscriber in your code | 15:35 |
| ignas | or you add new permissions and add grants for appropriate roles in the zcml in the zcml of your module | 15:35 |
| ignas | one is as complex as the other i am afraid | 15:36 |
| faassen | ignas: well, you don't have a permission explosion in the one case. :) | 15:36 |
| ignas | you don't have all permissions in one file | 15:36 |
| ignas | and the ammount of logic/thinking required is the same | 15:37 |
| faassen | ignas: anyway, about splitting up taht file, yeah, we can. we didn't yet as we were more concerned with getting it all to work properly. | 15:37 |
| faassen | ignas: anyway, those are good points. | 15:37 |
| faassen | ignas: the main nice thing about custom security policies is that you can for instance determine things on another basis than containment. | 15:38 |
| faassen | ignas: but of course custom adapters can also help there. | 15:38 |
| faassen | ignas: anyway, since you're going to try this anyway, I'll just stop this discussion. I think I made all the points I wanted to make and heard some useful counter arguments. :) | 15:38 |
| ignas | thank you | 15:38 |
| ignas | th1a: ping me ;) | 15:39 |
| povbot | /svn/commits: * faassen committed revision 6031: | 16:00 |
| povbot | /svn/commits: whitespace | 16:00 |
| povbot | /svn/commits: * faassen committed revision 6032: | 16:01 |
| povbot | /svn/commits: add 'demographics' screen. | 16:01 |
| povbot | /svn/commits: Note that the drop down boxes content is temporary. | 16:01 |
| povbot | /svn/commits: Note that this will break your content as a new demographics attribute is added. | 16:01 |
| povbot | /svn/commits: * faassen committed revision 6033: | 16:11 |
| povbot | /svn/commits: Remove security declaration moved to demographics package. | 16:11 |
| *** jinty has joined #schooltool | 16:20 | |
| *** jinty has quit IRC | 17:00 | |
| *** alga has quit IRC | 17:41 | |
| *** alga has joined #SchoolTool | 17:48 | |
| povbot | /svn/commits: * faassen committed revision 6034: | 18:00 |
| povbot | /svn/commits: Use multisubscribers instead of checks in the subscriber code itself where possible. | 18:00 |
| povbot | /svn/commits: This means that some conditional logic in the events could go away. Some tests have also been simplified, as they were verifying the conditional logic which would never occur in normal code-paths (where the subscribers get called). | 18:00 |
| *** alga has quit IRC | 18:01 | |
| th1a | ignas: pong. | 18:01 |
| ignas | you have collapsed administrator groups into one column because ? | 18:03 |
| ignas | i am not sure i understood the motive for that :/ | 18:04 |
| th1a | I did it because they were all getting the same permissions and it would seem to simplify the process. | 18:05 |
| th1a | And arguably is more predictable for users. | 18:05 |
| ignas | oh | 18:05 |
| ignas | i see | 18:05 |
| th1a | I can go through and say, well, a school administrator doesn't need to do *that*, | 18:06 |
| th1a | but inevitably a school administrator will expect to be able to do *that*, or a site manager will wonder why the administrator can't do *that*. | 18:07 |
| ignas | i was just asking | 18:07 |
| ignas | i just wanded you to know that we can support different roles for different groups with the upcomming access model | 18:07 |
| ignas | i mean - i wanted to be sure that you know that | 18:07 |
| th1a | We'll probably want to in the long run. Im trying to SIMPLIFY this process right now as much as possible. | 18:08 |
| th1a | My new ThinkPad just arrived. | 18:09 |
| ignas | :D | 18:10 |
| ignas | welcome to ThinkPad family ;) | 18:10 |
| th1a | Do you guys keep the "Rescue and Recovery" partition around? | 18:10 |
| ignas | err - my laptop was used - so it didn't have one already, marius managed to erasi his | 18:11 |
| ignas | by accident ;) | 18:11 |
| ignas | i can't remember whether alga still has his rescue partition | 18:11 |
| th1a | But it is desirable? | 18:12 |
| ignas | can't tell i have missed mine that much, but if you are going to reinstall windows some time | 18:13 |
| ignas | and don't have an install CD | 18:13 |
| ignas | you should probably keep it in case you manage to completely bork your laptop | 18:14 |
| ignas | IIRC install/rescue and recovery CD's cost money, but you can get them at any IBM support office | 18:15 |
| th1a | What sucks is they don't send you XP install disks anymore. | 18:15 |
| th1a | I'd like to just set up Windows on VMware, but I don't think I can. | 18:16 |
| ignas | indeed | 18:18 |
| ignas | i have a valid serial key, and can't get Windows XP OEM CD anywhere | 18:18 |
| * ignas is too lazy to got to IBM and ask for one | 18:18 | |
| th1a | Am I supposed to be able to tap the little red joystick for a click? | 18:33 |
| ignas | nope | 18:34 |
| ignas | or maybe | 18:34 |
| ignas | not on linux iir | 18:34 |
| ignas | s/iir/iirc | 18:34 |
| *** faassen has quit IRC | 19:41 | |
| *** jinty has joined #schooltool | 19:55 | |
| *** ignas has quit IRC | 20:03 | |
| *** mgedmin has joined #schooltool | 20:09 | |
| *** thisfred has left #schooltool | 20:53 | |
| *** Hwyvar has joined #schooltool | 21:28 | |
| *** knoppix has joined #schooltool | 21:56 | |
| knoppix | hey | 21:57 |
| knoppix | does someone use Linux here? plz i need a bit pf help | 21:59 |
| knoppix | ého? | 22:00 |
| *** knoppix has left #schooltool | 22:01 | |
| *** mgedmin has quit IRC | 23:04 | |
| *** Aiste has quit IRC | 23:07 | |
| *** Aiste has joined #schooltool | 23:31 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!