| pcardune | sure | 00:08 |
|---|---|---|
| pcardune | th1a: sure | 00:09 |
| *** jinty has quit IRC | 00:23 | |
| *** brigadoon has joined #schooltool | 00:26 | |
| *** brigadoon has quit IRC | 00:30 | |
| *** tristil has quit IRC | 00:46 | |
| *** pcardune has quit IRC | 00:58 | |
| *** felipe__ has joined #schooltool | 01:50 | |
| *** felipe__ has quit IRC | 02:30 | |
| *** jinty has joined #schooltool | 04:46 | |
| *** th1a_ has joined #schooltool | 04:58 | |
| th1a_ | srichter: ayt? | 04:58 |
| *** jinty has quit IRC | 05:11 | |
| *** th1a_ has quit IRC | 08:20 | |
| *** kwak has joined #schooltool | 08:51 | |
| *** kwak has left #schooltool | 08:54 | |
| *** kitblake has left #schooltool | 10:34 | |
| *** mgedmin has joined #schooltool | 11:50 | |
| *** gintas has joined #schooltool | 12:15 | |
| povbot | /svn/commits: * faassen committed revision 6218: | 12:50 |
| povbot | /svn/commits: Add generation code that: | 12:50 |
| povbot | /svn/commits: * sets up the required utilities for demographics. | 12:50 |
| povbot | /svn/commits: * catalogs all persons by sending ObjectAddedEvent. | 12:50 |
| * mgedmin notices that buildbot was idling for a couple of days | 13:11 | |
| * mgedmin kicks buildbot in the nethers | 13:11 | |
| *** gintas has quit IRC | 13:27 | |
| *** vidasp has joined #schooltool | 13:29 | |
| povbot | /svn/commits: * faassen committed revision 6219: | 13:31 |
| povbot | /svn/commits: Improve search form. Put in some explanatory text, and hook it up to the menu. | 13:32 |
| *** faassen has joined #schooltool | 13:34 | |
| *** povbuildbot has joined #schooltool | 13:35 | |
| *** gintas has joined #schooltool | 13:44 | |
| *** gintas has quit IRC | 13:47 | |
| *** gintas has joined #schooltool | 13:48 | |
| *** didymo has quit IRC | 13:59 | |
| *** jinty has joined #schooltool | 14:02 | |
| *** gintas has quit IRC | 14:10 | |
| *** ignas has joined #schooltool | 14:11 | |
| *** srichter has quit IRC | 14:18 | |
| *** thisfred has joined #schooltool | 14:23 | |
| ignas | faassen: ping | 14:31 |
| faassen | ignas: pong | 15:08 |
| ignas | i sent an email explaining what's the problem with evolution | 15:08 |
| faassen | ignas: I'll mail you the Data.fs | 15:09 |
| faassen | ignas: I just sent you the Data.fs | 15:09 |
| ignas | ok | 15:09 |
| faassen | ignas: I tihnk it's more efficient if you look into it. | 15:09 |
| ignas | it's a 5 minute fix anyway | 15:11 |
| *** mgedmin has quit IRC | 15:12 | |
| *** mgedmin has joined #schooltool | 15:14 | |
| ignas | faassen: the evolution still breaks, as it seems person objects lose their parents or something :/ | 15:18 |
| ignas | should i just commit the change and leave it to you ? | 15:18 |
| ignas | i am getting tracebacks when trying to view persons calendar | 15:19 |
| ignas | while i can see the list of persons or persons themselves without a hitch | 15:19 |
| povbot | /svn/commits: * ignas committed revision 6220: | 15:25 |
| povbot | /svn/commits: Fix invalid deprecation of Term and TermContainer. | 15:25 |
| faassen | you just get deprecation warnings now. | 15:27 |
| faassen | and what will be do by 0.15? :) | 15:27 |
| faassen | write the evolution script that does actually move the class? | 15:27 |
| faassen | anyway thanks for the fix. | 15:30 |
| ignas | 1. there will be no 0.15 :D we will have SchoolTool2006 | 15:32 |
| ignas | 2. we will state that we do not support migration from schooltool0.13 to schooltool2007 | 15:32 |
| ignas | oh | 15:33 |
| ignas | ouch | 15:33 |
| ignas | i just understood the implications of your statement | 15:33 |
| ignas | term container stays with it's old class :/ | 15:34 |
| ignas | so deprecation actually is for deprecating interfaces not ZODB classes | 15:34 |
| ignas | wonder why srichter did it with deprecation not evolution then ... | 15:35 |
| faassen | well, if you deprecate a ZODB class, you need to provide an evolution that upgrades it. | 15:35 |
| faassen | I don't know. | 15:35 |
| faassen | because it's a million times easier? :) | 15:35 |
| ignas | bingo :) | 15:36 |
| faassen | I mean, in general it makes sense to deprecate ZODb classes I guess. | 15:36 |
| faassen | if you move them. | 15:36 |
| faassen | if you have clients that use the systme as a framework. | 15:36 |
| faassen | such as in the case of Zope 3 core and less so for Schooltool | 15:36 |
| faassen | as then your clients know they need to fix things. | 15:36 |
| ignas | what clients ? | 15:41 |
| faassen | clients of the framework, I mean. | 15:42 |
| faassen | users of the framework. | 15:42 |
| ignas | i was being ironic, as schooltool has pretty much no users that use it as a framework | 15:44 |
| faassen | well, isn't pc..what's his name? one.. | 15:45 |
| faassen | and there's the whole intent of the commendation package. | 15:45 |
| faassen | but I'm actually pretty glad there's nobody who is using it as a framework right now. :) | 15:45 |
| faassen | so for schooltool, deprecation warnings are not so important I'd say. | 15:45 |
| ignas | by the way - can you see calendar for schooltool manager after migrating the Data.fs.small ? | 15:48 |
| *** jinty has quit IRC | 15:48 | |
| faassen | hm, no. | 15:50 |
| faassen | TypeError: ('Not enough context information to get parent', <schooltool.person.person.Person object at 0xb12b176c>) | 15:50 |
| faassen | weird though, that shouldn't be a schooltool.person.person object. | 15:50 |
| faassen | it should be a schooltool.demographics.person object. | 15:50 |
| faassen | and it is. | 15:50 |
| faassen | so what is it complaining about .. | 15:50 |
| mgedmin | faassen: did you write an evolution script to replace schooltool.person persons witrh demographics persons? | 15:51 |
| faassen | yes. | 15:51 |
| faassen | and it works. | 15:51 |
| faassen | using the introspector, it shows that manager is a demographics person. | 15:51 |
| mgedmin | are you sure you got all the references to the old person objects? | 15:51 |
| faassen | mgedmin: well, not anymore obviously. | 15:51 |
| mgedmin | it seems to me that the demo person points to some subobject (e.g. calendar?) that has a __parent__ that still points to the old object | 15:51 |
| mgedmin | the old object is dangling (has no __parent__ or something) | 15:52 |
| faassen | right.. | 15:52 |
| faassen | so that might be the calendar overlay. | 15:52 |
| mgedmin | or it could be that references to the old person object remain somewhere deep in the internals of relationship links | 15:52 |
| mgedmin | replacing an object's class is very very tricky with zodb | 15:52 |
| faassen | I suspect it's just the parent link. I did take care of relationships by just reestablishing them. | 15:52 |
| faassen | okay, .. | 15:54 |
| faassen | overload_calendars is more complicated than I suspected. :) | 15:54 |
| faassen | I think it turns out to be a BoundOverlaidCalendarsProperty | 15:54 |
| faassen | which is a BoundRelationshipProperty | 15:54 |
| faassen | heh, I actually wonder who we're doing this for. | 15:55 |
| ignas | i think calendar overlays must be punished | 15:55 |
| faassen | well evolving classes is painfully painful. :) | 15:56 |
| faassen | maybe it's the clincher and I should've used annotations everywhere, though that would've been painful elsewhere. | 15:56 |
| faassen | I sort of think, I should write a test for this. | 15:56 |
| faassen | though I expect that would cost me the entire afternoon again. | 15:56 |
| faassen | and I just spent a day writing tests for evolve17.py | 15:57 |
| faassen | satisfying the catalog. | 15:57 |
| ignas | i'd say that a surface test that only checks "that the code does that what you think it does" would suffice | 15:59 |
| ignas | tough in the long term resurrecting the migration functional testing | 15:59 |
| ignas | would be nice | 15:59 |
| faassen | it depends on how much set up the test needs. | 16:00 |
| faassen | the setup is the painful thing. | 16:00 |
| faassen | lovely. NoSuchRelationship. | 16:02 |
| faassen | I tried to do the same thing as for the groups relationship. | 16:02 |
| faassen | but I get 'NoSuchRelationship' | 16:02 |
| *** pcardune has joined #schooltool | 16:03 | |
| faassen | of course I do eyeball testing by actually starting schooltool. | 16:03 |
| faassen | probably I wouldn't have been able to replicate this problem if I set up stuff in the test. :) | 16:03 |
| faassen | are overlaid calendars relationships that just cannot be removed or something? | 16:04 |
| faassen | the doctest of overlaid calendars claims it should work. | 16:05 |
| faassen | okay, so calendar overlays don't appear to be right. | 16:10 |
| faassen | I don't claim to know how the relationship package works. | 16:10 |
| faassen | but you'd think this would work: | 16:10 |
| faassen | calendars = list(person.overlaid_calendars) | 16:11 |
| faassen | for calendar in calendars: | 16:11 |
| faassen | person.overlaid_calendars.remove(calendar) | 16:11 |
| faassen | but it doesn't. | 16:11 |
| faassen | it gives me NoSuchRelationship | 16:11 |
| mgedmin | hmm, removing while iterating? scary | 16:11 |
| mgedmin | do you perhaps have security proxies there | 16:11 |
| faassen | what do you mean? | 16:11 |
| mgedmin | ? | 16:11 |
| faassen | didn't you see that list? | 16:11 |
| mgedmin | oh, oops | 16:11 |
| * mgedmin blind | 16:12 | |
| faassen | well, the only thing that seems to be in there.. | 16:12 |
| faassen | seems to have a target .. | 16:12 |
| faassen | <schooltool.app.cal.Calendar object at 0xb660652c> | 16:12 |
| faassen | and the other thing it compares to is | 16:12 |
| faassen | <schooltool.app.overlay.CalendarOverlayInfo object at 0xb657766c> | 16:12 |
| faassen | don't know whether that causes it to fail. | 16:12 |
| mgedmin | hmm | 16:12 |
| faassen | but I think it does. | 16:13 |
| mgedmin | oops | 16:13 |
| faassen | I mean, I'm not going to be the proper way about this, I'm testing by hand. :) | 16:13 |
| mgedmin | the overlaid_calendars proxy magically constructs transient OverlaidCalendarInfo objects in its __iter__ | 16:13 |
| mgedmin | but forgets to take those into account in remove() | 16:13 |
| mgedmin | I suspect | 16:13 |
| faassen | hm. | 16:13 |
| faassen | I don't think I'm easily capable to do this myself. | 16:13 |
| faassen | capable of doing this myself, that is. | 16:14 |
| faassen | fixing it, I mean. | 16:14 |
| mgedmin | no... BoundOverlaidCalendarsProperty's docstring tests that case | 16:14 |
| mgedmin | no it doesn't! | 16:15 |
| mgedmin | ok, here's how to make it work: | 16:15 |
| mgedmin | for cal_info in list(person.overlaid_calendars): person.overlaid_calendars.remove(cal_info.calendar) | 16:15 |
| mgedmin | or we could rethink the unobvious api | 16:16 |
| faassen | you'd expect this to always work for relationships. | 16:16 |
| faassen | I mean, that should be part of the semantics. | 16:16 |
| faassen | in Eiffel, you'd express this with pre and postconditions and it would be inherited. | 16:16 |
| mgedmin | yes | 16:16 |
| faassen | not that I know Eiffel. :) | 16:16 |
| mgedmin | the abuse of __iter__ is Bad | 16:16 |
| mgedmin | the person who did this was probably smoking something | 16:17 |
| mgedmin | um... that would be me, I guess ;) | 16:17 |
| mgedmin | sorry! | 16:17 |
| mgedmin | anyway, don't these relationship properties have a clear() method? | 16:18 |
| faassen | might be. | 16:18 |
| faassen | hm, IOverlaidCalendarsProperty doesn't. | 16:18 |
| faassen | it doesn't subclass anything. | 16:18 |
| mgedmin | nope, they don't | 16:19 |
| mgedmin | there's a global unrelateAll() function, but it removes *all* relationships | 16:19 |
| faassen | joy, now it starts but I get some kind of duplicate relationship error | 16:20 |
| faassen | weird. | 16:21 |
| faassen | it's hardly as if I added that relationship already. | 16:21 |
| faassen | argh. | 16:21 |
| faassen | I set up fresh person objects. | 16:22 |
| faassen | but perhaps they already ahve some relationship in there.. | 16:22 |
| *** jinty has joined #schooltool | 16:28 | |
| faassen | okay, I give up. | 16:31 |
| faassen | I have no idea how to migrate these overlaid calendars. | 16:31 |
| ignas | :/ | 16:45 |
| faassen | I've sent a report to the mailing list. :) | 16:49 |
| *** jinty has quit IRC | 16:50 | |
| ignas | ZODB sucks :/ | 16:55 |
| ignas | and if i would have some time i would actually redo overlaid calendars completely | 16:57 |
| ignas | as the implementation is unflexible and too complex at the same time | 16:58 |
| faassen | yeah, it's pretty complicated. | 16:58 |
| faassen | any code with __get__ in it is overly complicated. :) | 16:58 |
| faassen | and words like Bound. | 16:58 |
| faassen | including zope.formlib. | 16:58 |
| ignas | and we can't even have custom colors for overlays with all that complexity | 16:59 |
| faassen | I debugged through it and I saw a reference to colors. :) | 17:00 |
| faassen | that's all I know about overlays. | 17:00 |
| faassen | I don't really know what's going on. :) | 17:00 |
| faassen | I vaguely wonder what real world schooltools will really be upgrading anyway. :) | 17:01 |
| ignas | a public promise to migrate databases was made so :/ even if there is one user in the basement that is actually using schooltool we must do it | 17:02 |
| faassen | hm. | 17:03 |
| faassen | all upgrade strategies have their ups and downs. | 17:03 |
| faassen | XML export and import is hard to make too. | 17:03 |
| faassen | but avoids a whole set of issues. | 17:03 |
| faassen | it has its own issuse though. | 17:03 |
| *** jinty has joined #schooltool | 17:05 | |
| ignas | faassen: yay, found the bug | 17:05 |
| ignas | IIRC person added subscriber automatically overlays some calendars | 17:05 |
| faassen | yeah.. | 17:05 |
| ignas | so you should remove all the calendar relationships AFTER adding the person once more | 17:06 |
| faassen | that's what I suspected but I don't know what to do about t. | 17:06 |
| faassen | again, huh? | 17:06 |
| faassen | oh, and concerning testing... | 17:06 |
| faassen | thanks for the help by the way. | 17:06 |
| faassen | I mean, I consider writing an actual test for this more trouble than it's worth. | 17:06 |
| faassen | I speak as someone who spent a day writing the catalog test. :) | 17:06 |
| ignas | :) | 17:07 |
| ignas | i'll look at it though | 17:07 |
| ignas | i can refactor some parts | 17:07 |
| ignas | and test them separately | 17:07 |
| ignas | just to be sure | 17:07 |
| faassen | will you check in the fix? | 17:07 |
| faassen | or shall I? | 17:07 |
| ignas | yes | 17:07 |
| ignas | i will | 17:07 |
| faassen | I mean, I dno't know how to start writing a test for this. | 17:07 |
| faassen | great. | 17:07 |
| faassen | thanks for the help, that's great. :) | 17:07 |
| faassen | sorry I get grumpy. | 17:07 |
| faassen | I am hatching plots to make Zope 3 safe for mortals. | 17:07 |
| faassen | I'm not all complaints. :) | 17:07 |
| ignas | ./makezopeinstance --iddqd | 17:08 |
| faassen | what's iddqd? | 17:11 |
| ignas | Doom2 immortality cheat code | 17:11 |
| ignas | btw why exactly are you doing event.notify(ObjectAddedEvent(person)) ? | 17:12 |
| faassen | is that adding overlays? | 17:12 |
| faassen | it's one thing I had my doubts about doing. | 17:12 |
| ignas | yes | 17:12 |
| faassen | I'm doing this to trigger the cataloging. | 17:12 |
| ignas | i see | 17:12 |
| faassen | so my doubts were correct. | 17:12 |
| faassen | I mea,n it triggers the intid index. | 17:12 |
| ignas | how many subscribers there are that do catalogs ? | 17:12 |
| faassen | which triggers the catalog. | 17:12 |
| faassen | but isn't that in evolve16? | 17:13 |
| faassen | I'm confused about the objectadded event in .. | 17:13 |
| ignas | 17 | 17:13 |
| faassen | wait.. | 17:13 |
| faassen | why is that adding the overlays? | 17:13 |
| faassen | we have a problem in evolve14, right? | 17:13 |
| ignas | nope | 17:13 |
| faassen | ooh. | 17:13 |
| ignas | apparently not | 17:13 |
| faassen | you mean that it's trying to add them again.. | 17:13 |
| ignas | yes | 17:13 |
| faassen | while they now already exist. | 17:13 |
| ignas | yes | 17:13 |
| faassen | okay, that explains it. | 17:13 |
| faassen | sorry, took me a while to catch up. | 17:13 |
| faassen | anyway, I could change that to manually call the intid thing. | 17:14 |
| faassen | I tink. | 17:14 |
| ignas | one way to do this is "hack the subscriber" to cope with objects that have been "added" twice | 17:14 |
| faassen | I think. | 17:14 |
| faassen | so there's no object added event response. | 17:14 |
| faassen | basically call addIntIdSubscriber manually. | 17:15 |
| faassen | that should trigger the right response. | 17:15 |
| faassen | from zope.app.intid import addIntIdSubscribe | 17:15 |
| faassen | r | 17:15 |
| pcardune | I've got a question about these Crowd things, who should I ask about them? | 17:16 |
| faassen | addIntIdSubscriber(person, None) | 17:16 |
| faassen | not sure about the None bit. you might have to make a dummy ObjectAddedEvent object. | 17:16 |
| faassen | and pass that on. | 17:16 |
| faassen | ignas: would that help you fix it? | 17:16 |
| ignas | looking at it | 17:17 |
| faassen | ignas: any luck? | 17:28 |
| ignas | evolution script works, but i am still getting the traceback when looking at my calendar | 17:28 |
| faassen | hm. | 17:28 |
| faassen | we do avoid the add event now. | 17:28 |
| faassen | and nothing else is subscribed to intids in schooltool. | 17:29 |
| faassen | so evolve17 isn't the issue anymore. | 17:29 |
| ignas | apparently - no | 17:29 |
| ignas | don't know about unit tests though | 17:29 |
| faassen | well, leave it like that anyway, it's cleaner. | 17:29 |
| faassen | did you try running the unit tests? | 17:29 |
| ignas | yep | 17:30 |
| ignas | 17 pass | 17:30 |
| ignas | 14 not yet | 17:30 |
| faassen | probably as I didn't do enough mockup there. | 17:31 |
| faassen | this is rather a pain to mock up, and you probably still won't find the real bugs. | 17:31 |
| ignas | i am doing all kinds of bugs not just real ones ;) so they do help me (i have a lot of problems noticing minute details) | 17:33 |
| *** vidasp has quit IRC | 17:33 | |
| faassen | oh, I agree they're helpful. | 17:35 |
| faassen | it's just that I think for upgrade we'd be better off doing functional tests. | 17:35 |
| ignas | there was a "framework" for that | 17:37 |
| faassen | yeah, yeah, don't scare me. :) | 17:38 |
| *** alga has joined #SchoolTool | 17:39 | |
| ignas | no really, a couple of old Data.fs.0.11 and Data.fs.0.12 files with python scripts that Copy them and run schooltool | 17:39 |
| ignas | so one would not have to do it by hand | 17:39 |
| faassen | I just am scared by frameworks right now. :) | 17:40 |
| alga | Happy BD Martijn! | 17:41 |
| ignas | HAPPY BIRTHDAY | 17:41 |
| faassen | oh, thanks. :) | 17:43 |
| faassen | that darn orkut, huh? | 17:43 |
| faassen | who still uses Orkut in lithuania? | 17:43 |
| * faassen grins. | 17:43 | |
| th1a | Happy birthday, faassen! | 18:09 |
| th1a | What could be a better birthday present than working on generations scripts! | 18:10 |
| faassen | yay! | 18:10 |
| faassen | I did that yesterday mostly. | 18:10 |
| mgedmin | faassen.generation += 1 | 18:10 |
| th1a | I do appreciate your persistence, faassen. | 18:10 |
| faassen | today I wisely decided to give up before I was dragged into it. | 18:10 |
| mgedmin | happy birthday | 18:10 |
| faassen | too deeply. | 18:10 |
| faassen | th1a: hah, persistence, me? :) | 18:11 |
| faassen | I changed the add form to your behavior now. it works. now to fix all the broken tests. :) | 18:12 |
| th1a | class faassen(persistent): | 18:12 |
| faassen | th1a: I don't mean your behavior, I mean the behavior you specified. I think. :) | 18:12 |
| * faassen laughs. | 18:12 | |
| faassen | from programmer import Grumbly | 18:13 |
| faassen | class Faassen(Grumbly): | 18:13 |
| faassen | .... | 18:13 |
| faassen | """ | 18:13 |
| faassen | We test whether Faassen is really grumbly enough: | 18:13 |
| faassen | >>> faassen.changeAddFormBehavior(Person) | 18:13 |
| faassen | >>> faassen.runAllTests() | 18:13 |
| faassen | >>> faassen.wait() | 18:14 |
| faassen | >>> faassen.getTestFailureReport() | 18:15 |
| faassen | "6 failures only" | 18:15 |
| faassen | >>> faassen.rejoice() | 18:15 |
| faassen | >>> faassen.spendHoursFixingTests() | 18:15 |
| faassen | >>> faassen.getEmotionalState() | 18:15 |
| faassen | 'grumbly' | 18:15 |
| faassen | let's see whether centralizing the add form thing helped. :) | 18:16 |
| ignas | faassen: found the bug | 18:24 |
| faassen | what was the problem? | 18:25 |
| ignas | tricky fungus | 18:25 |
| ignas | problem is | 18:26 |
| ignas | calendar is stored in annotations | 18:26 |
| faassen | what? :) | 18:26 |
| ignas | calendar has __parent__ | 18:26 |
| ignas | so one must actually go through objects stored in annotations and check whether they are pointing at the old person | 18:26 |
| mgedmin | <mgedmin> it seems to me that the demo person points to some subobject (e.g. calendar?) that has a __parent__ that still points to the old object | 18:27 |
| mgedmin | ;) | 18:27 |
| faassen | yeah, well, I first had to solve the whole relationship issue. :) | 18:28 |
| ignas | mgedmin: that's lawyer talk | 18:28 |
| faassen | before we even go to that thing. | 18:28 |
| faassen | *and* solve the issue concerning dual adding of these relationships. | 18:29 |
| ignas | weird :? | 18:34 |
| ignas | can't grok it ... | 18:34 |
| ignas | __annotations__ do not contain calendar | 18:34 |
| faassen | doesn't the CalendarInfo have a __parent__ thing? | 18:35 |
| mgedmin | could be... | 18:35 |
| ignas | what's weird is that - getCalendar takes the calendar out of annotations | 18:35 |
| faassen | or whatever it was. | 18:36 |
| faassen | maybe those are stored in the special overlaid relationship property thingy. | 18:36 |
| faassen | I know I saw a __parent__ in there. | 18:36 |
| faassen | when debugging through it. I was touring the scenery, I had no real idea where I was. | 18:36 |
| faassen | annotations are evil, it's very clear now! :) | 18:36 |
| faassen | whatever happened to good old attributes. :) | 18:36 |
| pcardune | So, does someone have time to answer a few of my crowd questions? | 18:38 |
| pcardune | I guess everyone has left to watch the world cup | 18:42 |
| alga | I guess you're wrong | 18:44 |
| faassen | I don't watch the world cup. :) | 18:44 |
| faassen | but I'm going home soon. | 18:44 |
| pcardune | there is still 15 minutes left for people to leave... | 18:44 |
| faassen | with geeks it's all a bit confusing, it's actually not trendy to be a world cup fan. | 18:45 |
| pcardune | I guess I'm just one of those fence sitters... watching the world cup while I program | 18:45 |
| *** vidasp has joined #schooltool | 18:46 | |
| ignas | pcardune: just ask questions | 18:46 |
| alga | http://www.logosdictionary.org/pls/dictionary/new_dictionary.gdic.st?phrase_code=5642911 | 18:46 |
| ignas | i'll answer them as soon as i am not 100% busy thinking | 18:46 |
| pcardune | It seems like you can register permissions/crowds for browser views but what happens to the permissions on the context object the browser view is working on? Are browser views like trusted adapters? | 18:48 |
| alga | of course they're not | 18:48 |
| alga | you have to have a permission to render the view | 18:48 |
| alga | and the permission to access the data | 18:49 |
| alga | in some cases, the view acts as a "trusted" adapter | 18:49 |
| faassen | that's not different with crowds now, pcardune | 18:49 |
| alga | in that case you need to carefully call removeSecurityProxy in the view | 18:49 |
| faassen | Zope 3's security model isn't entirely complete. for instance, if you look up a utility, you can do anything you'd like. | 18:50 |
| faassen | through that utility. | 18:50 |
| mgedmin | what's a "world cup"? | 18:50 |
| pcardune | ok, so i have a grading spreadsheet, which contains data for all students... I want a student to only see his/her data. there are however different views for spreadsheet and single student grades. Should I put low permissions on the spreadsheet data, and then higher permissions on the views? | 18:50 |
| faassen | well, it's this theory that some worlds can have the shape of a cup. | 18:50 |
| faassen | and in certain gravitationally complex systems | 18:51 |
| mgedmin | "and this is how we know the world is banana shaped" | 18:51 |
| faassen | for instance with a number of gas giants going around a black hole. | 18:51 |
| faassen | you can have world shapes that are cups. | 18:51 |
| faassen | it only works with certain unified theories, though. | 18:52 |
| faassen | but general relativity appears to predict the world cup. | 18:52 |
| faassen | mgedmin: that clear? :) | 18:52 |
| vidasp | i thought it has something to do with printing system... | 18:52 |
| faassen | no, that's Cups World. | 18:52 |
| faassen | the global high flying conference on Cups. | 18:52 |
| faassen | full of noisy stands, demos of the latest cups extensions. | 18:52 |
| faassen | and a keynote by Steve "Shuttle" Jobs. | 18:53 |
| alga | pcardune: yes, that's exactly the case | 18:53 |
| alga | pcardune: you ensure that the view does proper checking and does not reveal the data | 18:53 |
| pcardune | hmm. OK then. thanks | 18:53 |
| alga | pcardune: require high permission on data | 18:54 |
| alga | and have the view do removeSecurityProxy | 18:54 |
| pcardune | ok | 18:54 |
| alga | and make the view more or less public | 18:54 |
| alga | and, when using removeSecurityProxy, add a comment explaining why and how | 18:55 |
| pcardune | ok | 18:55 |
| povbot | /svn/commits: * faassen committed revision 6221: | 18:55 |
| povbot | /svn/commits: Change the person add form to look mostly like the nameinfo form, with some extra fields for username and password. Submitting it successfully now redirects to the next tab. | 18:55 |
| povbot | /svn/commits: Adjust the tests so they work with it. | 18:55 |
| faassen | okay, I'm going home. :) | 18:56 |
| faassen | not to watch the world cup, however. | 18:56 |
| faassen | ignas: thanks for that evolution help..goodl uck with it. :) | 18:56 |
| faassen | ignas: sorry cause this, indirectly indirectly. | 18:56 |
| faassen | bye! have a nice weekend. | 18:57 |
| *** faassen has quit IRC | 18:57 | |
| povbot | /svn/commits: * ignas committed revision 6222: | 19:09 |
| povbot | /svn/commits: Fixed 14th and 17th evolution scripts. | 19:09 |
| *** th1a_ has joined #schooltool | 19:15 | |
| *** th1a_ is now known as th1a|X60s | 19:16 | |
| pcardune | alga: what's the difference between schooltool raising a ForbiddenAttribute error, and getting the login screen? In which cases are you going to get which screen? | 19:40 |
| *** srichter has joined #schooltool | 19:55 | |
| ignas | pcardune: i think you get ForbiddenAttribute when permissions are not set | 19:57 |
| ignas | and a log in screen when you don'[t have | 19:57 |
| ignas | sufficient privileges to do something | 19:57 |
| pcardune | ignas: do you have any tips for debugging security? | 19:58 |
| ignas | err | 20:00 |
| ignas | what problem are you having exactly | 20:01 |
| pcardune | well, I get this log in screen, but i'd like to see which permissions the logged in user has, and which ones they need to access the given page | 20:01 |
| pcardune | and where they get those permissions from... like which crowd | 20:02 |
| ignas | it's the other way | 20:02 |
| ignas | a.k.a. | 20:02 |
| ignas | when you declare a view you say permission="schoooltool.view" | 20:02 |
| ignas | or edit | 20:02 |
| ignas | you can find it in zcml | 20:02 |
| ignas | then the view tries to acquire the crowd (not crowds) that can do "schooltool.view" on the object | 20:03 |
| ignas | as the object is a view | 20:03 |
| ignas | and views don't have ICrowd adapters for them | 20:03 |
| ignas | __parent__ of the view is taken | 20:03 |
| ignas | and a named adapter of ICrowd is queried | 20:04 |
| ignas | so now we have a crowd of people who can see that view | 20:04 |
| ignas | line 64 of schooltool/securitypolicy/policy.py | 20:05 |
| ignas | and we check whether current principal is in that crowd | 20:05 |
| ignas | as you probably have a particular object in mind | 20:05 |
| pcardune | but you can have multiple crowds for a given permission on a view, and a principal can be part of multiple crowds | 20:05 |
| ignas | not multiple crowds | 20:05 |
| ignas | rather one aggregate crowd | 20:06 |
| ignas | you can add import pdb; pdb.set_trace() in line 62 of thet file | 20:06 |
| pcardune | ok | 20:06 |
| ignas | prefferably with an if "boo.bar.baz" in str() | 20:06 |
| ignas | so it would not stop on every check | 20:07 |
| ignas | or ISomeInterface.providedBy(obj) ... | 20:07 |
| ignas | and inspect the crowd | 20:07 |
| ignas | it will be AggregateCrowd most of the time | 20:07 |
| ignas | to inspect it call: | 20:07 |
| ignas | crowd.crowdFactories() | 20:08 |
| pcardune | ok | 20:08 |
| ignas | that should list the crowds contained in there | 20:08 |
| ignas | hope that clears the picture a bit | 20:09 |
| pcardune | it does a lot. Thanks | 20:09 |
| *** jinty has quit IRC | 20:15 | |
| ignas | pcardune: found the problem ? | 20:49 |
| pcardune | yes I did actually | 20:49 |
| pcardune | it was incorrect permissions on something I didn't realize was being accessed | 20:50 |
| pcardune | I've just put a bunch of print statements with a catch on security rejections and I can see things very clearly | 20:50 |
| povbot | /svn/commits: * ignas committed revision 6223: | 20:53 |
| povbot | /svn/commits: Deleted some commented out debug code. | 20:53 |
| *** thisfred has quit IRC | 21:01 | |
| *** jinty has joined #schooltool | 21:27 | |
| *** ignas has quit IRC | 21:31 | |
| *** dwoo has joined #schooltool | 22:06 | |
| *** pcardune_ has joined #schooltool | 22:08 | |
| *** alga has quit IRC | 22:10 | |
| *** pcardune has quit IRC | 22:23 | |
| *** Aiste has quit IRC | 22:36 | |
| *** mgedmin has quit IRC | 22:38 | |
| *** Aiste has joined #schooltool | 23:08 | |
| *** jinty has quit IRC | 23:21 | |
| *** pcardune has joined #schooltool | 23:31 | |
| *** dwoo has quit IRC | 23:33 | |
| *** pcardune_ has quit IRC | 23:33 | |
| *** pcardune has quit IRC | 23:57 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!