| *** aelkner has joined #schooltool | 00:46 | |
| *** tdoggette has quit IRC | 00:53 | |
| *** didymo has joined #schooltool | 02:33 | |
| *** tdoggette has joined #schooltool | 04:22 | |
| *** tdoggette has quit IRC | 06:13 | |
| *** jfroche has quit IRC | 06:13 | |
| *** tdoggette has joined #schooltool | 06:20 | |
| *** jfroche has joined #schooltool | 06:20 | |
| *** tdoggette has quit IRC | 06:33 | |
| *** jfroche has quit IRC | 07:09 | |
| *** jfroche has joined #schooltool | 07:11 | |
| *** jfroche has quit IRC | 07:17 | |
| *** jfroche has joined #schooltool | 07:26 | |
| *** jfroche has quit IRC | 07:33 | |
| *** jfroche has joined #schooltool | 07:43 | |
| *** jfroche has quit IRC | 07:48 | |
| *** jfroche has joined #schooltool | 07:57 | |
| *** tdoggette has joined #schooltool | 08:21 | |
| *** jfroche has quit IRC | 08:28 | |
| *** jfroche has joined #schooltool | 08:38 | |
| *** tdoggette has quit IRC | 10:10 | |
| *** tdoggette has joined #schooltool | 11:53 | |
| *** tdoggette has quit IRC | 11:56 | |
| *** tdoggette has joined #schooltool | 11:57 | |
| *** didymo has quit IRC | 12:46 | |
| *** tdoggette has quit IRC | 14:01 | |
| *** ignas has joined #schooltool | 14:21 | |
| *** mgedmin has joined #schooltool | 14:31 | |
| *** th1a has joined #schooltool | 15:31 | |
| ignas | th1a: hi | 15:47 |
|---|---|---|
| th1a | hi ignas. | 15:47 |
| Lumiere | 'morning | 15:47 |
| ignas | th1a: should I just go and fix the CAS authentication? or are we going to leave it to aelkner? | 15:48 |
| ignas | it seems he is having a lot of problems with it :/ | 15:48 |
| th1a | Well, I assume we'll be discussing that today. | 15:49 |
| th1a | Certainly if you can help him get unstuck, that would be good. | 15:49 |
| th1a | ignas: Do you know what the specific problem is? | 15:51 |
| *** wbrady has joined #schooltool | 16:01 | |
| ignas | th1a: no, but i know that the code is complex, and the tests are missing | 16:04 |
| ignas | not the code, but the CAS magic dnce | 16:05 |
| th1a | Yeah... I think we have to have tests. | 16:05 |
| ignas | well - adding tests is complicated too | 16:06 |
| th1a | I ran into the same kind of thing with SIF. | 16:06 |
| th1a | If you don't know if the bug is in the client or server, you're humped. | 16:06 |
| ignas | yep, and testing with a server outside is giving you messy logs | 16:08 |
| ignas | because one part of the logs is coming from rubycas | 16:08 |
| ignas | and the other part from your application | 16:08 |
| ignas | which means - you don't know what happend first | 16:09 |
| aelkner | th1a, ignas: morning | 16:21 |
| th1a | Good morning aelkner. | 16:22 |
| th1a | A CAS gameplan seems to be the first order of business here. | 16:22 |
| aelkner | yeah, i figured | 16:22 |
| aelkner | i should give you some details of what i've discovered | 16:23 |
| th1a | Go ahead. | 16:23 |
| aelkner | i didn't want to get into it in my report to the SLA folks | 16:23 |
| th1a | Yep. | 16:23 |
| aelkner | so first, if you are not signed on to CAS and you start the app | 16:24 |
| aelkner | it will correctly take you to the CAS login screen | 16:24 |
| aelkner | and if you put the right credentials in, it will take you back to the app | 16:24 |
| aelkner | so that part always worked | 16:24 |
| aelkner | only problem with that part was what i found out was going on in the traces i wrote | 16:24 |
| aelkner | namely, i fond out that zope is weird about redirects | 16:25 |
| aelkner | when you say, request.response.redirect(some_url) | 16:25 |
| aelkner | i always assumed that zope would take that as a signal to abort that transaction | 16:26 |
| aelkner | and redirect | 16:26 |
| *** jelkner has joined #schooltool | 16:26 | |
| ignas | emm, why? | 16:26 |
| aelkner | well, how would you know if you were really going to redirect to where you wanted to | 16:26 |
| ignas | i mean - you won't be able to store anything in the session or in the database and then redirect then ... | 16:26 |
| aelkner | if it just keeps going on executing more tranversal handlers | 16:27 |
| aelkner | in other words | 16:27 |
| aelkner | it starts traversing the app object | 16:27 |
| aelkner | it calls the authenticate method of your plugin | 16:27 |
| aelkner | we say, "redirect to CAS server with this query string" | 16:28 |
| aelkner | it doesn't redirect at first | 16:28 |
| ignas | yes | 16:28 |
| aelkner | it traverses to say, the person container, for the sake of an example | 16:28 |
| aelkner | that causes it to call our authenticate method again | 16:29 |
| aelkner | causing us to redirect again! | 16:29 |
| aelkner | with a different query string | 16:29 |
| ignas | are you sure it's happening in the same request then? | 16:29 |
| aelkner | yes, i'm sure | 16:29 |
| aelkner | becuase i put a trace at the beginning of zope/publichser/publish.py | 16:30 |
| aelkner | in the publish method | 16:30 |
| ignas | pdb trace? | 16:30 |
| ignas | i see | 16:30 |
| aelkner | no way could i use pdb | 16:30 |
| aelkner | well, in that case i could | 16:30 |
| ignas | if query strings are different - it's probably the second request, and you even though you have access to the app, just don't have access to the person container | 16:30 |
| ignas | if it's print | 16:30 |
| ignas | it can be comming from 2 different requests | 16:30 |
| aelkner | cuase it only stopped there a couple of times | 16:30 |
| ignas | how do you know it's the same request if you are printing ? | 16:31 |
| aelkner | i don't understand the question | 16:31 |
| aelkner | i hit just one button in the browser | 16:31 |
| ignas | so | 16:31 |
| aelkner | adn watch the print statements | 16:31 |
| ignas | it still generates 2x requests | 16:31 |
| ignas | with CAS authentication | 16:31 |
| ignas | Schooltool -> CAS -> Schooltool | 16:32 |
| aelkner | i understand that | 16:32 |
| aelkner | i expect that, in fat | 16:32 |
| ignas | 2 redirects - 2 different print statements | 16:32 |
| aelkner | it's the calling of authenticate ten times that got me confused | 16:32 |
| aelkner | and agravated actgually | 16:32 |
| aelkner | because why would it not redirect to CAS when i ask it to | 16:32 |
| aelkner | instead of coming back to authenticate once for each object in the traversal | 16:33 |
| aelkner | before leaving the publich method | 16:33 |
| ignas | is it really comming back for each object? | 16:33 |
| ignas | because a redirect is not "invoked" before the end of traversal | 16:33 |
| aelkner | yes, that's the benefit of my traces, that i can see what it's doing | 16:33 |
| ignas | so if it hits CAS 10 time | 16:33 |
| ignas | times | 16:33 |
| ignas | hits CAS actually, not tries to redirect 10 times | 16:33 |
| aelkner | it doesn't hit the CAS server ten times | 16:34 |
| ignas | oh | 16:34 |
| aelkner | it hits the authenticate method ten times | 16:34 |
| aelkner | ad maybe i'll have to live with that | 16:34 |
| ignas | hmm, interesting | 16:34 |
| aelkner | it's just really disturbing that you redirect only to find that you havce to redirect again | 16:34 |
| ignas | well - that's the way CAS works, most of the time | 16:35 |
| aelkner | that's not a CAS thing, it's a zope thing | 16:35 |
| ignas | and yes - at the moment schooltool authentication strategy is not optimal | 16:35 |
| ignas | it's schooltool thing actually | 16:35 |
| aelkner | well, yes, that's the other issue | 16:35 |
| aelkner | no, i'm talking zope traversal | 16:35 |
| aelkner | when zope traverses | 16:35 |
| aelkner | it should notice that it's been redirected | 16:36 |
| aelkner | and stop! | 16:36 |
| ignas | no it should not | 16:36 |
| aelkner | why? | 16:36 |
| ignas | because there might be more operations to be performed | 16:36 |
| ignas | to the database even | 16:36 |
| aelkner | more travesal? | 16:36 |
| aelkner | if i'm traversing and object | 16:37 |
| aelkner | and i can't allow travesal to the root | 16:37 |
| aelkner | why should it keep traversing below the root | 16:37 |
| aelkner | ? | 16:37 |
| aelkner | if i say, redirect | 16:37 |
| aelkner | it should redirect | 16:37 |
| ignas | redirect does not mean - you can't access what's below | 16:38 |
| aelkner | what does it mean when you can't access the root? | 16:38 |
| aelkner | only that? | 16:39 |
| ignas | redirect is not "signaling that" | 16:39 |
| ignas | the question is - why is our authentication utility not saying "you can't access" properly, or why Zope is ignoring that | 16:39 |
| ignas | it's not related to redirects | 16:39 |
| aelkner | ok, well, take the situation where the user just signs in | 16:40 |
| aelkner | the first traversal is the root | 16:40 |
| aelkner | schooltool.cas authenticate method redirects to CAS | 16:40 |
| ignas | aelkner: do you know the difference between authentication and authorization? | 16:40 |
| aelkner | yeah, why? | 16:41 |
| ignas | unauthenticated does not mean - can't access | 16:41 |
| aelkner | i'm only talking authenticate method of the pluging | 16:41 |
| ignas | it just means - we don't know who you are | 16:41 |
| aelkner | right, the principal is None | 16:42 |
| aelkner | becuase it needs to redirect to CAS | 16:42 |
| ignas | so it's our problem | 16:42 |
| aelkner | and get back the ticket | 16:42 |
| ignas | to say - we know we don't know who you are | 16:42 |
| ignas | 10 times | 16:42 |
| ignas | and redirect only once | 16:42 |
| ignas | though - we don't have to do that | 16:42 |
| ignas | even | 16:42 |
| aelkner | we can just redirect the ten times as we do | 16:43 |
| ignas | yes | 16:43 |
| ignas | it will only redirect once | 16:43 |
| aelkner | well, i can live with that | 16:43 |
| ignas | with the last value of redirect | 16:43 |
| aelkner | it just was not how i would expect redirect to work | 16:43 |
| ignas | the redirect call is not "do a redirect" | 16:43 |
| aelkner | so even our success case was confusing | 16:43 |
| ignas | it's "remember - render a redirect http response" | 16:43 |
| aelkner | understood | 16:44 |
| aelkner | is saw the code | 16:44 |
| aelkner | it was stting up headers and all | 16:44 |
| aelkner | but just not finishing the transaction | 16:44 |
| aelkner | i'm just not used to that paradigm | 16:44 |
| aelkner | anyway, i can live with that | 16:45 |
| ignas | believe me - you would not think that redirect acting as an exception is a good idea too | 16:45 |
| * ignas had to deal with an http server that does that | 16:45 | |
| ignas | doing anything meaningful and then redirecting suddenly becomes a major pain | 16:45 |
| aelkner | and you had problems cleaning up the transaction, right?> | 16:46 |
| ignas | no, i had problems making the server not cleanup the transaction for things like "Add a person, then redirect to his information view" things | 16:46 |
| aelkner | right, you didn't want to abort | 16:46 |
| ignas | but that was in a different language, though - it made me understand why this approach was picked | 16:47 |
| aelkner | that's cool, i can see the benefit of the way it is now | 16:47 |
| th1a | So does something else not work? | 16:47 |
| aelkner | well, yes | 16:47 |
| aelkner | the next thing to report is that when i click on the logout button | 16:47 |
| aelkner | it doesn't go to schooltool.cas logout view | 16:48 |
| aelkner | but that is probably because | 16:48 |
| ignas | ? | 16:48 |
| ignas | that view "redirects immediately" | 16:48 |
| ignas | so - you can't see it | 16:48 |
| aelkner | it reaches the unauthenticate method | 16:48 |
| aelkner | which redirects to CAS | 16:48 |
| aelkner | it never reaches the logout view | 16:49 |
| ignas | you mean the __call__ of it? | 16:49 |
| aelkner | i'm not sure of this one yet | 16:49 |
| aelkner | right | 16:49 |
| ignas | interesting | 16:49 |
| aelkner | it may be a registration problem | 16:49 |
| aelkner | i was going to look into that soon | 16:49 |
| aelkner | i'll tell you what my trace revealed | 16:50 |
| aelkner | it calls the unathenticate method | 16:50 |
| aelkner | which redirects to CAS with login?... | 16:50 |
| aelkner | and the CAS sever omes up | 16:50 |
| aelkner | which is what we want, except | 16:50 |
| ignas | i am not sure really | 16:50 |
| ignas | it might be the second go | 16:50 |
| aelkner | it says, "you are already logged in as aelkner" | 16:51 |
| ignas | then it's not working properly | 16:51 |
| aelkner | it shoudl say, "log in" | 16:51 |
| aelkner | yeah | 16:51 |
| ignas | maybe permissions on the logout view are broken | 16:51 |
| ignas | or something like that | 16:51 |
| aelkner | could be | 16:51 |
| aelkner | it's registered for * | 16:51 |
| aelkner | maybe it needs to be registered for the plugin | 16:51 |
| aelkner | maybe it would get found then | 16:51 |
| ignas | should not be affecting it | 16:52 |
| aelkner | i was going to check that out today | 16:52 |
| aelkner | it's always a guessing game for me with registrations | 16:52 |
| aelkner | because there isn;'t any trace | 16:52 |
| aelkner | as to what zope is trying and failing at | 16:52 |
| aelkner | and then succeeding | 16:52 |
| aelkner | that would be so nice | 16:52 |
| aelkner | personally, i am always able to get complex systems of my own creation to work | 16:53 |
| aelkner | and be trouble-shootable | 16:53 |
| aelkner | by using trace debugging | 16:53 |
| aelkner | that i can turn on and off | 16:53 |
| aelkner | so if a problem happens that i didn't anticipate | 16:54 |
| aelkner | i can look at the trace and say, "oh, i see" | 16:54 |
| aelkner | but zope doesn't provide such a thing for registration lookup | 16:54 |
| aelkner | that's too bad | 16:54 |
| ignas | believe me - you don't want traces of "Adapting Foo to IBar got BarFooAdapter" | 16:54 |
| aelkner | why not | 16:55 |
| ignas | you'd get thousands of them ... | 16:55 |
| aelkner | for once transaction? | 16:55 |
| ignas | yes | 16:55 |
| aelkner | one | 16:55 |
| ignas | just tracing SecurityPolicy gets you more data than you can handle most of the time, like a few hundered | 16:56 |
| aelkner | well, perhaps | 16:56 |
| aelkner | anyway | 16:56 |
| aelkner | the third problem i wanted to report is | 16:57 |
| aelkner | that when schooltool gets an authorized exception | 16:57 |
| aelkner | it wants to redirect to a login page | 16:58 |
| aelkner | our CAS plugin redirects to CAS | 16:58 |
| ignas | yes | 16:58 |
| aelkner | but CAS has no problem with the user | 16:58 |
| aelkner | so it just redirects back to us | 16:58 |
| aelkner | and we redirect to it | 16:58 |
| ignas | really? | 16:58 |
| ignas | weird, must be a missing parameter then | 16:58 |
| aelkner | and this infinite loop gets stopped by the browser | 16:59 |
| ignas | we should "force" the authentication | 16:59 |
| ignas | and I was sure we were ... | 16:59 |
| aelkner | after about ten round trips | 16:59 |
| Lumiere | is it possible to tell cas 'insufficient' authorization? | 16:59 |
| aelkner | is that what "renew" is for? | 16:59 |
| ignas | Lumiere: yes, you can "force" authentication | 16:59 |
| ignas | yes i think it's renew | 16:59 |
| ignas | or something like that | 17:00 |
| ignas | yeah, it's "renew" | 17:00 |
| ignas | oh | 17:00 |
| ignas | you know | 17:00 |
| Lumiere | what does renew do if the person isn't authenticated to zope? | 17:00 |
| ignas | maybe we are making the mistake of redirecting to CAS server | 17:00 |
| aelkner | let me try it right now and tell you what my traces yield | 17:00 |
| ignas | instead of redirecting to schooltool login page | 17:00 |
| aelkner | go ahead | 17:00 |
| ignas | yeah, it seems that "unauthorized" redirects to CAS | 17:01 |
| aelkner | right | 17:01 |
| ignas | while it should probably redirect either to schooltool login or at least ask for a renew | 17:01 |
| ignas | though i am not sure how to do it properly while maintaining the form information | 17:02 |
| aelkner | well, redirecting to schooltool login would not work | 17:02 |
| *** tdoggette has joined #schooltool | 17:02 | |
| aelkner | becuase then they get the schooltool auth | 17:02 |
| aelkner | instead of cas auth | 17:02 |
| *** wbrady has quit IRC | 17:02 | |
| ignas | aelkner: the first redirect loses form information | 17:03 |
| ignas | unless you store it | 17:03 |
| aelkner | i understand your store form dat logic | 17:03 |
| ignas | thus - you should be very careful about what's being fone there | 17:03 |
| aelkner | it works fine | 17:03 |
| aelkner | perhaps it jsut isn;'t being used there | 17:03 |
| ignas | it is being used at the moment | 17:03 |
| ignas | but if you redirect to schooltool login page - you will lose the form data i think | 17:04 |
| th1a | Which form information? | 17:04 |
| aelkner | you post something | 17:04 |
| aelkner | adn you want it to be there after you resolve the authentication | 17:04 |
| aelkner | that was good code that ignas wrote | 17:04 |
| aelkner | to handle that situation | 17:04 |
| ignas | th1a: we are handling the case where you enter all the data for let's say person, click submit and get to a login page (session timeouts, insufficient privileges) | 17:04 |
| ignas | you log in, and your form get's properly submitted | 17:04 |
| ignas | instead of being lost | 17:05 |
| th1a | I guess timeout is a particularly important case there. | 17:05 |
| aelkner | that's not even cas code, that's schooltool auth code | 17:05 |
| aelkner | the cas plugin subclasses schooltool's | 17:05 |
| th1a | otoh, I'm not sure that insufficient privileges is. | 17:06 |
| ignas | I think losing data is bad, no matter why... | 17:06 |
| aelkner | right | 17:06 |
| th1a | Well, it just depends on how many hoops we're creating for ourselves. | 17:07 |
| ignas | this hoop is solvable from CAS plugin anyway | 17:07 |
| th1a | OK. | 17:07 |
| ignas | just adding "renew" as a parameter in unauthorized method | 17:07 |
| ignas | should work | 17:07 |
| aelkner | well, i have to run that trace again | 17:08 |
| aelkner | give me a couple of minutes | 17:08 |
| aelkner | ok, i see that it's not redirecting to CAS with renew | 17:09 |
| aelkner | so maybe just changing that would fix the infinite loop problem | 17:09 |
| aelkner | let me look into that after the meeting | 17:10 |
| ignas | yeah, it should | 17:10 |
| aelkner | what about the logout view not getting called | 17:10 |
| aelkner | do you have a recommendation | 17:10 |
| aelkner | for how to trouble-shoot that | 17:10 |
| aelkner | ignas: i'm guessing you're looking at schooltool.cas configure.zcml | 17:12 |
| aelkner | do you see how the login and logout differ | 17:13 |
| aelkner | only with the for being * for logout | 17:13 |
| aelkner | shouldn't that be the same as for the login? | 17:13 |
| ignas | no difference | 17:13 |
| aelkner | what do mean | 17:14 |
| aelkner | there is no difference or it's ok for them to be different? | 17:14 |
| ignas | oh | 17:14 |
| ignas | ok, replace it now that i think about it | 17:14 |
| ignas | or | 17:14 |
| ignas | hmm | 17:14 |
| ignas | i'd look for other logout views | 17:14 |
| ignas | see what they are on | 17:14 |
| ignas | see whether they are registered | 17:14 |
| ignas | or called | 17:14 |
| aelkner | ok | 17:15 |
| ignas | it might be that logout is on * for backwards compatibility | 17:15 |
| ignas | but at the same time * will not conflict with a more specific logout view | 17:15 |
| *** wbrady has joined #schooltool | 17:15 | |
| ignas | so if there is a more specific logout view even if that view is registewred for IGenericAuthnticationPlugin | 17:15 |
| ignas | the more specific one will get used | 17:16 |
| ignas | ignoring the * view | 17:16 |
| ignas | so yeah - find out whether it's - problem with other view being used | 17:16 |
| ignas | or problem with permissions for logout view | 17:16 |
| aelkner | i think you answered my question anout the registration lookup logic of zope | 17:17 |
| aelkner | and i found the registration of schooltool's logout view | 17:17 |
| aelkner | it's for schooltool.app.interfaces.ISchoolToolAuthenticationPlugin | 17:17 |
| aelkner | which is in fact more specific than * | 17:17 |
| aelkner | adn since ICASAuthenticationPlugin is a subclass of it | 17:18 |
| ignas | yeah, it seems so | 17:18 |
| ignas | so yes - it will "win" | 17:18 |
| aelkner | cool | 17:18 |
| aelkner | i bet changing the reg will fix it | 17:18 |
| aelkner | i can do that after the meeting as well | 17:18 |
| aelkner | so i've reported the three issues now | 17:19 |
| aelkner | and i have a good feeling for how to address them for now | 17:19 |
| aelkner | first one was don't worry | 17:19 |
| aelkner | about the mutiple redirectsd | 17:19 |
| aelkner | just maek sure it works | 17:19 |
| aelkner | second one is fix the registration | 17:19 |
| aelkner | third one is fix the unathorized method to use renoew | 17:19 |
| aelkner | renew | 17:20 |
| aelkner | so that's all i have for now | 17:20 |
| ignas | th1a: should I report? | 17:21 |
| th1a | Please. | 17:21 |
| ignas | so my plan from add "SchoolYear" went to "fix timetables" and then to "fix timetable REST views" | 17:21 |
| ignas | which is what i am doing | 17:21 |
| ignas | the REST views either have to get fixed | 17:21 |
| ignas | or I have to rewrite a bunch of functional tests | 17:22 |
| th1a | Ah. | 17:22 |
| ignas | don't know which one is easier at the moment, actively looking at tit | 17:22 |
| ignas | *it | 17:22 |
| th1a | ;-) | 17:22 |
| ignas | the problem is - as i will add SchoolYear, and put terms in it, referring to terms by term_id | 17:23 |
| ignas | will not be viable, nor will it be a good idea | 17:23 |
| ignas | so i have to fix timetable -> term/school_timetable relationships first | 17:23 |
| ignas | which means - getting rid of the "relationship is encoded in __name__ of the timetable" | 17:23 |
| ignas | thing | 17:23 |
| ignas | that was bothering me for ages | 17:24 |
| ignas | first i will make __name__ used only through term and school_tt attributes of the timetable | 17:24 |
| ignas | to have only 1 point in code that has to be fixed | 17:24 |
| ignas | then i will convert them to direct references (temporarily) | 17:24 |
| ignas | then will make __names__ not important | 17:25 |
| ignas | like section __names__ that are 1,2,3 ... | 17:25 |
| ignas | and then add relationships so we'd avoid direct references | 17:25 |
| ignas | and would get backreferences too | 17:25 |
| ignas | as in - terms would know which timetables are using them directly | 17:25 |
| ignas | then i will add schoolyears and move terms into schoolyears | 17:26 |
| ignas | that's kind of it, spent a lot of time finding out which parts of the system are relying on terms being in a flat namespace | 17:26 |
| ignas | and refactoring timetable code | 17:26 |
| ignas | that's it | 17:27 |
| th1a | Glad you're digging into it. | 17:28 |
| th1a | Lumiere: Anything to add? | 17:28 |
| th1a | ... | 17:30 |
| Lumiere | not really | 17:30 |
| Lumiere | eldar is making great progress on his tasks | 17:30 |
| th1a | OK then. Sounds like ignas and aelkner have plenty to sink your teeth into this week. | 17:30 |
| ignas | Lumiere: what is he working on? | 17:30 |
| th1a | Have a good one! | 17:30 |
| * th1a drops the bag of gravel. | 17:30 | |
| Lumiere | he's still working through replacing all the competency back end | 17:30 |
| ignas | oh | 17:31 |
| aelkner | i attend the wed meeting each week | 17:31 |
| Lumiere | it's one of those things that changes everything | 17:31 |
| ignas | indeed | 17:31 |
| aelkner | so i'm on top of what eldar is up to | 17:31 |
| wbrady | jelkner: ayt? | 17:31 |
| Lumiere | right now he's finishing up rewriting the import of competencies into courses | 17:31 |
| Lumiere | and then rewriting importing into skill drivers | 17:31 |
| th1a | Lumiere: I'd guess it is making him feel like the whole thing is getting more sane. | 17:32 |
| Lumiere | from there he'll do gradebook likely | 17:32 |
| aelkner | importing is not the right term | 17:32 |
| aelkner | it's assinging | 17:32 |
| Lumiere | aelkner: yes | 17:32 |
| Lumiere | importing is easier to type ;) | 17:32 |
| aelkner | it's one of your habits, using that term :) | 17:32 |
| Lumiere | th1a: yes, it also will hopefully make it more bulletproof | 17:32 |
| Lumiere | old terms die hard | 17:33 |
| aelkner | definitely | 17:33 |
| aelkner | it wil be sane | 17:33 |
| aelkner | and reliable | 17:33 |
| Lumiere | I still have trouble calling jr developers anything but interns | 17:33 |
| aelkner | yeah, we all have that one | 17:33 |
| aelkner | although i've been getting better | 17:33 |
| aelkner | it just takes time | 17:33 |
| aelkner | but you shoudl stop thinking about importing | 17:33 |
| Lumiere | import is similar for welsh and I... we both have called it that for 3-5 years | 17:33 |
| aelkner | yeah | 17:33 |
| aelkner | it will take time i guess | 17:33 |
| aelkner | i oticed that welsh does the same thing | 17:34 |
| aelkner | it's a major change to the way cando works | 17:34 |
| Lumiere | anyways... good progress is being made | 17:34 |
| Lumiere | we start our sprint in a couple weeks | 17:34 |
| aelkner | yes, we have a good plan, and we keep on top of the progress each week | 17:34 |
| Lumiere | and hopefully will come out of that with substantial functional testing | 17:34 |
| Lumiere | and unit testing where possible | 17:35 |
| th1a | Good. | 17:35 |
| Lumiere | aelkner: http://www.careercenter.arlington.k12.va.us/cando-coverage/ | 17:35 |
| aelkner | it's nice to have such a report | 17:36 |
| aelkner | but i don't have time to look into how it's created right now | 17:37 |
| aelkner | so i can't say confidently, that 100% coverage means just that | 17:37 |
| aelkner | but we can get into this during the week leading up to the sprint | 17:37 |
| aelkner | i don't want to distract myself from the CAS work in the meantime | 17:38 |
| Lumiere | kk | 17:39 |
| *** jboisture has joined #schooltool | 18:12 | |
| jboisture | I'm having a problem with the zope test browser. Can anyone help? | 18:13 |
| jboisture | when I try to run browser.open('http://www.google.com/') I get an error that says zope.configuration.exceptions.ConfigurationError: No registered publisher found for (GET/) | 18:14 |
| jboisture | does anyone know what this means | 18:15 |
| Lumiere | remove the / | 18:19 |
| Lumiere | maybe | 18:19 |
| jelkner | ignas: ping | 18:21 |
| ignas | jelkner: pong | 18:21 |
| jelkner | we have a new developer who has been studying zope3 furiously for the past several weeks | 18:21 |
| ignas | jboisture: i think that there is more than one browser class | 18:21 |
| ignas | and the default class | 18:21 |
| ignas | only works with "local" hosts | 18:21 |
| ignas | which is - your Zope3 application | 18:22 |
| ignas | you must use a different implementation | 18:22 |
| ignas | if you want to test a remote server | 18:22 |
| jboisture | ok I'm going to test this ok again thanks | 18:22 |
| jboisture | I tried browser.open('http://localhost:8999') and got the same problem | 18:24 |
| ignas | how and where from are you running testbrowser? | 18:25 |
| ignas | is it inside of a functional test? | 18:25 |
| jboisture | I'm just running it in a python interpreter in the home folder of my time clock instance | 18:26 |
| ignas | you see | 18:27 |
| ignas | in functional tests | 18:27 |
| ignas | the publisher gets setup by all the fancy functional test machinery | 18:27 |
| ignas | so it works in there | 18:27 |
| ignas | the "test testbrowser" | 18:27 |
| ignas | and if you want it to run in a non functional test environment | 18:27 |
| ignas | you have to use a different TestBrowser class | 18:28 |
| Lumiere | my suggestion is to write a functional test | 18:28 |
| Lumiere | and call it | 18:28 |
| Lumiere | ignas: would pdb's settrace work in a functional test? | 18:28 |
| Lumiere | or start trace (don't remember name offhand) | 18:29 |
| th1a | jelkner: The new developer is jboisture? | 18:29 |
| jelkner | th1a: si | 18:29 |
| Lumiere | bbiab | 18:29 |
| ignas | Lumiere: nope i don't think so | 18:30 |
| jelkner | th1a: did you see my email to david trask? | 18:30 |
| th1a | Yes, thanks. | 18:31 |
| aelkner | ignas: i'm going to need to use TestBrowser to visit pages outside of schooltool | 18:31 |
| ignas | why? | 18:31 |
| aelkner | what implementation are you refering to? | 18:32 |
| jelkner | i hope they follow up with the XO idea | 18:32 |
| ignas | and no - you DON'T! | 18:32 |
| ignas | unless you really want to make tests depend on outside servers and internet connection | 18:32 |
| ignas | which is BAD | 18:32 |
| aelkner | one of my projects for this summer will be to propogate changes to schooltool to Moodle and Drupal | 18:32 |
| aelkner | so if you create a person in schooltool, it gets created in the other apps | 18:33 |
| aelkner | hwo would you suggest doing that? | 18:33 |
| ignas | you mean - testing that | 18:33 |
| ignas | it is tricky | 18:33 |
| aelkner | i mean doing it | 18:33 |
| *** mattva01 has joined #schooltool | 18:33 | |
| ignas | aelkner: emm, no idea, i mean - the perfect case is having them all use the same data structure for persons | 18:33 |
| ignas | aelkner: so the totally perfect case would be having SChoolTool use the sql table when storing persons | 18:34 |
| aelkner | that was my first idea | 18:34 |
| aelkner | but th1a didn't like it | 18:34 |
| ignas | aelkner: then if you can't do that, you opt for synchronization using crontab | 18:34 |
| ignas | which is simpler but not as reliable | 18:34 |
| ignas | than you can go for webservices and zc.deferred | 18:35 |
| th1a | We're going for very simple first. | 18:35 |
| ignas | so it really depends on what's available | 18:35 |
| aelkner | th1a: ignas suggests it's impossible to use TestBrowser | 18:35 |
| ignas | well - i am suggesting that it's a major pain | 18:35 |
| ignas | you have to find out how to do "teardown" for moodle | 18:35 |
| ignas | and "teardown" for drupal | 18:35 |
| th1a | You aren't going to write tests for the whole thing. | 18:36 |
| ignas | if you want to functionally test it | 18:36 |
| ignas | now if it's crontab approach | 18:36 |
| ignas | then you only test your new script | 18:36 |
| ignas | that lists all persons (part that connects to schooltool) | 18:36 |
| ignas | and adds these persons to SQL | 18:36 |
| ignas | in both cases - you stub out the SQL server and schooltool server | 18:36 |
| ignas | and test your utility without using the real stuff | 18:37 |
| th1a | I would rather avoid directly sticking our fingers into the database. | 18:38 |
| ignas | th1a: well, i guess yes, you can do that using moodle and drupal html UI | 18:38 |
| ignas | or some API if they have one | 18:38 |
| aelkner | so that brings us back to ,my question about TestBrowser | 18:39 |
| th1a | html is probably better. | 18:39 |
| aelkner | you said it isn't something that can be used for external sites? | 18:39 |
| ignas | th1a: xml or jason API is better | 18:39 |
| ignas | aelkner: it can be used | 18:39 |
| th1a | Well, if those were well documented. | 18:39 |
| ignas | well - HTML UI is always less documented than XML API's are ... | 18:40 |
| ignas | aelkner: i was saying - you should not do that in a functional test, unless you really really know what you are doing | 18:40 |
| th1a | Not necessarily. | 18:40 |
| *** jboisture has quit IRC | 18:40 | |
| th1a | Not necessarily documented, that is. | 18:40 |
| aelkner | i don't see how to functionally test something that interacts with another app | 18:40 |
| aelkner | because the state of the other app is not predictable | 18:41 |
| aelkner | or even its existense | 18:41 |
| aelkner | the same goes for testing CAS | 18:41 |
| aelkner | unless we have a fake CAS server that is part of schooltool.cas | 18:42 |
| ignas | aelkner: precisely, a fake server | 18:42 |
| aelkner | that gets started in the functional tests for schooltool.cas | 18:42 |
| ignas | or a fake utility that immitates server | 18:42 |
| ignas | better - fake utility | 18:42 |
| aelkner | you keep mentioning utilities | 18:42 |
| ignas | well yes - you add a utility that does all the real http calls | 18:43 |
| aelkner | but we're talking to servers | 18:43 |
| ignas | and use that in an application | 18:43 |
| ignas | in tests - you replace it with one that does no real http calls | 18:43 |
| aelkner | ok | 18:43 |
| ignas | the point is | 18:43 |
| ignas | if you call an external service | 18:43 |
| ignas | you have to start it up | 18:43 |
| ignas | in your test setup | 18:44 |
| ignas | do you want to write a functional test | 18:44 |
| ignas | that starts up a *clean* moodle instance? | 18:44 |
| ignas | and then tears it down when the test is over? | 18:44 |
| aelkner | certainly not | 18:44 |
| ignas | (we have done some simmilar things in PoV) | 18:44 |
| ignas | so yes it's possible | 18:44 |
| ignas | we used Zope3 testbrowser to test roundup | 18:44 |
| ignas | so test setup was starting up a clean roundup instance | 18:44 |
| ignas | that we did our testing on | 18:45 |
| ignas | and was deleting it after the test | 18:45 |
| aelkner | so that test would take hours, right? | 18:45 |
| ignas | no | 18:45 |
| ignas | quite fast actually | 18:45 |
| aelkner | what is roundup | 18:45 |
| ignas | bugtracker | 18:46 |
| ignas | we used it before launchpad | 18:46 |
| ignas | for schooltool | 18:46 |
| aelkner | so what did it take to make it clean? | 18:46 |
| ignas | can't recall, maybe deleting the database, or was it just removing all items | 18:47 |
| th1a | I would say the goal is to test it enough that you confirm that you're actually sending out the message you think you're sending, | 18:49 |
| th1a | and that if you get the response you expect, that you do what you're supposed to do. | 18:49 |
| aelkner | so you're suggesting the idea of a utility that fakes talking to Moodle and Drupal | 18:50 |
| ignas | yes | 18:50 |
| aelkner | and just gives responses of success or failure | 18:50 |
| ignas | something like that | 18:50 |
| ignas | actually | 18:50 |
| ignas | i am suggesting a separate application | 18:50 |
| ignas | and crontab | 18:50 |
| ignas | unless you want to learn zc.deferred | 18:50 |
| ignas | because as you know Zope3 has only 4 worker threads by default | 18:51 |
| ignas | so if your http calls will timeout or hang up | 18:51 |
| ignas | 4 stalled requests will make the application unusable | 18:51 |
| ignas | for anyone | 18:51 |
| aelkner | all the more reason to talk to the sql database directly | 18:52 |
| ignas | aelkner: that one is tough | 18:52 |
| ignas | because you have to handle double commit | 18:52 |
| *** tdoggette has quit IRC | 18:52 | |
| ignas | as in - if your zope code fails | 18:52 |
| ignas | you must revert both | 18:53 |
| ignas | schooltool ZODB transaction | 18:53 |
| ignas | AND SQL transaction | 18:53 |
| ignas | if ZODB transaction works, but SQL transaction fails - you must revert ZODB transaction | 18:53 |
| th1a | what about zc.deferred? | 18:53 |
| ignas | or else you get broken state again | 18:53 |
| ignas | th1a: not sure i understand your question... | 18:54 |
| th1a | What would that do for us? | 18:54 |
| ignas | well - i have no idea how it works | 18:54 |
| ignas | i have no idea whether it's stable | 18:54 |
| ignas | but what it would allow us to do | 18:54 |
| ignas | is make HTTP calls | 18:54 |
| ignas | to outside applications and have them not affect schooltool in any way | 18:55 |
| ignas | it is used to run looong running things in the background, like "generate a bunch of PDF documents" | 18:55 |
| ignas | or make 20 http requests | 18:55 |
| ignas | in the background | 18:55 |
| ignas | so Zope keeps on going, and the operations that add persons get done on their own pace | 18:56 |
| aelkner | and error recovery? | 18:56 |
| aelkner | if Moodle gives and error? | 18:56 |
| ignas | aelkner: well - then you are in trouble anyway, you have to implement it manually | 18:57 |
| ignas | aelkner: because it depends on when you got the error | 18:57 |
| aelkner | that's what i was getting at | 18:57 |
| ignas | and whether the person was added | 18:57 |
| aelkner | there's no way to protect against erros | 18:57 |
| ignas | or only half added | 18:57 |
| aelkner | in a system other than the one you're in | 18:57 |
| th1a | aelkner: You should probably investigate zc.deferred. | 18:57 |
| aelkner | that's why things need to be rerunnable | 18:58 |
| ignas | so yeah, a separate script that is executed by crontab that "syncs" both schooltool and moodle | 18:58 |
| aelkner | i probably will need it | 18:58 |
| ignas | is something that you can just rerun | 18:58 |
| ignas | and if it fails - you fix it, and run it again | 18:59 |
| ignas | it's brute and simple | 18:59 |
| aelkner | by crontab, what is the job in question doing? | 18:59 |
| aelkner | visiting a schooltool page | 18:59 |
| aelkner | that does the sync | 18:59 |
| aelkner | ? | 18:59 |
| ignas | it lists all persons (like the xml page that lists all of them) | 18:59 |
| ignas | then lists all persons in moodle | 19:00 |
| ignas | then compares them and comes up with an action plan | 19:00 |
| ignas | like - delete 2 persons, add 3 persons | 19:00 |
| ignas | and then executes that plan | 19:00 |
| aelkner | let me see if i understand your meaning | 19:00 |
| aelkner | the cron job is a python script | 19:00 |
| aelkner | that visits schooltol, say using urllib | 19:00 |
| aelkner | and visits Moodle | 19:01 |
| aelkner | the same way | 19:01 |
| aelkner | then does the comparison | 19:01 |
| aelkner | and then visits the appropriate app, navigating the UI to insert the data | 19:01 |
| aelkner | do i get your meaning? | 19:02 |
| *** alga has joined #SchoolTool | 19:02 | |
| ignas | yes | 19:03 |
| ignas | it's simple, and you know what to do if it fails, and if you run it twice - nothing bad happens | 19:03 |
| ignas | the downside is lag | 19:03 |
| ignas | between one system getting updated and the other seeing changes | 19:03 |
| ignas | so you might have to wait 5 minutes, and hour, a day | 19:04 |
| ignas | or whatever the amount you want | 19:04 |
| aelkner | i've developed a system that does the same thing | 19:04 |
| ignas | until changes propagate | 19:04 |
| th1a | As long as it works, nobody will really complain about lag. | 19:04 |
| aelkner | it moved data from a mainfrmae to a pc sql database | 19:04 |
| aelkner | and, yes, there was a time lag | 19:04 |
| aelkner | and, yes, people didn't complain | 19:04 |
| aelkner | i had it run every two minutes | 19:05 |
| ignas | well - you should lag a bit more | 19:05 |
| ignas | schooltool will not like you listing 1000 users | 19:05 |
| ignas | every 2 minutes | 19:05 |
| th1a | Once a night would probably be fine. | 19:05 |
| aelkner | my system didn't list all users | 19:05 |
| aelkner | it had a table of changed records | 19:05 |
| aelkner | and only updated those changed since the last successful update | 19:05 |
| aelkner | i could do the same in schooltool | 19:06 |
| aelkner | have event subscribers that write to a change queue | 19:06 |
| aelkner | the cron job will only ask for those records that changed since a certain date/time | 19:06 |
| ignas | emm | 19:06 |
| ignas | i'd suggest not complicating it | 19:06 |
| aelkner | if nothing has changedd in last two minutes that would be nothing | 19:06 |
| aelkner | it was a very reliable systgem | 19:07 |
| aelkner | and only had time lag of two minutwes | 19:07 |
| ignas | i do understand it, but only having integration working IF that changelog is in the system | 19:07 |
| ignas | and only working with users added after the changelog activation | 19:07 |
| ignas | + problems with reruns | 19:07 |
| Lumiere | the other thing you could do | 19:07 |
| ignas | if you list all of them all the time | 19:07 |
| ignas | it can't fail | 19:07 |
| Lumiere | is let it run once a night | 19:07 |
| Lumiere | and let the sysadmin run it | 19:08 |
| ignas | if you only react to "added" "removed" events | 19:08 |
| Lumiere | when there was a need | 19:08 |
| ignas | you can mess it up | 19:08 |
| ignas | if you script fails | 19:08 |
| ignas | to add a person | 19:08 |
| ignas | for example, you don't know which "added" are "added" and which ones are "old" | 19:08 |
| aelkner | add and change should not be distinguished | 19:08 |
| aelkner | in either case | 19:08 |
| aelkner | the record is sought out in the target | 19:09 |
| aelkner | if it doesn't exist | 19:09 |
| aelkner | it gets added | 19:09 |
| aelkner | otherwise, it's changed | 19:09 |
| aelkner | that's how you get around that | 19:09 |
| ignas | as i have said - full sync IMHO is more reliable and more simple | 19:09 |
| ignas | it works even when any part of the system fails | 19:09 |
| ignas | but - it's up to you | 19:09 |
| aelkner | it wouldn't have been acceptable to the advertising agencies that used the product | 19:10 |
| ignas | zc.deferred is better if you want changelogs i'd say | 19:10 |
| aelkner | two minute turnaround was necessary | 19:10 |
| ignas | aelkner: i know, if it's 2 minutes, then it pretty much assumes that it won't fail | 19:10 |
| aelkner | no | 19:10 |
| ignas | because if it fails - you won't be able to fix it in 2 minutes | 19:10 |
| aelkner | it failed | 19:11 |
| aelkner | but it was rerunnable | 19:11 |
| aelkner | so the cuase of failure could be fixed | 19:11 |
| aelkner | and it would pick up where it left off | 19:11 |
| ignas | you see | 19:11 |
| ignas | that requires schooltool to have additional state | 19:11 |
| ignas | the synchronizer to have additional state | 19:11 |
| ignas | which adds complexity | 19:11 |
| ignas | prematurely i would say | 19:12 |
| ignas | and yes - i understand that you already did it once | 19:12 |
| ignas | just that if we could avoid the "moodle integration" module in schooltool, while still having moodle integration solution | 19:13 |
| ignas | it would be a bit more useful ;) | 19:13 |
| aelkner | that's why i like your crontab idea | 19:13 |
| ignas | and that's why i don't like your "changelog" idea | 19:13 |
| aelkner | i don't understand you objection to having a changelog | 19:14 |
| aelkner | as a matter of fact | 19:14 |
| ignas | well - then changelog has to be a part of schooltool | 19:14 |
| ignas | always | 19:14 |
| aelkner | that could be a general solution to any number of problems | 19:14 |
| ignas | no changelog - no integration | 19:14 |
| ignas | and it's not a "view" | 19:14 |
| ignas | it's a data structure | 19:14 |
| aelkner | i'm suggesting a data structure | 19:15 |
| aelkner | actually, it could be used for any object type we wanted to support | 19:15 |
| aelkner | it would have a datetime together with the object that was added or changed | 19:15 |
| ignas | and would make evolution difficult, sql integration difficult, refactoring difficult ... and disable ZODB packing | 19:16 |
| aelkner | a view that says, "give me all changes since Jun 09, 2008 1:00PM" could devlier xml | 19:16 |
| ignas | in some cases | 19:16 |
| ignas | and the xml would include what? object __names__, UID's, URL's, object exports in XML? | 19:17 |
| aelkner | object exports | 19:17 |
| aelkner | ids would be part of it, yes | 19:17 |
| aelkner | anything usefult to anyone outside of schooltool | 19:17 |
| aelkner | like Moodle or Drupal | 19:17 |
| ignas | emm, so REST revisited | 19:18 |
| ignas | for everything | 19:18 |
| th1a | I think we're drifting off topic... | 19:18 |
| aelkner | what's the topic, then? | 19:18 |
| th1a | Certainly not a general object export. | 19:19 |
| th1a | Or general changelog. | 19:19 |
| aelkner | the task at hand requires a combination of things | 19:20 |
| aelkner | i think you like jsut having schooltool use TestBrowser immediately | 19:20 |
| aelkner | so exports and changelog doesn't com into play | 19:20 |
| aelkner | but ignas suggested that this approach would be frought with peril | 19:20 |
| aelkner | as the transaction could time out or something | 19:21 |
| th1a | I defer to his judgement. | 19:21 |
| aelkner | well, that's what got us discussing the other things | 19:22 |
| aelkner | i'm not going to think about this anymore until i get CAS working | 19:23 |
| ignas | it's zc.assync i think not zc.deferred | 19:26 |
| ignas | async | 19:26 |
| ignas | aelkner: even if you go for changelog - i'd suggest adding person.log to schooltool, and adding 3 subscribers for IObjectAdded/Modified/Removed | 19:28 |
| ignas | that would use python logging | 19:28 |
| ignas | to log the person __name__ + operation | 19:28 |
| ignas | and interact with the text script | 19:28 |
| th1a | It certainly seems like zc.async would be useful in a variety of contexts. | 19:28 |
| ignas | https://answers.launchpad.net/schooltool/+question/35569 - is the answer "No." ? | 19:30 |
| *** mattva01 has quit IRC | 19:31 | |
| th1a | I'll answer it. | 19:31 |
| *** jelkner has quit IRC | 19:40 | |
| ignas | th1a, Lumiere: http://www.iam.unibe.ch/~scg/OORP/, http://www.iam.unibe.ch/~scg/OORP/OORP.pdf if you will have some free time - read it, and make the interns read it ;) | 20:44 |
| Lumiere | ignas: looks interesting | 20:54 |
| ignas | Read it. It will make it easier for you to understand me, and things I am worried about... | 20:55 |
| Lumiere | I forwarded it to the cando dev mailing list | 20:56 |
| ignas | thanks | 20:56 |
| Lumiere | I'll take a look at some point | 20:56 |
| Lumiere | that lp question | 20:57 |
| Lumiere | is there any reason not to have a package for cal-only? | 20:57 |
| ignas | yes, we don't have time for that | 20:57 |
| Lumiere | schooltool-minimal-cal? | 20:57 |
| Lumiere | ok | 20:57 |
| Lumiere | not that it matters | 20:58 |
| ignas | yep, no time for that, sorry, i can explain you how to do it, I can even help you do it... I can help anyone do that | 20:58 |
| ignas | but everyone comes and says - "can you do it?" | 20:58 |
| ignas | and runs away as soon as I am mentioning "You could do that, i can explain how!" | 20:59 |
| ignas | so apparently - nobody needs schoolbell enough to write some code :/ | 20:59 |
| ignas | i mean - an intern could hack a buggy but working schoolbell in a week ;) without tests ;) | 21:00 |
| ignas | without touching schooltool code even ;) | 21:00 |
| ignas | (every few of months this task gets easier and easier to do) | 21:01 |
| th1a | Jeez... amazon.com is down again? | 21:01 |
| th1a | ...and back. | 21:02 |
| ignas | ooh "Http/1.1 Service Unavailable" | 21:02 |
| th1a | Bouncing up and down. | 21:03 |
| *** ignas has quit IRC | 21:33 | |
| *** alga has quit IRC | 21:56 | |
| *** wbrady has quit IRC | 22:13 | |
| *** mgedmin has quit IRC | 22:23 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!