| *** didymo has joined #schooltool | 02:52 | |
| *** Hwyvar has quit IRC | 03:30 | |
| *** Gwynn has joined #schooltool | 05:24 | |
| *** jinty has joined #schooltool | 05:42 | |
| *** strichter has joined #schooltool | 07:02 | |
| *** srichter has quit IRC | 07:25 | |
| *** Aiste has quit IRC | 12:06 | |
| *** Aiste has joined #schooltool | 12:29 | |
| *** faassen has joined #schooltool | 12:58 | |
| *** thisfred has joined #schooltool | 13:13 | |
| *** mgedmin has joined #schooltool | 13:37 | |
| *** ignas has joined #schooltool | 13:39 | |
| *** alga has joined #SchoolTool | 13:57 | |
| *** strichter is now known as srichter | 14:03 | |
| *** didymo has quit IRC | 14:17 | |
| *** srichter has quit IRC | 14:32 | |
| povbot | /svn/commits: * ignas committed revision 6023: | 14:41 |
|---|---|---|
| povbot | /svn/commits: Refactored TimetableSetup view a bit. | 14:41 |
| *** srichter has joined #schooltool | 14:43 | |
| *** srichter has joined #schooltool | 15:02 | |
| *** faassen has quit IRC | 15:27 | |
| *** faassen has joined #schooltool | 15: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 bothered | 15:41 |
| povbot | /svn/commits: by demographics related stuff. | 15:41 |
| povbot | /svn/commits: * prepare the ground for pluggable demographics. If you want a different | 15: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 the | 15: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 here | 16:29 | |
| * faassen is here. | 16:30 | |
| th1a | srichter: How are you feeling? | 16:30 |
| srichter | crappy, to be honest | 16:30 |
| faassen | srichter: what's wrong? | 16:30 |
| th1a | Bird flu. | 16:30 |
| srichter | I am still feeling dizzy and conjested from the pressure on my ear drums | 16:30 |
| faassen | srichter: oh ick | 16:30 |
| * mgedmin is here | 16:31 | |
| faassen | th1a: joking I hope! | 16:31 |
| th1a | He brought it to the US. | 16:31 |
| srichter | if so, I would be the first survivor ;-) | 16:31 |
| th1a | It is all over the news. | 16:31 |
| srichter | he he | 16:31 |
| faassen | Stephan Richter, Zope 3 release manager, downed by bird flu! | 16:31 |
| faassen | Extra extra!@ | 16:31 |
| th1a | srichter dooms America. Everyone blames him! | 16:31 |
| srichter | LOL | 16:31 |
| faassen | Bush sez: srichter doomed Amurrica! | 16:31 |
| mgedmin | the only known survivor used Zope 3! | 16:31 |
| mgedmin | use Zope 3 to be safe! | 16:31 |
| * faassen laughs. | 16:31 | |
| * faassen watches hordes of PHP hackers make the transition. | 16:32 | |
| srichter | LOL | 16:32 |
| faassen | oh no! | 16:32 |
| th1a | OK, so we have lots of access control discussion to get to. | 16:32 |
| ignas | hi | 16:32 |
| faassen | ok. :) | 16:32 |
| th1a | Let's just have some *quick* updates. | 16:32 |
| faassen | about non-access control issues? | 16:33 |
| th1a | Just where you are, what you're planning. | 16:33 |
| faassen | ok. | 16:33 |
| th1a | faassen: Would you like to start? | 16:33 |
| faassen | yes. last week was not very productive due to LinuxTag and training new employee here | 16:33 |
| faassen | but I did some work the result of which is checked in today. | 16:33 |
| faassen | basically I separated the demographics work I did before out from schooltool.person and put it into its own person. | 16:34 |
| faassen | then 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 |
| faassen | it 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 |
| faassen | after some discussion with mgedmin I worked around that. | 16:34 |
| faassen | so now if you svn up your schooltool, the person objects are taken over by the demographics package. | 16:35 |
| faassen | the idea is that future customizations of schooltool could provide their own demographics packages. | 16:35 |
| faassen | for particular schools or countries or whatnot. | 16:35 |
| faassen | but for now I'll just keep on expanding it. | 16:35 |
| th1a | OK. | 16:36 |
| th1a | faassen: Don't forget we need to finish reorganizing your proposal. | 16:36 |
| th1a | Are you going to have much time for ST the rest of the week? | 16:36 |
| th1a | We'll skip srichter and I'm going to go visit him as soon as he's in working order. | 16:37 |
| srichter | I 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 |
| faassen | I 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 | |
| th1a | OK. Thanks faassen. | 16:38 |
| faassen | th1a: reorganizing the proposal, I need to know who does what. | 16:38 |
| th1a | On to POV. | 16:38 |
| faassen | th1a: I thought Kit had a conversation with you but if you want something more.. | 16:38 |
| faassen | th1a: then you should let us know what exactly you want to see. | 16:38 |
| ignas | we were working on the proposal | 16:39 |
| th1a | faassen: OK, I'll pick up the thread. | 16:39 |
| faassen | th1a: I was hoping Kit had worked it out with you already and I think Kit was assuming that. | 16:39 |
| ignas | spiking ACL | 16:39 |
| ignas | fixed a couple of bugs | 16:39 |
| ignas | and are continuing the struggle with conflict resolution for resources | 16:39 |
| th1a | OK. | 16:40 |
| ignas | th1a: did you get the draft ? | 16:40 |
| th1a | Thanks ignas. | 16:40 |
| th1a | Draft? | 16:40 |
| th1a | Proposal? | 16:40 |
| ignas | yes | 16:40 |
| th1a | Hm... I didn't see it. | 16:41 |
| th1a | When did you send it? | 16:41 |
| alga | To: Tom Hoffman <tom.hoffman@gmail.com>, all@pov.lt | 16:41 |
| alga | Date: Tue, 9 May 2006 14:13:00 +0300 | 16:41 |
| th1a | Found it. | 16:41 |
| th1a | Well, Mark was pretty definitive about the SchoolBell issue in his email, so I guess we'll be striking that item. | 16:42 |
| ignas | striking as in ? | 16:43 |
| th1a | Can you send the access control section to the dev list while I read over it. | 16:43 |
| th1a | As in not doing it. | 16:43 |
| ignas | oh | 16:43 |
| th1a | Although the access control part of the proposal doesn't really make sense, since the part I wrote is now obselete, I think. | 16:44 |
| ignas | probably | 16:45 |
| ignas | and the todo list is not very informative | 16:45 |
| ignas | the high level plan is implementing a couple of IPrincipalRoleMap adapters | 16:45 |
| ignas | that would hook up needed Roles to principals depending on the context object | 16:45 |
| th1a | How many nuts in a day? | 16:46 |
| ignas | a productive day is estimated to be ~4 nuts | 16:46 |
| ignas | 1 nut -> 1.5 hour | 16:46 |
| th1a | OK. | 16:47 |
| th1a | All right, let's go through this. | 16:47 |
| th1a | So we're proposing to stop using local grants. | 16:47 |
| th1a | Entirely. | 16:47 |
| faassen | (do I understand that schoolbell is out, by the way) | 16:48 |
| faassen | I mean, I am trying to interpret the schoolbell bit. | 16:48 |
| ignas | i think we are not going to do schoolbell extraction yet | 16:48 |
| th1a | Yes, I'm certainly not going to send Mark an invoice for it now. | 16:48 |
| faassen | ok. | 16:48 |
| faassen | no schoolbell extraction, ok. | 16:48 |
| faassen | just wanted to make sure I understood right. | 16:48 |
| faassen | a local grant is a local permission grant, right? | 16:48 |
| th1a | Right. | 16:49 |
| th1a | What's the correct Zope 3 terminology for a new permissions system? | 16:49 |
| ignas | th1a: by the way - i think we can add an option to hide/show individual calendars to public without using local grants | 16:49 |
| th1a | We need to write a new... ? | 16:50 |
| faassen | well, I understood from the words above that you won't make a new security policy. | 16:50 |
| faassen | but that it'll be done with a number of overridden adapters. | 16:50 |
| faassen | but the word would be 'security policy' | 16:50 |
| th1a | ignas didn't actually change the narrative part, so it is completely obselete and misleading. | 16:50 |
| th1a | Just look at the bullet points. | 16:51 |
| faassen | I didn't read that text. | 16:51 |
| faassen | I just mean this that ignas said on irc: the high level plan is implementing a couple of IPrincipalRoleMap adapters | 16:51 |
| faassen | this implies that this implementation uses the default Zope 3 security policy. | 16:51 |
| faassen | but changes the way roles are determined for individual objects. | 16:52 |
| th1a | Well, this is my question. | 16:52 |
| th1a | Are we writing a new security policy? | 16:52 |
| th1a | I'm a little unclear on the scope of our ambition. | 16:53 |
| faassen | from what I just understood, the answer is no new security policy is written. | 16:53 |
| faassen | but instead the current security policy is used and adapters are used to change the way roles are determined. | 16:53 |
| faassen | note that writing a new security policy in Zope 3 is not hard technically. | 16:54 |
| th1a | ignas? | 16:54 |
| faassen | of 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 |
| ignas | faasen is right | 16:54 |
| ignas | the rules would be like "does this object has the principal in it's parents" (the self permission) | 16:55 |
| th1a | So there are roles in the default Zope security policy, but it isn't evident in the UI? | 16:55 |
| faassen | the default Zope security policy has roles. | 16:55 |
| ignas | or even "has the parent of this calendar a *public* bit set in his preferences" | 16:56 |
| faassen | I'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 |
| faassen | I may be wrong of course, but that's my suspicion. | 16:57 |
| th1a | So 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 |
| th1a | As opposed to, completely eliminating the idea of local grants? | 16:57 |
| faassen | as far a I understand, people get permissions to objects based on three possibilities. | 16:57 |
| ignas | faassen: at the moment i think that rules will be simple enough, the "assign permissions to objects views" will be more difficult one | 16:57 |
| faassen | they're globally given this permission (perhaps because they're in a group or have a role, or whatever) | 16:57 |
| faassen | they'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 |
| ignas | s/objects views/objects and views/ | 16:58 |
| faassen | and thirdly, they get permissions to an object becasue it has certain relations with the object I own. | 16:58 |
| ignas | faassen: true | 16:59 |
| faassen | I meam, I get permissions because my person object has certain relations with the object I own. | 16:59 |
| faassen | so there is no local permission mapping at all. | 16:59 |
| faassen | but there *is* local information, namely the ownership concept | 16:59 |
| faassen | and the relationship concept. | 16:59 |
| faassen | but this is integral to the system anyway. | 16:59 |
| faassen | ignas: what do you mean by 'assign permissions to objects views"? I thought that went away. | 16:59 |
| faassen | ignas: but you say it'll be difficult. | 17:00 |
| ignas | faassen: logical permissions like - who can do what on what SchoolTool objects | 17:00 |
| ignas | what objects/views are Personal Data | 17:00 |
| ignas | etc. | 17:00 |
| ignas | yes, 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 runtime | 17:00 |
| faassen | ignas: I don't understand that. | 17:00 |
| faassen | ignas: why does defining something as personal data need to be configured? | 17:01 |
| ignas | faassen: we have such things as "person names", "person info" in the permission table made by Tom | 17:01 |
| faassen | ignas: 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 |
| faassen | ignas: for views, you'd just give them permissions, right? | 17:01 |
| ignas | faassen: but this is not directly mapping to SchoolTool Views and Objects, and the mapping will have to get crafted by someone | 17:01 |
| faassen | ignas: I mean, nothing effectively changes to the views, though we may change which permissions are required a bit here and there. | 17:02 |
| faassen | ignas: so do you mean the global configuration screen? | 17:02 |
| faassen | I'm trying to get a hold of this concept.. | 17:02 |
| faassen | there'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 |
| faassen | like "teachers may access the demographic data of their students", say. | 17:03 |
| faassen | you can say yes or not. | 17:03 |
| faassen | no | 17:03 |
| ignas | yes | 17:03 |
| faassen | that doesn't sound like a very complicated story to me. | 17:03 |
| th1a | I think we need to define the "data types" a bit more. | 17:03 |
| faassen | but you're implying that this is complicated. | 17:03 |
| faassen | so I'm worrying I'm missing something somewhere. | 17:03 |
| ignas | faassen: can you list all the views and objects that are demographic data ? that are Person info ? | 17:03 |
| srichter | btw, I have made some great experience with a project in this regard in the last weeks too | 17:04 |
| ignas | all the interfaces | 17:04 |
| faassen | ignas: wouldn't that be a matter of permissions and ownership? | 17:04 |
| srichter | I think you can define well global permissions and assign them globally the roles | 17:04 |
| faassen | srichter: great experience with what exactly? | 17:04 |
| srichter | but what you would have to do is split several roles into two | 17:04 |
| srichter | how to set up permissions, roles and groups for an application | 17:05 |
| faassen | imagine we have just schooltool.view and schooltool.edit | 17:05 |
| srichter | for example, a teacher is not just a teacher in general, but you also need teacherOfClass | 17:05 |
| faassen | then our rules system can determine "oh, this person is the owner of the object, so schooltool.view is allowed" | 17:05 |
| srichter | right | 17:06 |
| faassen | or, "oh, this person is a global school administrator, so they get schooltool.edit" | 17:06 |
| srichter | yep | 17:06 |
| faassen | and even "oh, this person is the teacher of a class in which the student is participating, so they get schooltool.view" | 17:06 |
| srichter | so teacherOfClass would be the owner role for a teacher of a class | 17:06 |
| ignas | more like - "oh this person is teaching the class let's give him teacherOfClass role" | 17:06 |
| faassen | that's if you use the zope 3 security policy. | 17:06 |
| ignas | when accesing the class object | 17:06 |
| faassen | I'm still not convinced using the default security policy and using roles is actually simplifying anything. | 17:07 |
| faassen | it might be simpler to just codify the rules in a single security policy. | 17:07 |
| faassen | I may be wrong, but I messed with this stuff in document library. | 17:07 |
| faassen | and in the end I was on the fence. | 17:07 |
| faassen | I didn't use a custom security policy. | 17:07 |
| faassen | and that made life easier in the beginning. | 17:07 |
| th1a | Yes, that's what I wonder, too. | 17:07 |
| faassen | but I had to struggle in places too, especially when having to worry about __parent__ being there, etc. | 17:07 |
| faassen | which the normal zope 3 security policy needs. | 17:08 |
| srichter | actually, my experience was very positive with the default policy | 17:08 |
| th1a | It seems like we're changing everything around anyhow. Starting fresh might be cleaner. | 17:08 |
| faassen | and in the end, I wondered what an alternate history would've been like where I'd implemented a new security policy. | 17:08 |
| faassen | I don't know for sure, but it might've been easier. | 17:08 |
| faassen | srichter: I had a mixed experience with the default policy. I had reasonably complex rules including groups and ownership. | 17:08 |
| srichter | yep, I had that too | 17:08 |
| ignas | th1a: we are zapping all the existing local grants so we are starting fresh (if the default security policy can be called fresh) | 17:08 |
| ignas | default as in Zope3 security policy | 17:09 |
| mgedmin | I wish launchpad were open source | 17:09 |
| mgedmin | we could take a look at their security policy | 17:09 |
| faassen | srichter: 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 |
| srichter | the biggest issue for me was to understand the subtle difference between roles and groups; once that clicked, it was all downhill from there | 17:09 |
| th1a | That might be helpful. | 17:09 |
| faassen | I believe there's also a ZC security policy hanging out somewhere. | 17:09 |
| faassen | in some module somewhere. I saw it once. | 17:09 |
| srichter | right, I remember that too | 17:09 |
| srichter | I think it's in a Sandbox | 17:10 |
| faassen | anyway, what I'd propose is a spike where we investigate replacing the security policy. | 17:10 |
| faassen | and then decide. | 17:10 |
| faassen | which way to go. Zope 3 security policy or new security policy. | 17:10 |
| ignas | faassen: replacing adapters was less code that's why i and gintas spiked it | 17:10 |
| th1a | Before we run out of time I need to understand what "data types" are and what the implications for my little table are. | 17:10 |
| mgedmin | ignas: how much time did your spike take? | 17:10 |
| faassen | anyway 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 |
| faassen | less interactions of different bits. | 17:11 |
| faassen | I ended up in the zope 3 security policy quite frequently with my debugger during document library develompent. | 17:11 |
| faassen | and that didn't exactly make things happier for me. | 17:11 |
| ignas | mgedmin: a couple of hours | 17:12 |
| srichter | mmh, I never debugged the security policy recently | 17:13 |
| faassen | srichter: I didn't debug the security policy either | 17:13 |
| faassen | srichter: it worked fine. it's just I tried to figure out why my permission/role story *didn't* work. | 17:13 |
| th1a | OK, so in making my table, I can assume we have a concept of "self?" | 17:13 |
| faassen | srichter: 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 |
| srichter | but then I know that I have to give everything a __parent__ | 17:13 |
| th1a | And a certain amount of ownership based on containment? | 17:14 |
| faassen | srichter: yes, that's of course one area that was annoying, but I knew that too. :) | 17:14 |
| faassen | srichter: but it reminded me of zope 2. :) | 17:14 |
| faassen | http://svn.zope.org/zc.sharing/trunk/src/zc/sharing/ | 17:14 |
| faassen | has a file policy.py | 17:14 |
| faassen | which is I think a custom security policy by ZC. | 17:14 |
| th1a | OK, let's talk about ME and my needs. | 17:15 |
| ignas | th1a: yes we have a concept of self | 17:15 |
| faassen | yes. :) | 17:15 |
| faassen | sorry, th1a | 17:15 |
| th1a | ;-) | 17:15 |
| th1a | So I can have self permissions. | 17:15 |
| th1a | Ownership? | 17:15 |
| faassen | with 'self' you mean what exactly? | 17:15 |
| faassen | I mean, the object owned by the current authenticated user? | 17:16 |
| ignas | th1a: yes | 17:16 |
| th1a | Can I see my own data? | 17:16 |
| faassen | and any objects inside it? | 17:16 |
| srichter | th1a: you can see your own data, but not necessarily edit it | 17:16 |
| srichter | th1a: also "own data" is ill-defined | 17:16 |
| th1a | I can't necessarily see it, based on the type of the data. | 17:16 |
| faassen | it depends on the granularity of the permissions. | 17:16 |
| srichter | th1a: I could imagine that a student cannot see all the data about him/her | 17:17 |
| faassen | if you want some data that can be seen and other data that can't. | 17:17 |
| faassen | one way to solve that is to split up the permissions. another way is to have granular ownership somehow. | 17:17 |
| ignas | th1a: if you are checking for permissions for your person object or other objects inside (calendar) you are granted the "self" role | 17:17 |
| th1a | srichter: Of course. | 17:17 |
| srichter | faassen: I would use fine-grained permissions | 17:17 |
| ignas | th1a: and then zcml decides whether the self role can read it or editi it or delete it | 17:17 |
| faassen | ignas: you mean the permission declarations in ZCML? | 17:18 |
| ignas | faassen: yes | 17:18 |
| th1a | OK, here's an important conceptual question. | 17:18 |
| faassen | ignas: or the role to permission mapping? | 17:18 |
| faassen | ignas: I guess the role to permission mapping plus the local permission declarations. | 17:18 |
| th1a | In the current system, you've got a big grid, and every cell in that grid has to be defined. | 17:18 |
| ignas | faassen: 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 |
| faassen | ignas: oops, non-local, in ZCML. | 17:19 |
| faassen | ignas: brain not working. :) | 17:19 |
| th1a | But 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 |
| th1a | Does that make sense? | 17:19 |
| ignas | th1a: kind of, i think so | 17:20 |
| faassen | anyway, the rules system (adapter or security policy doesn't matter) would implement the complicated stuff. | 17:20 |
| faassen | and that would consult the global configuration settings, done in the global config screen. | 17:20 |
| faassen | right? | 17:20 |
| ignas | yes | 17:20 |
| th1a | In 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 |
| faassen | th1a: same difference, right? :) | 17:20 |
| faassen | th1a: I mean, if they're black they're not granted. :) | 17:21 |
| faassen | th1a: blank. | 17:21 |
| th1a | Hm... | 17:21 |
| th1a | OK "data types" | 17:21 |
| th1a | Do I need to come up with a definitive list of these? | 17:21 |
| faassen | th1a: I think you're talking about the combinations that just don't make sense. | 17:21 |
| faassen | th1a: sometimes some combinations didn't make sense in your table. | 17:21 |
| th1a | faassen: Yes. | 17:22 |
| faassen | th1a: like, 'add new people' | 17:22 |
| faassen | th1a: doesn't apply to the role 'owner' (or 'self' or whatever) | 17:22 |
| faassen | th1a: or 'view other people' also doesn't make sense to 'owner' role. | 17:22 |
| ignas | th1a: mapping roles in your chart to schooltool principals is easy - they are plainly roles | 17:22 |
| ignas | th1a: what is difficult is mapping "person name" to IPerson.name, IPersonContainer.__list__ etc. | 17:23 |
| th1a | So on the chart, I have groups, relationships, etc. across the top. | 17:23 |
| faassen | th1a: 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 |
| th1a | And each row is view, add/edit on a data type? | 17:23 |
| faassen | th1a: you mean what is difficult is figuring out how to translate his table to actual permissions on attributes in the system? | 17:24 |
| ignas | th1a: not really | 17:24 |
| faassen | th1a: sorry, that was for ignas. | 17:24 |
| faassen | ignas: that was for you, sorry. | 17:24 |
| ignas | faassen: YES exactly | 17:24 |
| ignas | that's why someone will have to think what actions touch which parts of schooltool | 17:25 |
| faassen | in doclib we have the following approach. | 17:25 |
| faassen | we have objects like User, Category, Document. | 17:25 |
| faassen | and then we have ViewUser, EditUser, ViewCategory, EditCategory, ViewDocument, EditDocument permissions. | 17:25 |
| faassen | and then we have roles (which can be local or global) | 17:26 |
| faassen | which get assigned these permissions. for instance, someone who is a DocumentOwner for a document. | 17:26 |
| faassen | gets to do EditDocument | 17:26 |
| srichter | yep, that's what we did too | 17:26 |
| faassen | and 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 |
| faassen | of course that means category needs to be a folder | 17:26 |
| faassen | and documnts need to be contained. | 17:26 |
| faassen | I mean, this is where I think it may be that we need a new security policy. | 17:26 |
| faassen | that doesn't use containment relationships. | 17:27 |
| faassen | to simplify matters. | 17:27 |
| faassen | that's my intuitino. | 17:27 |
| faassen | but that's the approach. | 17:27 |
| faassen | it might even be that we could do away with separate EditFoo and EditBar | 17:27 |
| faassen | and just have an Edit permission. | 17:27 |
| faassen | and a rule to figure out for a particular object type when you have Edit permission. | 17:27 |
| ignas | faassen: i Foo Bar would be "data types" in my vocabulary | 17:28 |
| faassen | ignas: okay, that's useful to know. | 17:28 |
| ignas | when you have a Self and you have an action "Edit person data" | 17:28 |
| th1a | Well, 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 |
| ignas | data type is "PersonData", permission is editPersonData and grant is "allow role self to editPersonData " | 17:29 |
| faassen | it 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 |
| ignas | and that translates into require="schooltool.editPersonData" on IWritePerson interface or something like that | 17:30 |
| faassen | ignas: anyway, I think you, I and srichter are more or less able to communicate about this stuff now, right? | 17:30 |
| faassen | ignas: i..e I think I understand what you guys are saying. | 17:30 |
| faassen | ignas: and I'm hoping you guys understand me. :) | 17:30 |
| ignas | :) | 17:31 |
| th1a | I think we're on the same page. | 17:31 |
| th1a | That's all the time we have... | 17:31 |
| th1a | have a good week, folks. | 17:32 |
| faassen | okay. | 17:32 |
| * th1a bangs the virtual bag of gravel. | 17:32 | |
| faassen | I think that was valuable. | 17:32 |
| th1a | Yes. | 17:32 |
| th1a | srichter: Do you want to plan a f2f meeting yet? | 17:32 |
| alga | In Russia, today is the Victory Day | 17:32 |
| faassen | alga: ww2? | 17:32 |
| alga | yep | 17:32 |
| faassen | alga: we had liberation day last friday. :) | 17:33 |
| faassen | alga: we got liberated, Russia got victory. though in the end I suspect the NL was better off for a while. | 17:33 |
| alga | On May 9 the red banner was flown above Reichstag | 17:33 |
| faassen | alga: anyway, what about it? | 17:34 |
| th1a | There were what, 300,000 Russian casualties in the Battle of Berlin? | 17:34 |
| srichter | th1a: no, I think this would be premature | 17:34 |
| th1a | srichter: OK. | 17:34 |
| faassen | alga: you just wanted to inform us of it? :) | 17:35 |
| alga | faassen: I just thought I'd need to reread the log sometime later, and looked at the date... | 17:35 |
| faassen | alga: oh, okay. :) | 17:35 |
| faassen | alga: the lesson is: Don't attack Russia. | 17:35 |
| faassen | alga: Just Don't Do It. | 17:35 |
| faassen | alga: it's just too big. | 17:36 |
| faassen | alga: and it gets too cold in the winter. | 17:36 |
| th1a | Just take warm clothing. | 17:36 |
| faassen | Napoleon tried and Hitler tried, it just won't work. | 17:36 |
| alga | Heh... Americans ;-) | 17:36 |
| faassen | let's hope we don't have anyone else trying. :) | 17:36 |
| ignas | yep, or Russia will liberate even more countries | 17:37 |
| faassen | uh oh. | 17:37 |
| th1a | I met Khrushchev's son last month. | 17:37 |
| faassen | being liberated by russia isn't exactly the most pleasant thing. | 17:37 |
| th1a | At the frame shop. | 17:37 |
| faassen | th1a: I didn't meet Mark at linuxtag. he had a keynote saturday but I was traveling home then. | 17:37 |
| faassen | th1a: frame shop? | 17:37 |
| th1a | Getting a picture framed. | 17:37 |
| faassen | th1a: and you just ran into Khrushchev's son? | 17:38 |
| th1a | Which happened to be a picture from Russia in 1905. | 17:38 |
| th1a | Weird, huh? | 17:38 |
| faassen | th1a: he said, hi! get your picture framed too? I'm Hrushcev's son. | 17:38 |
| faassen | oh, that's weird indeed | 17:38 |
| faassen | he's in the US? | 17:38 |
| mgedmin | "Never get involved in a land war in Asia" | 17:38 |
| th1a | The frame shop owner introduced us. | 17:38 |
| faassen | mgedmin: we can generalize that. :) | 17:38 |
| faassen | mgedmin: "don't get involved in wars anywhere" :) | 17:38 |
| th1a | Unless you're Asian. | 17:38 |
| faassen | mgedmin: "especially not Iraq or Russia" | 17:38 |
| faassen | mgedmin: "or Vietnam" | 17:39 |
| th1a | faassen: Actually tracking Mark down at a conference takes some effort. | 17:39 |
| faassen | mgedmin: "or Indonesia" (the dutch did that after WW2.. spoke to a veteran grand uncle a few weeks ago) | 17:39 |
| faassen | mgedmin: (was a huge mess) | 17:39 |
| *** ignas has quit IRC | 17:43 | |
| jinty | Afganistan seems to also have been fun for quite a few countries:) | 17:44 |
| th1a | That's why we just bribed them all this time. | 17:44 |
| th1a | Bribes + air support. | 17:45 |
| th1a | Unfortunately, it only worked once. | 17:46 |
| * jinty for a moment though Khrushchev == Kutuzov | 17:46 | |
| th1a | And only kind of half-worked since Bin Laden escaped. | 17:46 |
| jinty | thought | 17:46 |
| th1a | Kutusov? | 17:46 |
| th1a | Kutuzov? | 17:46 |
| jinty | the general that beat off napoleon | 17:47 |
| th1a | Ah. | 17:47 |
| jinty | the downside of just scan reading;) | 17:47 |
| *** ignas has joined #schooltool | 17:48 | |
| jinty | when buying weapons for people, be careful that they don't use them against you later... | 17:48 |
| th1a | And don't teach them to fly airliners. | 17:49 |
| ignas | jinty: depends on how you define the "you" bit ;) | 17:49 |
| jinty | yeah, I know I shouldn't give countries personalities;) | 17:50 |
| jinty | they're a bit more schitzophrenic than that | 17:51 |
| th1a | Blast first England. | 17:51 |
| * jinty wants a spell checker for xchat | 17:51 | |
| *** Aiste has quit IRC | 17:52 | |
| *** Aiste has joined #schooltool | 17:53 | |
| *** alga_ has joined #SchoolTool | 17:53 | |
| *** alga has quit IRC | 18:01 | |
| *** alga_ has quit IRC | 18:18 | |
| *** jinty has quit IRC | 18:44 | |
| *** Aiste_ has joined #schooltool | 18:53 | |
| faassen | th1a: oh by the way, I released the document library last week. | 18:56 |
| faassen | th1a: http://www.infrae.com/newsitems/documentlibrary_1_1b | 18:57 |
| th1a | faassen: Yes, I've been meaning to blog about it. | 19:02 |
| *** Aiste has quit IRC | 19:15 | |
| *** Aiste_ is now known as Aiste | 19:17 | |
| th1a | faassen: Am I supposed to be able to SEE any changes from the demographics work, or is it all still under the hood? | 19:18 |
| th1a | Aiste: So I should say, "theres this conference, and there's this guy alga, and I'm inviting him to the conference"? | 19:19 |
| Aiste | yeah, something along those lines | 19:20 |
| th1a | OK. | 19:20 |
| faassen | th1a: it's still mostly under the hood, but you can do person/nameinfo/edit.html | 19:22 |
| faassen | th1a: I shall work on exposing more now. :) | 19:22 |
| th1a | Ah. It isn't linked up. | 19:22 |
| faassen | th1a: right. | 19:23 |
| *** ignas has quit IRC | 19:25 | |
| *** ignas_ has joined #schooltool | 19: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 IRC | 19:52 | |
| *** alga has joined #SchoolTool | 21:12 | |
| *** thisfred has quit IRC | 21:21 | |
| ignas_ | th1a: you still there ? | 21:43 |
| th1a | I am. | 21:43 |
| ignas_ | do we want booking conflicts for instructors indicate that the person is busy being a learner ? | 21:43 |
| th1a | Hm? | 21:44 |
| ignas_ | PersonA is schedulet as an instructor for SectionH | 21:45 |
| ignas_ | i am looking at the learner view for SectionH | 21:45 |
| ignas_ | do i see PersonA marked as Busy/Conflicting ? | 21:45 |
| *** Aiste has quit IRC | 21:45 | |
| th1a | That's a whole new story in my opinion. | 21:46 |
| th1a | I mean, what are you doing that triggers this conflict? | 21:47 |
| ignas_ | th1a: well - i am working on conflict display in resource booking for sections | 21:48 |
| ignas_ | the same view is used for "booking" Persons as learners and "Booking" persons as instructors | 21:48 |
| th1a | Oh, 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 have | 21:49 |
| th1a | I'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" too | 21:51 |
| ignas_ | pick one | 21:52 |
| ignas_ | the actual difference would be | 21:52 |
| ignas_ | when you go to select an instructor - you see a list of all persons (paginated) | 21:53 |
| ignas_ | and you either see | 21:54 |
| ignas_ | Teacher1 - is busy on that time teaching section C | 21:54 |
| ignas_ | Teacher2 - is busy on that time teaching section D | 21:54 |
| ignas_ | Stuent1 - is not busy | 21:54 |
| ignas_ | Stuent2 - is not busy | 21:54 |
| ignas_ | or | 21:55 |
| ignas_ | Student1 - is busy on that time attending section C | 21:55 |
| ignas_ | Student2 - is busy on that time attending section D | 21:55 |
| th1a | What am I trying to accomplish when I see this? | 21:55 |
| ignas_ | pick a teacher for the section | 21:56 |
| ignas_ | you will see only names though not Student1, Teacher2 | 21:56 |
| *** mgedmin has quit IRC | 22:02 | |
| th1a | ignas_: I can't really picture this. | 22:04 |
| th1a | Just pick one. | 22:04 |
| ignas_ | ok :) | 22:04 |
| *** ignas_ has quit IRC | 22:11 | |
| *** Aiste has joined #schooltool | 22:23 | |
| *** alga has quit IRC | 23:24 | |
| *** Gwynn has quit IRC | 23:47 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!