IRC log of #schooltool for Tuesday, 2006-05-09

*** didymo has joined #schooltool02:52
*** Hwyvar has quit IRC03:30
*** Gwynn has joined #schooltool05:24
*** jinty has joined #schooltool05:42
*** strichter has joined #schooltool07:02
*** srichter has quit IRC07:25
*** Aiste has quit IRC12:06
*** Aiste has joined #schooltool12:29
*** faassen has joined #schooltool12:58
*** thisfred has joined #schooltool13:13
*** mgedmin has joined #schooltool13:37
*** ignas has joined #schooltool13:39
*** alga has joined #SchoolTool13:57
*** strichter is now known as srichter14:03
*** didymo has quit IRC14:17
*** srichter has quit IRC14:32
povbot/svn/commits: * ignas committed revision 6023:14:41
povbot/svn/commits: Refactored TimetableSetup view a bit.14:41
*** srichter has joined #schooltool14:43
*** srichter has joined #schooltool15:02
*** faassen has quit IRC15:27
*** faassen has joined #schooltool15:28
povbot/svn/commits: * faassen committed revision 6024:15:40
povbot/svn/commits: Move demographics support into its own package, to work towards the following:15:40
povbot/svn/commits: * other applications that use schooltool.person do not need to be bothered15:41
povbot/svn/commits: by demographics related stuff.15:41
povbot/svn/commits: * prepare the ground for pluggable demographics. If you want a different15:41
povbot/svn/commits: demographics system, in the future we'll be able to do the following:15:41
povbot/svn/commits: * create a demographics package, subclass from schooltool.person in it,15:41
povbot/svn/commits: or from an existing demographics package you want to extend.15:41
povbot/svn/commits: * register your subclass with extra/different demographics into the15:41
povbot/svn/commits: skin as the add form. The skin would in the future be the skin of the particular customization, say, schooltool_us.15:41
povbot/svn/commits: * some extra steps will eventually need to be taken for custom search,15:41
povbot/svn/commits: and custom tabular display.15:41
povbot/svn/commits: Had to struggle quite hard to get the evolution script to work properly; this was the hardest part of the work...15:41
povbot/svn/commits: * ignas committed revision 6025:15:41
povbot/svn/commits: Add scheduling view for resources.15:41
povbot/svn/commits: * mg committed revision 6026:15:45
povbot/svn/commits: Bugfix: quote the URL for the login form.15:46
povbot/svn/commits: If you tried to access a page with a '+' in the URL (e.g. ++etc++site or an add form), but did not have permission to do so, you'd get a login form.  If you then logged in successfully, you'd be redirected to a nonexistent page because all the '+' signs in the URL were replaced with spaces.15:46
povbot/svn/commits: It was an old and well-known issue.  I cannot find the issue number in the tracker -- maybe it was never filed?15:46
povbot/svn/commits: * mg committed revision 6027:16:26
povbot/svn/commits: Move setUpTimetabling into a new setup module in the s.a.browser.ftests package.  Introduce a couple of functions that I'm using in a ftest that will soon be added.16:26
* th1a shuffles some papers around.16:29
* srichter is here16:29
* faassen is here.16:30
th1asrichter:  How are you feeling?16:30
srichtercrappy, to be honest16:30
faassensrichter: what's wrong?16:30
th1aBird flu.16:30
srichterI am still feeling dizzy and conjested from the pressure on my ear drums16:30
faassensrichter: oh ick16:30
* mgedmin is here16:31
faassenth1a: joking I hope!16:31
th1aHe brought it to the US.16:31
srichterif so, I would be the first survivor ;-)16:31
th1aIt is all over the news.16:31
srichterhe he16:31
faassenStephan Richter, Zope 3 release manager, downed by bird flu!16:31
faassenExtra extra!@16:31
th1asrichter dooms America.  Everyone blames him!16:31
faassenBush sez: srichter doomed Amurrica!16:31
mgedminthe only known survivor used Zope 3!16:31
mgedminuse Zope 3 to be safe!16:31
* faassen laughs.16:31
* faassen watches hordes of PHP hackers make the transition.16:32
faassenoh no!16:32
th1aOK, so we have lots of access control discussion to get to.16:32
faassenok. :)16:32
th1aLet's just have some *quick* updates.16:32
faassenabout non-access control issues?16:33
th1aJust where you are, what you're planning.16:33
th1afaassen:  Would you like to start?16:33
faassenyes. last week was not very productive due to LinuxTag and training new employee here16:33
faassenbut I did some work the result of which is checked in today.16:33
faassenbasically I separated the demographics work I did before out from schooltool.person and put it into its own person.16:34
faassenthen I tried to write an evolution script, which was by far the hardest, to use a new person subclass defined in the demographics package.16:34
faassenit turned out that schooltool uses the dependency framework in Zope 3 in such a way that it locks stuff indefinitely and the dependency is unremovable. :)16:34
faassenafter some discussion with mgedmin I worked around that.16:34
faassenso now if you svn up your schooltool, the person objects are taken over by the demographics package.16:35
faassenthe idea is that future customizations of schooltool could provide their own demographics packages.16:35
faassenfor particular schools or countries or whatnot.16:35
faassenbut for now I'll just keep on expanding it.16:35
th1afaassen:  Don't forget we need to finish reorganizing your proposal.16:36
th1aAre you going to have much time for ST the rest of the week?16:36
th1aWe'll skip srichter and I'm going to go visit him as soon as he's in working order.16:37
srichterI have not much to say other than I really need to get back into the term stuff; I am really looking forward to finishing this.16:37
faassenI plan to work on ST this week.16:38
* srichter had already prepared his sentence ;-)16:38
* th1a am really looking forward to srichter finishing this.16:38
th1aOK. Thanks faassen.16:38
faassenth1a: reorganizing the proposal, I need to know who does what.16:38
th1aOn to POV.16:38
faassenth1a: I thought Kit had a conversation with you but if you want something more..16:38
faassenth1a: then you should let us know what exactly you want to see.16:38
ignaswe were working on the proposal16:39
th1afaassen:  OK, I'll pick up the thread.16:39
faassenth1a: I was hoping Kit had worked it out with you already and I think Kit was assuming that.16:39
ignasspiking ACL16:39
ignasfixed a couple of bugs16:39
ignasand are continuing the struggle with conflict resolution for resources16:39
ignasth1a: did you get the draft ?16:40
th1aThanks ignas.16:40
th1aHm... I didn't see it.16:41
th1aWhen did you send it?16:41
algaTo: Tom Hoffman <>, all@pov.lt16:41
algaDate: Tue, 9 May 2006 14:13:00 +030016:41
th1aFound it.16:41
th1aWell, Mark was pretty definitive about the SchoolBell issue in his email, so I guess we'll be striking that item.16:42
ignasstriking as in ?16:43
th1aCan you send the access control section to the dev list while I read over it.16:43
th1aAs in not doing it.16:43
th1aAlthough the access control part of the proposal doesn't really make sense, since the part I wrote is now obselete, I think.16:44
ignasand the todo list is not very informative16:45
ignasthe high level plan is implementing a couple  of IPrincipalRoleMap adapters16:45
ignasthat would hook up needed Roles to principals depending on the context object16:45
th1aHow many nuts in a day?16:46
ignasa productive day is estimated to be ~4 nuts16:46
ignas1 nut -> 1.5 hour16:46
th1aAll right, let's go through this.16:47
th1aSo we're proposing to stop using local grants.16:47
faassen(do I understand that schoolbell is out, by the way)16:48
faassenI mean, I am trying to interpret the schoolbell bit.16:48
ignasi think we are not going to do schoolbell extraction yet16:48
th1aYes, I'm certainly not going to send Mark an invoice for it now.16:48
faassenno schoolbell extraction, ok.16:48
faassenjust wanted to make sure I understood right.16:48
faassena local grant is a local permission grant, right?16:48
th1aWhat's the correct Zope 3 terminology for a new permissions system?16:49
ignasth1a:  by the way - i think we can add an option to hide/show individual calendars to public without using local grants16:49
th1aWe need to write a new... ?16:50
faassenwell, I understood from the words above that you won't make a new security policy.16:50
faassenbut that it'll be done with a number of overridden adapters.16:50
faassenbut the word would be 'security policy'16:50
th1aignas didn't actually change the narrative part, so it is completely obselete and misleading.16:50
th1aJust look at the bullet points.16:51
faassenI didn't read that text.16:51
faassenI just mean this that ignas said on irc:  the high level plan is implementing a couple  of IPrincipalRoleMap adapters16:51
faassenthis implies that this implementation uses the default Zope 3 security policy.16:51
faassenbut changes the way roles are determined for individual objects.16:52
th1aWell, this is my question.16:52
th1aAre we writing a new security policy?16:52
th1aI'm a little unclear on the scope of our ambition.16:53
faassenfrom what I just understood, the answer is no new security policy is written.16:53
faassenbut instead the current security policy is used and adapters are used to change the way roles are determined.16:53
faassennote that writing a new security policy in Zope 3 is not hard technically.16:54
faassenof cousre making it work right may be hard, but it basically only means writing rules that say whether a particular object has certain permissions.16:54
ignasfaasen is right16:54
ignasthe rules would be like "does this object has the principal in it's parents" (the self permission)16:55
th1aSo there are roles in the default Zope security policy, but it isn't evident in the UI?16:55
faassenthe default Zope security policy has roles.16:55
ignasor even "has the parent of this calendar a *public* bit set in his preferences"16:56
faassenI'm still suspecting it might be easier to write a new security policy altogether (this is *not* complicated technically and it may be an easier way to codify the rules we need)16:56
faassenI may be wrong of course, but that's my suspicion.16:57
th1aSo when we say we'll "nuke local grants" do we really mean just get rid of the existing ones and not allow someone to create new ones?16:57
th1aAs opposed to, completely eliminating the idea of local grants?16:57
faassenas far a I understand, people get permissions to objects based on three possibilities.16:57
ignasfaassen: at the moment i think that rules will be simple enough, the "assign permissions to objects views" will be more difficult one16:57
faassenthey're globally given this permission (perhaps because they're in a group or have a role, or whatever)16:57
faassenthey're given permissions because they're the 'owner' of an object. this means that an ownership concept consists somewhere. basically authenticated users are owner of their own person object.16:58
ignass/objects views/objects and views/16:58
faassenand thirdly, they get permissions to an object becasue it has certain relations with the object I own.16:58
ignasfaassen: true16:59
faassenI meam, I get permissions because my person object has certain relations with the object I own.16:59
faassenso there is no local permission mapping at all.16:59
faassenbut there *is* local information, namely the ownership concept16:59
faassenand the relationship concept.16:59
faassenbut this is integral to the system anyway.16:59
faassenignas: what do you mean by 'assign permissions to objects views"? I thought that went away.16:59
faassenignas: but you say it'll be difficult.17:00
ignasfaassen: logical permissions like - who can do what on what SchoolTool objects17:00
ignaswhat objects/views are Personal Data17:00
ignasyes, but instead of using "local grants" that are added by subscribers when local information is modified we want to use code to determine the relationships runtime17:00
faassenignas: I don't understand that.17:00
faassenignas: why does defining something as personal data need to be configured?17:01
ignasfaassen: we have such things as "person names", "person info" in the permission table made by Tom17:01
faassenignas: I mean, for content objects, we just know a limited list of objects (Person, in particular) that someone can be the owner of.17:01
faassenignas: for views, you'd just give them permissions, right?17:01
ignasfaassen: but this is not directly mapping to SchoolTool Views and Objects, and the mapping will have to get crafted by someone17:01
faassenignas: I mean, nothing effectively changes to the views, though we may change which permissions are required a bit here and there.17:02
faassenignas: so do you mean the global configuration screen?17:02
faassenI'm trying to get a hold of this concept..17:02
faassenthere's a global configuration screen where some user-configurable bits about the security policy (I mean, we dno't use the zope 3 security policy but we still do something the same in effect) are tweaked.17:02
faassenlike "teachers may access the demographic data of their students", say.17:03
faassenyou can say yes or not.17:03
faassenthat doesn't sound like a very complicated story to me.17:03
th1aI think we need to define the "data types" a bit more.17:03
faassenbut you're implying that this is complicated.17:03
faassenso I'm worrying I'm missing something somewhere.17:03
ignasfaassen: can you list all the views and objects that are demographic data ? that are Person info ?17:03
srichterbtw, I have made some great experience with a project in this regard in the last weeks too17:04
ignasall the interfaces17:04
faassenignas: wouldn't that be a matter of permissions and ownership?17:04
srichterI think you can define well global permissions and assign them globally the roles17:04
faassensrichter: great experience with what exactly?17:04
srichterbut what you would have to do is split several roles into two17:04
srichterhow to set up permissions, roles and groups for an application17:05
faassenimagine we have just schooltool.view and schooltool.edit17:05
srichterfor example, a teacher is not just a teacher in general, but you also need teacherOfClass17:05
faassenthen our rules system can determine "oh, this person is the owner of the object, so schooltool.view is allowed"17:05
faassenor, "oh, this person is a global school administrator, so they get schooltool.edit"17:06
faassenand even "oh, this person is the teacher of a class in which the student is participating, so they get schooltool.view"17:06
srichterso teacherOfClass would be the owner role for a teacher of a class17:06
ignasmore like - "oh this person is teaching the class let's give him teacherOfClass role"17:06
faassenthat's if you use the zope 3 security policy.17:06
ignaswhen accesing the class object17:06
faassenI'm still not convinced using the default security policy and using roles is actually simplifying anything.17:07
faassenit might be simpler to just codify the rules in a single security policy.17:07
faassenI may be wrong, but I messed with this stuff in document library.17:07
faassenand in the end I was on the fence.17:07
faassenI didn't use a custom security policy.17:07
faassenand that made life easier in the beginning.17:07
th1aYes, that's what I wonder, too.17:07
faassenbut I had to struggle in places too, especially when having to worry about __parent__ being there, etc.17:07
faassenwhich the normal zope 3 security policy needs.17:08
srichteractually, my experience was very positive with the default policy17:08
th1aIt seems like we're changing everything around anyhow. Starting fresh might be cleaner.17:08
faassenand in the end, I wondered what an alternate history would've been like where I'd implemented a new security policy.17:08
faassenI don't know for sure, but it might've been easier.17:08
faassensrichter: I had a mixed experience with the default policy. I had reasonably complex rules including groups and ownership.17:08
srichteryep, I had that too17:08
ignasth1a: we are zapping all the existing local grants so we are starting fresh (if the default security policy can be called fresh)17:08
ignasdefault as in Zope3 security policy17:09
mgedminI wish launchpad were open source17:09
mgedminwe could take a look at their security policy17:09
faassensrichter: I ended up needing to change my physical containership model to suit the security policy. it made life simpler on the one hand, but I do wonder whether it wouldn't have been simpler still to just implement a new policy.17:09
srichterthe biggest issue for me was to understand the subtle difference between roles and groups; once that clicked, it was all downhill from there17:09
th1aThat might be helpful.17:09
faassenI believe there's also a ZC security policy hanging out somewhere.17:09
faassenin some module somewhere. I saw it once.17:09
srichterright, I remember that too17:09
srichterI think it's in a Sandbox17:10
faassenanyway, what I'd propose is a spike where we investigate replacing the security policy.17:10
faassenand then decide.17:10
faassenwhich way to go. Zope 3 security policy or new security policy.17:10
ignasfaassen: replacing adapters was less code that's why i and gintas spiked it17:10
th1aBefore we run out of time I need to understand what "data types" are and what the implications for my little table are.17:10
mgedminignas: how much time did your spike take?17:10
faassenanyway this new security policy would be more disruptive to the codebase, but it might be easier eventually to add new rules or tweak existing ones.17:11
faassenless interactions of different bits.17:11
faassenI ended up in the zope 3 security policy quite frequently with my debugger during document library develompent.17:11
faassenand that didn't exactly make things happier for me.17:11
ignasmgedmin: a couple of hours17:12
srichtermmh, I never debugged the security policy recently17:13
faassensrichter: I didn't debug the security policy either17:13
faassensrichter: it worked fine. it's just I tried to figure out why my permission/role story *didn't* work.17:13
th1aOK, so in making my table, I can assume we have a concept of "self?"17:13
faassensrichter: and I found myself there often enough to wonder whether it wouldn't have been simpler to just put in a custom policy.17:13
srichterbut then I know that I have to give everything a __parent__17:13
th1aAnd a certain amount of ownership based on containment?17:14
faassensrichter: yes, that's of course one area that was annoying, but I knew that too. :)17:14
faassensrichter: but it reminded me of zope 2. :)17:14
faassenhas a file policy.py17:14
faassenwhich is I think a custom security policy by ZC.17:14
th1aOK, let's talk about ME and my needs.17:15
ignasth1a: yes we have a concept of self17:15
faassenyes. :)17:15
faassensorry, th1a17:15
th1aSo I can have self permissions.17:15
faassenwith 'self' you mean what exactly?17:15
faassenI mean, the object owned by the current authenticated user?17:16
ignasth1a: yes17:16
th1aCan I see my own data?17:16
faassenand any objects inside it?17:16
srichterth1a: you can see your own data, but not necessarily edit it17:16
srichterth1a: also "own data" is ill-defined17:16
th1aI can't necessarily see it, based on the type of the data.17:16
faassenit depends on the granularity of the permissions.17:16
srichterth1a: I could imagine that a student cannot see all the data about him/her17:17
faassenif you want some data that can be seen and other data that can't.17:17
faassenone way to solve that is to split up the permissions. another way is to have granular ownership somehow.17:17
ignasth1a: if you are checking for permissions for your person object or other objects inside (calendar) you are granted the "self" role17:17
th1asrichter:  Of course.17:17
srichterfaassen: I would use fine-grained permissions17:17
ignasth1a: and then zcml decides whether the self role can read it or editi it or delete it17:17
faassenignas: you mean the permission declarations in ZCML?17:18
ignasfaassen: yes17:18
th1aOK, here's an important conceptual question.17:18
faassenignas: or the role to permission mapping?17:18
faassenignas: I guess the role to permission mapping plus the local permission declarations.17:18
th1aIn the current system, you've got a big grid, and every cell in that grid has to be defined.17:18
ignasfaassen: what local permission declarations ?17:18
faassen(I found it quite tricky to manage rather long lists of role to permission mappings in doclib)17:18
faassenignas: oops, non-local, in ZCML.17:19
faassenignas: brain not working. :)17:19
th1aBut in the new system, there are lots of possibilities that won't be negatively defined, that is, you don't state every relationship which does DON'T allow access, only those that do.17:19
th1aDoes that make sense?17:19
ignasth1a: kind of, i think so17:20
faassenanyway, the rules system (adapter or security policy doesn't matter) would implement the complicated stuff.17:20
faassenand that would consult the global configuration settings, done in the global config screen.17:20
th1aIn other words, when I make this grid, should I only indicate the allowed and optional grants and just leave the rest of them blank?17:20
faassenth1a: same difference, right? :)17:20
faassenth1a: I mean, if they're black they're not granted. :)17:21
faassenth1a: blank.17:21
th1aOK "data types"17:21
th1aDo I need to come up with a definitive list of these?17:21
faassenth1a: I think you're talking about the combinations that just don't make sense.17:21
faassenth1a: sometimes some combinations didn't make sense in your table.17:21
th1afaassen:  Yes.17:22
faassenth1a: like, 'add new people'17:22
faassenth1a: doesn't apply to the role 'owner' (or 'self' or whatever)17:22
faassenth1a: or 'view other people' also doesn't make sense to 'owner' role.17:22
ignasth1a: mapping roles in your chart to schooltool principals is easy - they are plainly roles17:22
ignasth1a: what is difficult is mapping "person name" to, IPersonContainer.__list__ etc.17:23
th1aSo on the chart, I have groups, relationships, etc. across the top.17:23
faassenth1a: but it does mean that someone given the self role can't add other people, I think. it's just that the self role isn't relevant in the rule checking at all at those points.17:23
th1aAnd each row is view, add/edit on a data type?17:23
faassenth1a: you mean what is difficult is figuring out how to translate his table to actual permissions on attributes in the system?17:24
ignasth1a: not really17:24
faassenth1a: sorry, that was for ignas.17:24
faassenignas: that was for you, sorry.17:24
ignasfaassen: YES exactly17:24
ignasthat's why someone will have to think what actions touch which parts of schooltool17:25
faassenin doclib we have the following approach.17:25
faassenwe have objects like User, Category, Document.17:25
faassenand then we have ViewUser, EditUser, ViewCategory, EditCategory, ViewDocument, EditDocument permissions.17:25
faassenand then we have roles (which can be local or global)17:26
faassenwhich get assigned these permissions. for instance, someone who is a DocumentOwner for a document.17:26
faassengets to do EditDocument17:26
srichteryep, that's what we did too17:26
faassenand the same as someone who is a Librarian for a Category, he also gets to do EditDocument for all documents in that category.17:26
faassenof course that means category needs to be a folder17:26
faassenand documnts need to be contained.17:26
faassenI mean, this is where I think it may be that we need a new security policy.17:26
faassenthat doesn't use containment relationships.17:27
faassento simplify matters.17:27
faassenthat's my intuitino.17:27
faassenbut that's the approach.17:27
faassenit might even be that we could do away with separate EditFoo and EditBar17:27
faassenand just have an Edit permission.17:27
faassenand a rule to figure out for a particular object type when you have Edit permission.17:27
ignasfaassen: i Foo Bar would be "data types" in my vocabulary17:28
faassenignas: okay, that's useful to know.17:28
ignaswhen you have a Self and you have an action "Edit person data"17:28
th1aWell, I think I know enough to have another crack at the table.  I'll send something out tonight.17:29
faassen(what I meant with my last lines is that in a new policy we could have less permissions and put some of the complexity in the rules, potentially. that's my intuition, I'm not making hard claims)17:29
ignasdata type is "PersonData", permission is editPersonData and grant is "allow role self to editPersonData "17:29
faassenit might be I see the grass being greener on the other side only. it's just complicated in general. I just want to remind people we have got that option, a new policy, and it's not amazingly complicated.17:30
ignasand that translates into require="schooltool.editPersonData" on IWritePerson interface or something like that17:30
faassenignas: anyway, I think you, I and srichter are more or less able to communicate about this stuff now, right?17:30
faassenignas: i..e I think I understand what you guys are saying.17:30
faassenignas: and I'm hoping you guys understand me. :)17:30
th1aI think we're on the same page.17:31
th1aThat's all the time we have...17:31
th1ahave a good week, folks.17:32
* th1a bangs the virtual bag of gravel.17:32
faassenI think that was valuable.17:32
th1asrichter:  Do you want to plan a f2f meeting yet?17:32
algaIn Russia, today is the Victory Day17:32
faassenalga: ww2?17:32
faassenalga: we had liberation day last friday. :)17:33
faassenalga: we got liberated, Russia got victory. though in the end I suspect the NL was better off for a while.17:33
algaOn May 9 the red banner was flown above Reichstag17:33
faassenalga: anyway, what about it?17:34
th1aThere were what, 300,000 Russian casualties in the Battle of Berlin?17:34
srichterth1a: no, I think this would be premature17:34
th1asrichter:  OK.17:34
faassenalga: you just wanted to inform us of it? :)17:35
algafaassen: I just thought I'd need to reread the log sometime later, and looked at the date...17:35
faassenalga: oh, okay. :)17:35
faassenalga: the lesson is: Don't attack Russia.17:35
faassenalga: Just Don't Do It.17:35
faassenalga: it's just too big.17:36
faassenalga: and it gets too cold in the winter.17:36
th1aJust take warm clothing.17:36
faassenNapoleon tried and Hitler tried, it just won't work.17:36
algaHeh...  Americans ;-)17:36
faassenlet's hope we don't have anyone else trying. :)17:36
ignasyep, or Russia will liberate even more countries17:37
faassenuh oh.17:37
th1aI met Khrushchev's son last month.17:37
faassenbeing liberated by russia isn't exactly the most pleasant thing.17:37
th1aAt the frame shop.17:37
faassenth1a: I didn't meet Mark at linuxtag. he had a keynote saturday but I was traveling home then.17:37
faassenth1a: frame shop?17:37
th1aGetting a picture framed.17:37
faassenth1a: and you just ran into Khrushchev's son?17:38
th1aWhich happened to be a picture from Russia in 1905.17:38
th1aWeird, huh?17:38
faassenth1a: he said, hi! get your picture framed too? I'm Hrushcev's son.17:38
faassenoh, that's weird indeed17:38
faassenhe's in the US?17:38
mgedmin"Never get involved in a land war in Asia"17:38
th1aThe frame shop owner introduced us.17:38
faassenmgedmin: we can generalize that. :)17:38
faassenmgedmin: "don't get involved in wars anywhere" :)17:38
th1aUnless you're Asian.17:38
faassenmgedmin: "especially not Iraq or Russia"17:38
faassenmgedmin: "or Vietnam"17:39
th1afaassen:  Actually tracking Mark down at a conference takes some effort.17:39
faassenmgedmin: "or Indonesia" (the dutch did that after WW2.. spoke to a veteran grand uncle a few weeks ago)17:39
faassenmgedmin: (was a huge mess)17:39
*** ignas has quit IRC17:43
jintyAfganistan seems to also have been fun for quite a few countries:)17:44
th1aThat's why we just bribed them all this time.17:44
th1aBribes + air support.17:45
th1aUnfortunately, it only worked once.17:46
* jinty for a moment though Khrushchev == Kutuzov17:46
th1aAnd only kind of half-worked since Bin Laden escaped.17:46
jintythe general that beat off napoleon17:47
jintythe downside of just scan reading;)17:47
*** ignas has joined #schooltool17:48
jintywhen buying weapons for people, be careful that they don't use them against you later...17:48
th1aAnd don't teach them to fly airliners.17:49
ignasjinty: depends on how you define the "you" bit ;)17:49
jintyyeah, I know I shouldn't give countries personalities;)17:50
jintythey're a bit more schitzophrenic than that17:51
th1aBlast first England.17:51
* jinty wants a spell checker for xchat17:51
*** Aiste has quit IRC17:52
*** Aiste has joined #schooltool17:53
*** alga_ has joined #SchoolTool17:53
*** alga has quit IRC18:01
*** alga_ has quit IRC18:18
*** jinty has quit IRC18:44
*** Aiste_ has joined #schooltool18:53
faassenth1a: oh by the way, I released the document library last week.18:56
th1afaassen:  Yes, I've been meaning to blog about it.19:02
*** Aiste has quit IRC19:15
*** Aiste_ is now known as Aiste19:17
th1afaassen:  Am I supposed to be able to SEE any changes from the demographics work, or is it all still under the hood?19:18
th1aAiste:  So I should say, "theres this conference, and there's this guy alga, and I'm inviting him to the conference"?19:19
Aisteyeah, something along those lines19:20
faassenth1a: it's still mostly under the hood, but you can do person/nameinfo/edit.html19:22
faassenth1a: I shall work on exposing more now. :)19:22
th1aAh.  It isn't linked up.19:22
faassenth1a: right.19:23
*** ignas has quit IRC19:25
*** ignas_ has joined #schooltool19:25
povbot/svn/commits: * faassen committed revision 6028:19:49
povbot/svn/commits: Add simple display form based on formlib.19:49
*** faassen has quit IRC19:52
*** alga has joined #SchoolTool21:12
*** thisfred has quit IRC21:21
ignas_th1a: you still there ?21:43
th1aI am.21:43
ignas_do we want booking conflicts for instructors indicate that the person is busy being a learner ?21:43
ignas_PersonA is schedulet as an instructor for SectionH21:45
ignas_i am looking at the learner view for SectionH21:45
ignas_do i see PersonA marked as Busy/Conflicting ?21:45
*** Aiste has quit IRC21:45
th1aThat's a whole new story in my opinion.21:46
th1aI mean, what are you doing that triggers this conflict?21:47
ignas_th1a: well - i am working on conflict display in resource booking for sections21:48
ignas_the same view is used for "booking" Persons as learners and "Booking" persons as instructors21:48
th1aOh, l guess you were saying that the two share code.21:48
ignas_so it's like 10 lines of code and a nice functionality to have21:49
th1aI'm a little confused, but it sounds like it is worth doing.21:50
ignas_so - do we want to show only conflicts with other sections taught at the same time as this one, or should we show conflicts with sections being "attended/learned" too21:51
ignas_pick one21:52
ignas_the actual difference would be21:52
ignas_when you go to select an instructor - you see a list of all persons (paginated)21:53
ignas_and you either see21:54
ignas_Teacher1 - is busy on that time teaching section C21:54
ignas_Teacher2 - is busy on that time teaching section D21:54
ignas_Stuent1 - is not busy21:54
ignas_Stuent2 - is not busy21:54
ignas_Student1 - is busy on that time attending section C21:55
ignas_Student2 - is busy on that time attending section D21:55
th1aWhat am I trying to accomplish when I see this?21:55
ignas_pick a teacher for the section21:56
ignas_you will see only names though not Student1, Teacher221:56
*** mgedmin has quit IRC22:02
th1aignas_:  I can't really picture this.22:04
th1aJust pick one.22:04
ignas_ok :)22:04
*** ignas_ has quit IRC22:11
*** Aiste has joined #schooltool22:23
*** alga has quit IRC23:24
*** Gwynn has quit IRC23:47

Generated by 2.15.1 by Marius Gedminas - find it at!