| *** alga has quit IRC | 02:47 | |
| *** ignas has quit IRC | 04:26 | |
| *** menesis has joined #schooltool | 08:39 | |
| *** alga has joined #schooltool | 09:30 | |
| *** ignas has joined #schooltool | 11:52 | |
| *** ignas has quit IRC | 12:07 | |
| *** menesis has quit IRC | 12:09 | |
| *** menesis has joined #schooltool | 12:49 | |
| *** ignas has joined #schooltool | 13:08 | |
| *** Aiste has joined #schooltool | 14:51 | |
| *** Aiste_ has joined #schooltool | 14:51 | |
| *** th1a has joined #schooltool | 15:20 | |
| *** yvl has joined #schooltool | 16:16 | |
| yvl | morning th1a | 16:21 |
|---|---|---|
| th1a | Hi yvl. | 16:21 |
| yvl | some pre-meeting drama... I managed to get sick | 16:21 |
| th1a | I see. | 16:22 |
| th1a | How are you feeling? | 16:22 |
| yvl | quite... sick, for the lack of a better word | 16:22 |
| th1a | Random virus? | 16:23 |
| th1a | Something specific? | 16:23 |
| yvl | probably common cold that went to later stages | 16:23 |
| yvl | I don't know english names for them | 16:24 |
| yvl | for some reason it hit me hard | 16:24 |
| th1a | I understand. | 16:24 |
| yvl | I mean - nose, throat, ears :) | 16:24 |
| th1a | Sure. | 16:24 |
| yvl | well, I'm actually at the point where (I hope) I'm getting better | 16:25 |
| yvl | so that's at least some comfort | 16:26 |
| th1a | Better than getting worse! | 16:26 |
| *** replaceafill has joined #schooltool | 16:27 | |
| th1a | Hi replaceafill, aelkner, menesis. | 16:31 |
| replaceafill | good morning/afternoon | 16:31 |
| aelkner | morning | 16:31 |
| menesis | hi | 16:31 |
| th1a | OK... one thing I want to make sure and discuss is https://answers.launchpad.net/schooltool/+question/131776 | 16:33 |
| th1a | It seems like we should be able to quickly save these guys a lot of bother by hacking in demographics support. | 16:33 |
| th1a | Even if it is not pretty. | 16:33 |
| yvl | yeah | 16:34 |
| th1a | Esp. since it isn't for human readability. | 16:34 |
| yvl | the least we can do is add another randomly named sheet to the xls | 16:35 |
| yvl | "Additional demographics data" | 16:35 |
| th1a | Does this use our standard xls otherwise? | 16:35 |
| yvl | yes | 16:35 |
| yvl | ST importer sould ignore sheets it doesn't recognises | 16:35 |
| yvl | another way would be first adding demographics import/export | 16:36 |
| th1a | So to do it "right," we'd just have to have the script first look at the fields, and generate columns first? | 16:36 |
| th1a | I thought we did? | 16:36 |
| yvl | hmm, let me check | 16:36 |
| th1a | Well, you have to set up the demographics manually. | 16:36 |
| th1a | It doesn't create the custom demographics based on the spreadsheet. | 16:37 |
| th1a | If they match it works. | 16:37 |
| th1a | So it is finicky. | 16:37 |
| replaceafill | the importer looks for the default demographics i guess | 16:37 |
| yvl | I think the demographics import is limited | 16:37 |
| yvl | no ethnicity, for example | 16:37 |
| th1a | Based on the spreadsheet or the code? | 16:37 |
| yvl | the importer code | 16:38 |
| th1a | My recollection was that you could customize the demographics, export it, recreate the same custom demographics in a clean database, and import it. | 16:38 |
| menesis | The XLS exporter does export Gender, Language, and even custom demographic fields | 16:38 |
| yvl | and here are the old demographics fields: | 16:39 |
| yvl | fields = ( | 16:39 |
| yvl | 'User Name', 'Prefix', | 16:39 |
| yvl | 'First Name', 'Middle Name', 'Last Name', | 16:39 |
| yvl | 'Suffix', 'Preferred Name', 'Birth Date', 'Gender', | 16:39 |
| yvl | 'Password', 'ID', 'Ethnicity', 'Language', | 16:39 |
| yvl | 'Place of birth', 'Citizenship' ) | 16:39 |
| th1a | Hm. | 16:39 |
| yvl | no, wait, I think that's our exported fields | 16:40 |
| menesis | but the importer does not support custom fields. it is fragile, some time ago prefix and suffix were added and an older XLS could not be imported | 16:41 |
| th1a | Hm. | 16:42 |
| th1a | Well, that ought to be improved regardless. | 16:42 |
| th1a | OK, let's table that for the moment and see if we can jam it in this week -- either a quick hack or real fix. | 16:43 |
| th1a | replaceafill, how was your week? | 16:44 |
| replaceafill | th1a, i'm almost done with the preferences work, i just have to make the changes i asked you about on friday | 16:44 |
| replaceafill | about where to put the buttons and stuff | 16:45 |
| replaceafill | renaming a view, etc | 16:45 |
| replaceafill | yvl, i have a question | 16:45 |
| replaceafill | it's mostly about the way we code | 16:46 |
| replaceafill | if i have a method in a class like: | 16:46 |
| replaceafill | gradebook.browser.gradebook.SectionFinder.processColumnPreferences | 16:46 |
| replaceafill | and later in GradebookOverview I see the call self.processColumnPreferences() | 16:47 |
| replaceafill | and then i get some self.* attributes on my class object | 16:47 |
| replaceafill | so i was wondering | 16:47 |
| replaceafill | if it would be easier to set up each attribute in a single call | 16:48 |
| replaceafill | like self.total_hide = self.getTotalHidePref() | 16:49 |
| replaceafill | so i dont have to follow another method to find out which attributes have been set | 16:49 |
| aelkner | easier? sounds REALLY inconvenient | 16:49 |
| replaceafill | aelkner, if i'm reading GradebookOverview, and processColumnPreferences does a lot of setting | 16:50 |
| replaceafill | i have to track down what it does | 16:50 |
| replaceafill | i mean, it's not a big deal | 16:50 |
| replaceafill | it was just kind of annoying | 16:50 |
| yvl | hmm | 16:50 |
| aelkner | i'm not sure how having a convenience function like that could be annoting | 16:51 |
| aelkner | anoying | 16:51 |
| aelkner | it does the job that needs doing | 16:51 |
| yvl | I'm still trying to grasp the reason for that part... | 16:51 |
| replaceafill | to me, it does too much | 16:51 |
| replaceafill | but as you say, it does what it has to do | 16:51 |
| yvl | from the first glance (though I'm probably wrong) | 16:52 |
| yvl | it seems that you want an IColumnPreferencesSomething adapter | 16:52 |
| yvl | that does that part | 16:52 |
| replaceafill | yes | 16:53 |
| aelkner | that would be better zope practice, but just as complicated (if not more) to follow | 16:53 |
| aelkner | i wouldn't be against it though | 16:53 |
| replaceafill | again, it was just a feeling i had while i was working on that part | 16:53 |
| replaceafill | just wanted to mention it | 16:54 |
| aelkner | might be a good idea to replace the method with an adapter | 16:54 |
| replaceafill | aelkner, yes | 16:54 |
| aelkner | and the class would just then have one attribute for the adapted context | 16:54 |
| replaceafill | the method also does a little view login with the apply_all_colspan part | 16:54 |
| replaceafill | s/login/logic | 16:55 |
| yvl | there are just those weird places | 16:55 |
| yvl | like this one: self.average_hide = prefs.get('hide', False) | 16:55 |
| aelkner | yes, it calculates colspans based on absence/presence of colcs | 16:55 |
| aelkner | cols | 16:55 |
| yvl | wouldn't it be easier if some class just had an attribute: average_hide = False | 16:55 |
| yvl | oh, no | 16:56 |
| replaceafill | ? | 16:57 |
| yvl | ok, don't mind me :) | 16:57 |
| replaceafill | th1a, other than that, i have no more questions, will work on the remaining part today | 16:57 |
| yvl | seriously, Alan, this type of code is hard to follow for a developer that didn't wrote it | 16:57 |
| replaceafill | yvl++ | 16:57 |
| aelkner | i agree it needs refactoring | 16:58 |
| replaceafill | well, i'm in that part, so i will give a try | 16:58 |
| aelkner | go for it | 16:58 |
| replaceafill | and ask your opinion when i | 16:58 |
| replaceafill | 'm done | 16:58 |
| replaceafill | oops | 16:58 |
| th1a | replaceafill: Do you think you could do this demo export at the same time? | 16:58 |
| th1a | export/import | 16:59 |
| th1a | Not literally at the same time. | 16:59 |
| aelkner | btw, it's not just that part that needs refactoring | 16:59 |
| th1a | I meant also this week. | 16:59 |
| aelkner | the whole view and Gradebook context is really old code | 16:59 |
| replaceafill | th1a, sure | 16:59 |
| th1a | replaceafill: could you do the demo stuff first? | 17:00 |
| replaceafill | th1a, just to be clear, we have to put demographics in the database exporter, correct? | 17:00 |
| th1a | Well.. | 17:00 |
| replaceafill | the one Trevor (from launchpad) is using | 17:00 |
| th1a | Yes, there are two questions, I guess. | 17:00 |
| yvl | umm, first check what data is actually there | 17:00 |
| yvl | https://launchpad.net/ubuntu/gutsy/+source/schooltool/0.11.4-3ubuntu2 | 17:00 |
| th1a | We need to import it, | 17:01 |
| yvl | then get the exporter bzr+ssh://bazaar.launchpad.net/~schooltool-owners/schooltool/database_exporter/ | 17:01 |
| th1a | immediately get the database recovery script to export it, | 17:01 |
| replaceafill | yvl, thanks | 17:01 |
| th1a | and then in the medium term get the regular exporter to export it. | 17:01 |
| yvl | and see mock_0_11_4.py | 17:01 |
| yvl | for some reason I can't find ethnicity data in old databases | 17:02 |
| replaceafill | will be interesting to see 0.11 code :) | 17:03 |
| replaceafill | th1a, will do that, and if i get some time, i'd like to continue the active statuses (or enrollment statuses) work | 17:03 |
| th1a | Yes, those are all things we need. | 17:04 |
| replaceafill | ok th1a, that's it from me | 17:04 |
| replaceafill | thanks yvl and aelkner | 17:04 |
| th1a | Thanks replaceafill. | 17:05 |
| th1a | OK, aelkner, I looked at your screenshots. | 17:05 |
| th1a | I'm a bit confused. | 17:06 |
| th1a | Are there separate student and teacher edit views? | 17:06 |
| aelkner | what does cambodia do, the same thing, right? | 17:06 |
| th1a | Oh... | 17:06 |
| replaceafill | yes | 17:07 |
| th1a | Well... | 17:07 |
| th1a | I suppose we should talk about the way this should end up in core. | 17:07 |
| aelkner | exactly | 17:07 |
| th1a | I'm thinking that we'll definitely want to move to "Add Student" "Add Teacher" | 17:07 |
| th1a | But those are for convenience. | 17:08 |
| th1a | So *in core* at least, subsequently you should be able to view and edit them with a generic add and edit person view. | 17:09 |
| th1a | Make sense? | 17:09 |
| th1a | Is that what you're thinking? | 17:09 |
| th1a | In a more customized configuration, we can maintain separate edit views. | 17:10 |
| aelkner | keep in mind that amogst the stuff that i stole from cambodia was the person container views as well | 17:10 |
| aelkner | also, navigation | 17:10 |
| th1a | I'm just trying to sort out the core from the custom parts here. | 17:10 |
| replaceafill | aelkner, do your forms put people in groups? | 17:11 |
| replaceafill | i mean the Add Student in Students and so on? | 17:11 |
| aelkner | yes, like cambodia | 17:11 |
| replaceafill | th1a, i wonder if that's ok for core | 17:11 |
| aelkner | i think those views make a lot of sense for the core user | 17:11 |
| replaceafill | it's an assumption | 17:11 |
| replaceafill | (if that's the right word) :( | 17:12 |
| aelkner | also, demos by group which i created in my new schooltool branch | 17:12 |
| aelkner | did my note to the developers list go though? | 17:12 |
| th1a | Even if you want someone to be a student and teacher, they don't have to be both at the moment of creation. | 17:12 |
| th1a | So that's why I'm saying we don't in core want to have completely separate view and edit views for the two groups. | 17:13 |
| th1a | I mean, in a sense, allowing someone to be a student and teacher is a dubious decision, it makes things more complicated for us. | 17:14 |
| th1a | It is a significant sunk cost. | 17:14 |
| th1a | But at this point, we should at least maintain the advantage of it in core. | 17:14 |
| aelkner | th1a, could i broach one concept a second | 17:14 |
| aelkner | i think we can support more than one group membership, but come up with a | 17:15 |
| aelkner | rule for which group really applies, like if you're a teacher, you're a teacher | 17:15 |
| aelkner | if you're not a teacher and you are a student, then you are a student | 17:16 |
| aelkner | if you are neither, and you are an admin, then you're that | 17:16 |
| aelkner | but as for which demos to show in person forms | 17:16 |
| aelkner | teacher, then student, then admin | 17:17 |
| aelkner | i mean one OR the other | 17:17 |
| th1a | Well, that's all completely unnecessary. | 17:17 |
| th1a | Because you can just create a form which checks to see which fields are relevant to that person. | 17:17 |
| th1a | No problem. | 17:17 |
| th1a | It just keeps you from doing a custom layout in our current system. | 17:18 |
| replaceafill | student + admin! (we have a use case for that one?) | 17:18 |
| th1a | Well, look. | 17:18 |
| th1a | Let's only talk about demographics here. | 17:18 |
| th1a | We have no custom demographic forms in core right now anyway | 17:18 |
| th1a | So there is no reason not to keep it very simple and just have the form check to see if the field is relevant. | 17:19 |
| th1a | Essentially, I wanted to do it that way to avoid opening up this can of worms. | 17:19 |
| th1a | Which is generally NOT A PROBLEM. | 17:20 |
| aelkner | when you say, "check to see if the field is relevant", how do you mean? | 17:20 |
| th1a | Person is a student. | 17:20 |
| th1a | For example. | 17:21 |
| aelkner | a student and a teacher? | 17:21 |
| th1a | Just a student. | 17:21 |
| th1a | When the edit form is rendering it checks each field to see if that field is relevant to a student. | 17:22 |
| th1a | Place of Birth, yes. | 17:22 |
| aelkner | that's what my forms do | 17:22 |
| th1a | I hope so! | 17:22 |
| aelkner | they use the new filter_group_id method i made in my schooltool branch | 17:22 |
| aelkner | yvl, did you have a chance to look at that? | 17:22 |
| th1a | My whole point here is that it doesn't *require* two separate forms. | 17:22 |
| th1a | Right? | 17:23 |
| aelkner | th1a, that's part of what i did in niepa, i made the forms very table-driven | 17:23 |
| aelkner | so the same base class/template applies to both case | 17:23 |
| yvl | no, aelkner | 17:24 |
| yvl | I didn't yet | 17:24 |
| aelkner | i understand, you're not feeling well | 17:24 |
| aelkner | anyway, the edit view classes set the group that is used by the base class | 17:25 |
| aelkner | to dynamically generate the fieldset with the demos | 17:25 |
| aelkner | using the filter_group_id method on the demo fields container | 17:26 |
| aelkner | also, the add views do the same | 17:26 |
| aelkner | the add views must know the group in question in order to set it | 17:26 |
| aelkner | having separate links to get to the add forms accomplishes that | 17:27 |
| yvl | oh, sorry aelkner, but please remake the core part | 17:27 |
| aelkner | the edit forms are called up from the custom person container views | 17:27 |
| yvl | use relationships instead of ids | 17:27 |
| th1a | Not to hammer this into the ground, but you could just do a generic version of that as well. | 17:27 |
| th1a | Correct? | 17:27 |
| aelkner | no, it's a good point, but what about the container views in cambodia which i put in niepa? | 17:28 |
| th1a | That just looked at what groups the person was a member of? | 17:28 |
| aelkner | they are specific to group | 17:28 |
| th1a | I'm not immediately worried about that. | 17:28 |
| th1a | I'm just trying to make sure we aren't marching off in different directions, and we seem to be ok. | 17:28 |
| th1a | So let's move on. | 17:28 |
| th1a | aelkner, you may go ahead with your report. | 17:29 |
| aelkner | well, we';re kind of in the middle of it already :) | 17:29 |
| th1a | Of course. | 17:30 |
| aelkner | i added two features to core, BoolFieldDescription | 17:30 |
| aelkner | and limit_group_ids, filter_group_id | 17:30 |
| aelkner | then i used them in niepa in the person views we were just discussing | 17:30 |
| aelkner | so that the demo fields come out onm the form according to the group | 17:31 |
| aelkner | i poached the person container/navigation code from cambodia to help the user add | 17:31 |
| aelkner | teachers/students more conveniently | 17:31 |
| aelkner | also, i think that kind of functionality would be useful in core | 17:32 |
| aelkner | so that's part of what i thought we would discuss today | 17:32 |
| th1a | Did we? | 17:32 |
| aelkner | we did, but that discussion still feels like an open one | 17:33 |
| aelkner | anyway, as for niepa | 17:33 |
| aelkner | there is only one part left to do for them to have forms for entering census data | 17:33 |
| aelkner | that is the classroom part | 17:33 |
| th1a | For resources. | 17:34 |
| aelkner | yes | 17:34 |
| aelkner | if we want niepa to add attributes to classroom resources that are not in core | 17:34 |
| aelkner | i will need to write a custom view class, but also i would need to have a place to put | 17:35 |
| aelkner | the additional attributes in a classroom resource object, like in annotations? | 17:35 |
| yvl | (btw, aelkner, you accidentally committed import pdb; pdb.set_trace in src/schooltool/niepa/person/person.py) | 17:35 |
| th1a | aelkner: Or we could just do user customizable "demographics" for resources. | 17:36 |
| aelkner | yvl, does the failed test get there? | 17:36 |
| aelkner | th1a, i thought you might be thinking that, but how? | 17:36 |
| *** alga has quit IRC | 17:36 | |
| yvl | didn't check | 17:36 |
| th1a | copy/paste? | 17:36 |
| aelkner | yvl, i guess i commited a pdb, but i still have tests to fix anyway, so i'll get rid of that in tme | 17:37 |
| yvl | ok then :) | 17:37 |
| aelkner | i was just hoping you could help me with the schoolyear add problem | 17:37 |
| yvl | just trying to help ;) | 17:37 |
| aelkner | :) | 17:37 |
| aelkner | that was REALLY helpful :) | 17:37 |
| aelkner | th1a, demographics are linked to basicperson objects in core | 17:38 |
| aelkner | there are adapters and all that | 17:38 |
| th1a | I mean, we have customizable demographics for person, so the same basic approach should work for resources, right? | 17:38 |
| aelkner | would we want to keep resource demos in a separate container off of the root? | 17:39 |
| yvl | the approach - yes :) | 17:39 |
| aelkner | or would we want to add them to the existing container | 17:39 |
| aelkner | and have a flag that tells us that the demo field is for classroom resources? | 17:39 |
| yvl | oh, I so know how I want that to be done in the future :) | 17:40 |
| yvl | developers should not care where the container lies in such cases | 17:40 |
| aelkner | IClassRoomDemos(classroom)? | 17:40 |
| aelkner | if by developer, you mean me, then i will need to worry about making the adapters | 17:41 |
| aelkner | and where the data is kept | 17:41 |
| yvl | and I wish you wouldn't need to | 17:41 |
| aelkner | but you are very busy with other core projects, and i'm only too happy to help :) | 17:42 |
| aelkner | though i need you guidance on decisions to made here | 17:43 |
| yvl | then use th1a 's suggestion I guess :) | 17:44 |
| th1a | That seems safest. | 17:44 |
| yvl | add demographics.py to schooltool/recourses | 17:44 |
| yvl | simply import field descriptions from basicperson | 17:44 |
| yvl | and a big fat XXX: why is this dependency on basicperson necessary???? | 17:44 |
| aelkner | yeah, why? | 17:45 |
| replaceafill | :D | 17:45 |
| aelkner | why are those classes in basicperson in the first place? | 17:45 |
| aelkner | why not in the demograpics package? | 17:45 |
| yvl | oh, just don't ask | 17:45 |
| aelkner | also, basicperson defines (and initializes in AppInit) | 17:45 |
| aelkner | the IDemograpicsFields container that is off of the root | 17:46 |
| yvl | just name it IResourceCustomFields or something | 17:46 |
| aelkner | so for resources, what to do about the container and AppInit stuff | 17:47 |
| *** Aiste_ has quit IRC | 17:47 | |
| yvl | make your own (I mean specific for resources) | 17:47 |
| yvl | copy-paste | 17:47 |
| aelkner | where do we house the ResourceCustomFields objects? | 17:48 |
| aelkner | in a spearate continer off of root? | 17:48 |
| yvl | make everything identical to IBasicPerson | 17:48 |
| yvl | just use resources | 17:48 |
| yvl | so yes, separate container in root | 17:48 |
| aelkner | so a separate container then? | 17:48 |
| yvl | 'schooltool.resource.custom_fields' and 'schooltool.resource.custom_data' | 17:48 |
| aelkner | oh, sorry, already answered | 17:49 |
| yvl | It should be easier to refactor this out once we develop a mechanism to add extra fields to objects | 17:49 |
| yvl | (say - courses - why not??? ) | 17:50 |
| aelkner | demo fields could all live in one container in the future with flags on the demo fields | 17:50 |
| aelkner | that tell which type of demo and the adapters could find the appropriate fields, right? | 17:51 |
| yvl | probably something like that | 17:51 |
| yvl | but that's in the future... | 17:51 |
| aelkner | for now, create the new container in the resource package | 17:52 |
| yvl | yes | 17:52 |
| aelkner | that will be my work for this week | 17:52 |
| aelkner | in the meantime, could you please look at my branches and respond to the thread | 17:53 |
| aelkner | i started in the developers list? | 17:53 |
| aelkner | yvl, that's when you're felling better, of course | 17:53 |
| th1a | Thanks, aelkner. | 17:54 |
| yvl | umm, I already asked to change ids to relationships | 17:54 |
| yvl | as for adding new <...>, sure, just gonna lie down for a while | 17:54 |
| aelkner | yvl, can't use relationships in limit_group_ids | 17:55 |
| aelkner | the filter applies year over year | 17:55 |
| aelkner | but groups live within a given school year | 17:55 |
| aelkner | so putting a relationship to a transitory object like a group within a school year | 17:55 |
| aelkner | would not work | 17:55 |
| aelkner | whereas saying | 17:56 |
| yvl | yes, of course | 17:56 |
| aelkner | "this demo field is for teachers, regardless of year" | 17:56 |
| yvl | this implementation is good for the grant project | 17:56 |
| aelkner | works well in my opinion | 17:56 |
| yvl | not good enough for core, sorry | 17:56 |
| aelkner | how would it be done otherwise? | 17:56 |
| yvl | the UI part? | 17:57 |
| aelkner | the limit_group_ids data model part | 17:57 |
| yvl | data model - simple | 17:57 |
| yvl | add a relationship between field an all groups in specific years | 17:57 |
| yvl | if you want it in all years | 17:58 |
| yvl | it's not that insane to think that *specific* demographics tracked for students or teachers will *change* over the years | 17:59 |
| yvl | so on the data model, it strictly must be a group-field relationship | 18:00 |
| aelkner | and the UI? | 18:00 |
| yvl | that is another, and a very good question | 18:01 |
| yvl | one of the simplest things you can do, is filter by the active school year | 18:01 |
| yvl | (and probably add the year to the titles in the dropdown) | 18:02 |
| yvl | [ 2009 / teachers ] | 18:02 |
| yvl | [ 2009 / students ] | 18:02 |
| yvl | etc | 18:02 |
| aelkner | and when we are in the AppInit method, creating custom demo fields by group | 18:02 |
| aelkner | and there is no active school year yet? | 18:03 |
| yvl | hmm | 18:03 |
| yvl | when is the default year created? | 18:03 |
| aelkner | what default year? | 18:03 |
| yvl | by users, manually, doh. | 18:03 |
| aelkner | :) | 18:04 |
| th1a | I generally prefer using relationships, but I don't know if the year by year aspect makes sense here. | 18:04 |
| aelkner | i understand preferring relationships, but can't ids be useful in some cases | 18:05 |
| aelkner | like 'teachers', 'students', 'admin...' which are special | 18:05 |
| yvl | hmm, you can write hooks to events | 18:05 |
| yvl | as in group created events | 18:05 |
| yvl | if the group is special, just relate it to the desired fields | 18:06 |
| yvl | in the event subscriber, instead of AppInit | 18:06 |
| aelkner | when i'm in AppInit, trying to create custom demo fields for students but there is no students group yet | 18:06 |
| aelkner | what do i do there? | 18:06 |
| yvl | see InitGroupsForNewSchoolyear | 18:06 |
| yvl | nothing | 18:06 |
| aelkner | that gets called later | 18:06 |
| yvl | just create the custom demo fields | 18:06 |
| aelkner | i don't want to create custom demo fields each time a schoolyear is added | 18:07 |
| aelkner | just once, when the app is created | 18:07 |
| yvl | no | 18:07 |
| yvl | create the demo fields when app is started | 18:07 |
| yvl | but relate them to groups when the groups are being created | 18:08 |
| aelkner | how would i know which group to relate to which demo field at that time? | 18:08 |
| yvl | ah, I see your point now :) | 18:08 |
| aelkner | hehe | 18:08 |
| yvl | guesswork is ok there | 18:08 |
| yvl | I thought that your point was - people enter persons before creating the schoolyear | 18:09 |
| aelkner | btw, this by no means seems SIMPLER | 18:09 |
| aelkner | no the app creates demos in AppInit | 18:09 |
| aelkner | th1a, do you think we need to have different student demos by school year? | 18:10 |
| aelkner | if so, i can see the need for all this complexity | 18:10 |
| th1a | I think that's pretty obscure. | 18:10 |
| th1a | It is more likely that you'd add than subtract. | 18:11 |
| aelkner | as it s, i already have a working implementation for group_id specific demos | 18:11 |
| th1a | Hm. | 18:11 |
| th1a | Well, here's the other thing. | 18:11 |
| th1a | We can also remove things from the add/edit fields but still display deprecated fields that aren't associated currently with the group but that have old values. | 18:12 |
| th1a | That's easy enough. | 18:12 |
| aelkner | what about the group_id (already working) versus active schoolyear group relationship qustion? | 18:13 |
| yvl | ok | 18:13 |
| yvl | let's go with group_id's | 18:13 |
| yvl | I'll have to refactor this out some time | 18:13 |
| yvl | if I'm to ever fix the default groups mess | 18:13 |
| yvl | but it's a good point | 18:14 |
| aelkner | default groups mess? | 18:14 |
| yvl | teachers, admins, etc. | 18:14 |
| aelkner | what's the mess? | 18:14 |
| yvl | don't want to get into it now | 18:14 |
| aelkner | oh, touched a sore nerve? :) | 18:14 |
| yvl | no, I'm just sick ;)))) | 18:15 |
| th1a | That could go on for another hour. | 18:15 |
| th1a | menesis: Still awake? | 18:15 |
| th1a | Thanks aelkner. | 18:15 |
| menesis | th1a: yes | 18:16 |
| th1a | So we're waiting for a reply from Mathias now? | 18:16 |
| menesis | Jonathan replied me two times saying that he talked to Daniel, then that Matthias should help us, but I got no replies from either of them | 18:17 |
| replaceafill | yvl, do you have a 0.11 database with data? | 18:17 |
| replaceafill | yvl, or i could install edubuntu 6 and fill it out, correct? | 18:18 |
| replaceafill | oopss sorry for interrupting menesis | 18:18 |
| menesis | I have worked on the packages a little to catch up with ZTK 1.0, but am not uploading them since they contain no noteworthy changes, but be less work when I know where to upload | 18:19 |
| th1a | OK. Sounds good. | 18:20 |
| th1a | I'll poke people if we get stuck at this point. | 18:21 |
| th1a | Any last words? | 18:21 |
| th1a | Have a great week, gentlemen! | 18:22 |
| th1a | Get better, yvl. | 18:22 |
| * th1a drops the bag of gravel. | 18:22 | |
| replaceafill | thanks everybody | 18:22 |
| replaceafill | get well yvl | 18:22 |
| aelkner | greate week everyone | 18:22 |
| aelkner | yes, feel better yvl | 18:22 |
| yvl | thanks guys | 18:22 |
| yvl | good week to you | 18:23 |
| yvl | and replaceafill - I'll send a small db I made when I had 0.11 running | 18:23 |
| replaceafill | yvl, great! thanks | 18:23 |
| yvl | there you go :) | 18:25 |
| replaceafill | thanks yvl | 18:25 |
| yvl | replaceafill, by the way if you want to run the old ST | 18:33 |
| yvl | you just need python 2.5 or lower | 18:33 |
| yvl | or, on gutsy, it should work out-of-the box | 18:34 |
| replaceafill | i was thiking of edubuntu 6 (the first time i saw schooltool) :D | 18:34 |
| yvl | aelkner, I just checked out schooltool.niepa | 18:46 |
| yvl | and at least manually, school year add view works | 18:47 |
| yvl | ah, I see, it's the tests :) | 18:50 |
| *** ignas has quit IRC | 19:01 | |
| yvl | aelkner, by the way, the add view crashes when you enter invalid data | 19:04 |
| yvl | '01-01-2010' is incorrect, you need to use ISO format: '2010-01-01' | 19:04 |
| replaceafill | yvl, out of blue question: does you have any experience with solid state drives? | 19:05 |
| replaceafill | i want to buy a new laptop | 19:05 |
| replaceafill | :) | 19:05 |
| yvl | umm, I'm going to go with... no, I've no experience with that :) | 19:09 |
| replaceafill | ah ok | 19:09 |
| * replaceafill wonders if they're worth it or they're just buzz | 19:10 | |
| * th1a has used a USB stick. | 19:29 | |
| *** yvl has quit IRC | 19:36 | |
| th1a | I wouldn't have any concerns about getting a solid state drive. | 19:38 |
| replaceafill | th1a, i wonder about the performance benefit vs storage space | 19:42 |
| replaceafill | i mean, like is it worth to have 80 GB SSD vs a 500 GB SATA? | 19:43 |
| replaceafill | i don't use much space anyway | 19:43 |
| th1a | That would be the case for me -- I don't need that much space anyhow. | 19:44 |
| th1a | Particularly for my work computer. | 19:45 |
| *** menesis has quit IRC | 20:13 | |
| *** menesis has joined #schooltool | 20:55 | |
| *** replaceafill has quit IRC | 21:01 | |
| *** alga has joined #schooltool | 21:20 | |
| *** replaceafill has joined #schooltool | 21:29 | |
| *** menesis has quit IRC | 22:39 | |
| *** menesis has joined #schooltool | 22:53 | |
| *** menesis1 has joined #schooltool | 22:58 | |
| *** menesis has quit IRC | 22:58 | |
| *** menesis has joined #schooltool | 23:15 | |
| *** menesis1 has quit IRC | 23:17 | |
| *** replaceafill has quit IRC | 23:21 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!