| *** replaceafill has joined #schooltool | 00:23 | |
| *** jelkner has quit IRC | 01:05 | |
| *** replaceafill has quit IRC | 01:05 | |
| *** replaceafill has joined #schooltool | 01:12 | |
| *** replaceafill has quit IRC | 01:14 | |
| *** jstraw has quit IRC | 01:21 | |
| *** replaceafill has joined #schooltool | 01:58 | |
| *** replaceafill has quit IRC | 02:23 | |
| *** aelkner has joined #schooltool | 02:25 | |
| *** replaceafill has joined #schooltool | 04:58 | |
| *** replaceafill has quit IRC | 05:07 | |
| *** aelkner has quit IRC | 06:26 | |
| *** aelkner has joined #schooltool | 06:27 | |
| *** yvl has joined #schooltool | 10:48 | |
| *** mgedmin has joined #schooltool | 13:10 | |
| *** th1a has joined #schooltool | 15:31 | |
| th1a | yvl: ayt? | 15:33 |
|---|---|---|
| yvl | hi th1a | 15:35 |
| th1a | hi | 15:35 |
| *** aelkner_ has joined #schooltool | 15:35 | |
| th1a | Can you reproduce the paragraphing issue? | 15:35 |
| th1a | I presume you need to look for carriage returns in the text and split it into multiple paragraph objects? | 15:36 |
| *** aelkner has quit IRC | 15:37 | |
| yvl | yes | 15:38 |
| yvl | btw, PDF reports already handle this... | 15:38 |
| th1a | So you need to see the examples. | 15:39 |
| yvl | just to be sure; | 15:39 |
| th1a | aelkner_: ayt? | 15:39 |
| yvl | I will do the fix anyway, and Ignas will merge when he's available | 15:40 |
| th1a | What fix are you going to do... I'm a little confused now. | 15:41 |
| yvl | split the text by carriage returns and put those into separate <p> tags | 15:44 |
| yvl | it should do the trick | 15:44 |
| th1a | OK. | 15:45 |
| *** ignas has joined #schooltool | 16:10 | |
| *** ignas changes topic to "SchoolTool development | IRC logs at http://source.schooltool.org/irclogs/ | SchoolTool Dev meetings Mon, 14:30 UTC (16:30 EET, 9:30 EST) | Use http://paste.lisp.org/new/schooltool for pasting | Write more unit and functional tests! Yes, you! | Build Status: http://source.schooltool.org/buildbot | User stories wanted for tjTalk module http://www.launchpad.net/tjtalk" | 16:14 | |
| *** fsufitch has joined #schooltool | 16:42 | |
| aelkner_ | yvl: ayt? | 17:12 |
| fsufitch | aelkner_: hi | 17:16 |
| fsufitch | mary is here, and she's asking if u remember her | 17:16 |
| aelkner_ | of couse i do | 17:17 |
| aelkner_ | what's she up to? | 17:17 |
| aelkner_ | are you playing bridge or something? | 17:18 |
| fsufitch | no, we're in class ;) | 17:18 |
| aelkner_ | i used to chat during class, but it was always with someone next to me :) | 17:19 |
| fsufitch | well im chatting with her... and you | 17:19 |
| fsufitch | remember drodge? | 17:19 |
| fsufitch | he's in this class too | 17:19 |
| aelkner_ | steve? | 17:19 |
| aelkner_ | now i know you're not paying attention to your class :) | 17:20 |
| fsufitch | we got lab time... | 17:21 |
| fsufitch | nobody's working really | 17:21 |
| fsufitch | no wait, there's 2 people who are working | 17:21 |
| fsufitch | also by using irssi, i *look* like i'm working | 17:21 |
| aelkner_ | i bet you do | 17:22 |
| fsufitch | :) | 17:23 |
| fsufitch | class is almost over thouhg | 17:24 |
| fsufitch | i g2g | 17:24 |
| *** fsufitch has quit IRC | 17:25 | |
| *** replaceafill has joined #schooltool | 17:42 | |
| replaceafill | aelkner_, ping | 17:43 |
| replaceafill | th1a, ping | 17:46 |
| th1a | hi replaceafill. | 17:46 |
| aelkner_ | hey there | 17:46 |
| replaceafill | hi th1a | 17:46 |
| replaceafill | hi aelkner_ | 17:46 |
| replaceafill | just wanted to let you know that the integration works | 17:46 |
| replaceafill | (i think...) | 17:46 |
| replaceafill | jelkner defined yesterday the ui stuff | 17:47 |
| replaceafill | where the buttons go | 17:47 |
| replaceafill | etc | 17:47 |
| replaceafill | so aelkner i'll send you the diff by the weekend | 17:47 |
| replaceafill | for u to check | 17:47 |
| aelkner_ | ok | 17:48 |
| aelkner_ | do you have tests? | 17:48 |
| aelkner_ | or will you, that is | 17:48 |
| replaceafill | yes, the thing is that i've testing the views using browser.open() | 17:49 |
| replaceafill | cause i didnt know where the buttons and options go | 17:49 |
| replaceafill | but know ill change the test to use clicks and stuff | 17:49 |
| th1a | replaceafill: One thing I definitely want to get into the April release is pulling scores into the gradebook from the attendance journal. | 17:50 |
| replaceafill | :O | 17:50 |
| replaceafill | th1a, that sounds interesting | 17:52 |
| th1a | That should be easy to do now, right? | 17:52 |
| replaceafill | well, maybe is the same logic | 17:53 |
| replaceafill | but i dont know :) | 17:53 |
| th1a | Just passing a score. | 17:53 |
| replaceafill | yes | 17:53 |
| th1a | So if everything works correctly, the gradebook side should be ready to go and we just need to add a few calculations to the journal. | 17:54 |
| replaceafill | yes | 17:54 |
| replaceafill | i hope it works correctly :) | 17:54 |
| replaceafill | that's why i was asking jelkner for some testing data | 17:55 |
| replaceafill | because the tests fill some grades and students | 17:55 |
| replaceafill | but i wanted to test it on many of them | 17:56 |
| replaceafill | ignas, ping | 18:08 |
| ignas | replaceafill: pong | 18:10 |
| replaceafill | hi ignas just wanted to ask you about Choice fields | 18:10 |
| ignas | yes | 18:10 |
| replaceafill | if you use the source attribute in a Choice field, you can pass the name of the source, right? | 18:10 |
| replaceafill | or just an ISource instance? | 18:11 |
| ignas | i think the name of the source works too | 18:12 |
| ignas | can't recall where I did it | 18:12 |
| ignas | but there should be an example in schooltool | 18:12 |
| replaceafill | really?!? cool | 18:12 |
| replaceafill | i'm getting a componentlookuperror if i use the name | 18:13 |
| ignas | you can pass a name of a vocabullary like: vocabulary="schooltool.gradebook.categories", | 18:13 |
| ignas | or name of the source source="schooltool.basicperson.grade_class_source", | 18:13 |
| ignas | and register the source like this: | 18:13 |
| ignas | <utility | 18:13 |
| ignas | factory=".vocabularies.gradeClassVocabularyFactory" | 18:13 |
| ignas | provides="zope.schema.interfaces.IVocabularyFactory" | 18:13 |
| ignas | name="schooltool.basicperson.grade_class_source" /> | 18:13 |
| replaceafill | :O!!! | 18:14 |
| replaceafill | the factory must provide ivocabularyfactory! | 18:14 |
| ignas | the factory looks like this | 18:14 |
| replaceafill | that's the error | 18:14 |
| ignas | def gradeClassVocabularyFactory(): | 18:14 |
| ignas | return GradeClassSource | 18:14 |
| ignas | while the source is a source | 18:14 |
| replaceafill | i understand now :) | 18:15 |
| ignas | maybe there is a better way to do it, but this way works and I am too lazy to read the documentation | 18:15 |
| replaceafill | :D | 18:15 |
| replaceafill | thanks ignas | 18:16 |
| ignas | np ;) that's what I am here for | 18:17 |
| th1a | aelkner_: ayt? | 18:45 |
| aelkner_ | th1a: yes | 18:53 |
| th1a | Did you get the email about adding the nurse and special ed person, aelkner_? | 18:56 |
| aelkner_ | i'm looking at it now | 18:57 |
| aelkner_ | i'm thinking of recommending them to add those people to the admin group along with the guidance counselor | 18:58 |
| th1a | no no no | 18:59 |
| th1a | I think you need to manage this just for the intervention system. | 19:00 |
| aelkner_ | the intervention system leverages the groups | 19:00 |
| aelkner_ | but it also uses the logic of knowing who teachers the student | 19:00 |
| th1a | Those people aren't administrators. | 19:01 |
| th1a | We would have to add new roles. | 19:01 |
| th1a | Which I'd rather not do. | 19:01 |
| aelkner_ | yeah, we don't have nurse as a group | 19:01 |
| aelkner_ | so how would i recognize the nurse as a nurse? | 19:02 |
| th1a | Actually, I'm a little unclear on exactly what they want. | 19:02 |
| th1a | How does it work right now? | 19:03 |
| aelkner_ | they want the nurse and the special ed person to appear in the list of people | 19:03 |
| aelkner_ | that one can send a message to | 19:03 |
| th1a | Who is in the list now? | 19:04 |
| aelkner_ | 1) all teachers of the student | 19:04 |
| th1a | These are people you select to get all relevant messages in the thread? | 19:04 |
| aelkner_ | no | 19:04 |
| aelkner_ | when one goes to add a message or a goal | 19:04 |
| aelkner_ | a list of people come up that you can check on | 19:04 |
| aelkner_ | teachers have no prefix | 19:05 |
| th1a | Prefix? | 19:05 |
| aelkner_ | but admin people have ADMIN: (i think) | 19:05 |
| aelkner_ | parents have PARENT: (that one for sure) | 19:05 |
| th1a | OK. | 19:05 |
| aelkner_ | advisors have ADVISOR: | 19:05 |
| aelkner_ | so the want NURSE: and SEL: | 19:05 |
| th1a | All teachers aren't included then. | 19:06 |
| aelkner_ | all teachers of the student | 19:06 |
| aelkner_ | a shorter list | 19:06 |
| th1a | This should be configurable through the web by the site manager. | 19:06 |
| th1a | Add a list of people to show up by default in addition to the above. | 19:07 |
| aelkner_ | hmm | 19:07 |
| aelkner_ | that's an idea | 19:07 |
| aelkner_ | but what abotu schooltool's use of group membership for various things | 19:07 |
| aelkner_ | isn't that the paradigm that we want | 19:08 |
| th1a | Well... it is a whole bees nest. | 19:09 |
| th1a | I don't think at this point we'd get it right for the general case -- a way that would work the way we want across components for the range of support roles like this. | 19:10 |
| aelkner_ | i hate bees... | 19:10 |
| th1a | For example, a lot of this stuff is more relationship based -- a guidance counselor should have access to the students they counsel, but not necessarily all students, etc. | 19:10 |
| th1a | The nurse gets these emails at SLA but generally doesn't get elevated access to student data. | 19:11 |
| aelkner_ | good points | 19:11 |
| ignas | if or rather when i will refactor relationships - we should be able to make queries for "all users that are teachers of any section" | 19:11 |
| ignas | or all "advisors of anyone" | 19:11 |
| ignas | at the moment such queries are prohibitively expensive :/ | 19:11 |
| ignas | thus we can only do them per person - like "is he teaching any section" | 19:12 |
| th1a | That will be helpful. | 19:12 |
| ignas | oh, and - if you really want to you can override "teachers" crowd definition and have it check for a prefix | 19:13 |
| ignas | quite easily | 19:13 |
| ignas | like - 3-4 lines of python and 3-4 lines of zcml in overrides.zcml | 19:13 |
| th1a | aelkner_: You don't have any management pages for interventions at this point, do you? | 19:14 |
| aelkner_ | not yet | 19:15 |
| th1a | Perhaps you should make a management page that lets you add persons to that list. | 19:16 |
| aelkner_ | what list? | 19:16 |
| th1a | of people that show up on the checklist. | 19:17 |
| aelkner_ | for all students? | 19:17 |
| th1a | yes -- isn't that what they want? | 19:17 |
| aelkner_ | they want what they have plus a nurse and a special ed category | 19:18 |
| th1a | Right. | 19:18 |
| aelkner_ | what they have is dynamically created | 19:18 |
| th1a | Yes. | 19:18 |
| aelkner_ | from the teachers that teach the student | 19:18 |
| th1a | I know. | 19:18 |
| th1a | I'm saying, let the administrator create a list that would be appended onto that. | 19:19 |
| aelkner_ | i see | 19:19 |
| aelkner_ | with the label specified for each person | 19:19 |
| aelkner_ | so the admin chooses a person and a label to go with that person | 19:19 |
| aelkner_ | and that info gets stored somewhere | 19:20 |
| th1a | I wouldn't worry that much about the label. | 19:20 |
| aelkner_ | they do | 19:20 |
| aelkner_ | it's essential to them | 19:20 |
| th1a | OK... | 19:20 |
| aelkner_ | they need NURSE: to show up before the nurse's name | 19:20 |
| th1a | Do that then. | 19:21 |
| aelkner_ | ignas: where would you recommend i store this info | 19:22 |
| aelkner_ | as an annotation of the app object? | 19:23 |
| ignas | reading | 19:25 |
| ignas | not sure I understand what the problem is | 19:26 |
| ignas | you want to show roles for persons | 19:26 |
| ignas | when displaying a person? | 19:26 |
| aelkner_ | no, the rols sytem is not useful in this case | 19:26 |
| ignas | so what user visible changes do you want to get | 19:26 |
| aelkner_ | th1a: suggests creating a custom list of people and prefixes | 19:27 |
| aelkner_ | to be displayed in the intervention system | 19:27 |
| aelkner_ | forget the roles that schooltool defines | 19:27 |
| aelkner_ | we have no nurse | 19:27 |
| th1a | We just want to be able to create a list of arbitrary persons who should always show up as options to get emails. | 19:27 |
| ignas | where? | 19:27 |
| ignas | in interventions? | 19:28 |
| th1a | yes. | 19:28 |
| aelkner_ | when adding intervention messages and goals | 19:28 |
| ignas | so - you add a list of persons to the intervention package then | 19:28 |
| ignas | either as a list of persons | 19:28 |
| ignas | or as an object that has relationships with persons | 19:28 |
| aelkner_ | it doesn't need to be complex | 19:28 |
| ignas | it's a global registry, but - it's not a part of application | 19:29 |
| aelkner_ | actually the less complexity the better | 19:29 |
| ignas | it's a part of interventions | 19:29 |
| ignas | well - to you relationships is complex, and user names are easy | 19:29 |
| ignas | to me - it's the other way | 19:29 |
| ignas | because I am keeping users being removed in mind... | 19:29 |
| aelkner_ | ok, fair enough | 19:30 |
| aelkner_ | but how does one say | 19:30 |
| ignas | so app['schooltool.intervention.emailers.list'] | 19:30 |
| aelkner_ | "Jane is a nurse" | 19:30 |
| ignas | well - if it's not a list that you want | 19:30 |
| aelkner_ | keep going | 19:30 |
| ignas | but rather - getting emails and showing up on that list | 19:31 |
| ignas | is a property of a user | 19:31 |
| ignas | then you might think of having a "role" as a demographics field | 19:31 |
| ignas | and filtering through all the users to find the ones you want to show there... | 19:31 |
| th1a | Hm... | 19:31 |
| ignas | the next option is | 19:32 |
| ignas | add a Nurses group | 19:32 |
| ignas | or add an Intervention dudes group | 19:32 |
| ignas | to schooltool groups container | 19:32 |
| ignas | hardcode that group | 19:32 |
| ignas | put people into that group | 19:32 |
| ignas | and show all the members of that group | 19:32 |
| ignas | in the list of email getting persons | 19:32 |
| aelkner_ | that's what i wanted from the start | 19:32 |
| th1a | I think it is more of a "gets intervention emails" property on the person. | 19:32 |
| aelkner_ | prefix? | 19:33 |
| ignas | th1a: well - if we had SQL queries then we could do it, but as we want it efficient with an object database, we might as well start from the "index of all the people who are getting emails" | 19:33 |
| th1a | The interventions package could create an intervention dudes group. | 19:33 |
| th1a | That would work. | 19:33 |
| ignas | aelkner_: if you are using an up to date schooltool, you can create the group on app startup even | 19:34 |
| aelkner_ | first, i don't have an up to date school | 19:34 |
| aelkner_ | but i can always patch their data | 19:34 |
| th1a | Yes. | 19:34 |
| aelkner_ | so that's not the issue | 19:34 |
| ignas | yeah, you can create the group manually | 19:34 |
| aelkner_ | second | 19:34 |
| aelkner_ | one group for intervention dudes would not be enough | 19:35 |
| aelkner_ | we need the dud to have a prefix | 19:35 |
| aelkner_ | or dudette | 19:35 |
| th1a | Well, that's a separate problem. | 19:35 |
| th1a | That's just something that needs to be added to the demographic schema. | 19:35 |
| aelkner_ | look | 19:35 |
| aelkner_ | think of it simply | 19:35 |
| aelkner_ | we need a list | 19:35 |
| aelkner_ | ex/ | 19:35 |
| aelkner_ | 1) NURSE: Jane | 19:35 |
| th1a | I'm not looking at it complexly. | 19:36 |
| aelkner_ | 2) SEL: Bob | 19:36 |
| aelkner_ | 3) COUNSELOR: Karina | 19:36 |
| aelkner_ | etc. | 19:36 |
| aelkner_ | so a list of tuples | 19:36 |
| aelkner_ | role (prefix), userid | 19:36 |
| aelkner_ | it's that simple | 19:36 |
| th1a | Or just add "title" to the schema. | 19:36 |
| aelkner_ | what schema? | 19:37 |
| th1a | The demographic schema. | 19:37 |
| aelkner_ | ah ha | 19:37 |
| aelkner_ | intervention title | 19:37 |
| th1a | More like job title. | 19:38 |
| th1a | It is generally relevant. | 19:38 |
| aelkner_ | but remeber | 19:38 |
| aelkner_ | the reason Bill shows up as ADVISOR: Bill | 19:38 |
| aelkner_ | in the list for adding a message for student Bob | 19:39 |
| aelkner_ | is the Bill is one of Bob's advosors | 19:39 |
| th1a | Right, but if you're adding him to the list because he is an advisor you don't have to use his title. | 19:39 |
| aelkner_ | right | 19:39 |
| th1a | If you're adding him as a member of the dudes, then you use his title. | 19:39 |
| aelkner_ | but if we have this new title field | 19:39 |
| aelkner_ | and we put NURSE there | 19:39 |
| aelkner_ | we could have that automatically add that person to the lsit | 19:40 |
| aelkner_ | so no, title, no appearance on any lists | 19:40 |
| th1a | Hm? | 19:40 |
| aelkner_ | unless for other reason, i.e., the person is the student's advisor or teacher | 19:40 |
| th1a | We just need a title field anyhow. | 19:41 |
| th1a | It is relevant beyond interventions. | 19:41 |
| aelkner_ | i could see that | 19:42 |
| aelkner_ | i would need logic for applying the title field | 19:42 |
| aelkner_ | when do i interpret the presense of a title | 19:42 |
| aelkner_ | to mean add them to the list | 19:42 |
| th1a | The title doesn't determine who is on the list. The group membership does. | 19:43 |
| th1a | If you are a dude. | 19:43 |
| aelkner_ | walk me though how Jane the nrese gets into the list | 19:43 |
| aelkner_ | nurse | 19:43 |
| th1a | Add Jane to the Intervention Dudes group. | 19:43 |
| ignas | i'd still add 3 groups | 19:43 |
| th1a | Which? | 19:43 |
| ignas | Nurses, Advisors, Counselors | 19:43 |
| ignas | and add people to these groups | 19:44 |
| ignas | or do Advisors and Counselors depend on the student | 19:44 |
| th1a | I don't want to get into that. | 19:44 |
| ignas | th1a: why? | 19:44 |
| th1a | I don't think it is necessary. | 19:44 |
| ignas | emm, it's simpler, not necessary | 19:44 |
| th1a | Because it is complicated. | 19:44 |
| ignas | other options are more complicated from the code side | 19:44 |
| ignas | if you have tuples | 19:45 |
| ignas | you must store them somewhere | 19:45 |
| ignas | you must manage them somehow which you need UI for | 19:45 |
| ignas | you must update them if people get removed | 19:45 |
| th1a | Advisors and counselors depend on the student. | 19:45 |
| th1a | Also, I don't have the slightest idea of how these things are handled in different countries. | 19:45 |
| ignas | th1a: i see | 19:45 |
| th1a | In the US, you often have a counsellor assigned to each grade. | 19:46 |
| th1a | For example, so that's something that has to be managed. | 19:46 |
| th1a | It is not something to open up now. | 19:46 |
| ignas | well - when we will have grades we will have counselors for grades instead of students | 19:46 |
| ignas | my point is - adding groups is an isolated solution | 19:47 |
| ignas | it will not affect persons | 19:47 |
| ignas | it will not affect schooltool_2008.10 | 19:47 |
| ignas | it will not affect anything except intervention package | 19:47 |
| ignas | i can't understand how it makes it more complicated | 19:48 |
| th1a | I'm thinking about what will be most generally useful for different schools using the intervention system. | 19:48 |
| aelkner_ | i always like using the groups | 19:48 |
| th1a | They may want entirely separate kinds of people to get these emails, so hard coding "nurses" for example doesn't help. | 19:49 |
| ignas | th1a: we will change it when we will see the problem | 19:49 |
| ignas | th1a: we have SLA for that reason, so they could tell us what is that is useful to them, and we would not drift into "general" solutions | 19:49 |
| ignas | and then we generalize the solutions | 19:50 |
| ignas | when we expand the horizons | 19:50 |
| th1a | I'm not sure what we're arguing about. | 19:51 |
| th1a | Do you want to use the group titles to generate the prefixes? | 19:51 |
| ignas | about the implementation of the list of people who get emails | 19:51 |
| th1a | Yes, but I don't know why you want three groups instead of one. | 19:51 |
| th1a | What's the advantage? | 19:52 |
| ignas | we have 1 prefix from group title - Nurses, other prefixes are generated by role, or at least that's what I understand | 19:52 |
| ignas | th1a: i did not know that advisors and counselors are relationship with student based, not global group based | 19:52 |
| th1a | At SLA, this is global. | 19:52 |
| aelkner_ | wiat | 19:53 |
| aelkner_ | adisors are neither | 19:53 |
| aelkner_ | part od the demos for a student | 19:53 |
| th1a | Counselors are global. | 19:53 |
| aelkner_ | is advisor1 and advisor2 | 19:53 |
| aelkner_ | that's it | 19:53 |
| th1a | The change in question concerns two global people. | 19:53 |
| ignas | aelkner_: yeah, it's relations based, the relationship is described as a demo field | 19:53 |
| aelkner_ | so you mean relationship in the abstract | 19:54 |
| ignas | aelkner_: yes | 19:54 |
| aelkner_ | not the schooltool.relationship sense | 19:54 |
| th1a | The feature request is "we need the nurse and the counselor to show up on this dynamically generated list every time" | 19:54 |
| aelkner_ | right, with NURSE: and SEL: as prefixes | 19:55 |
| aelkner_ | so, if we add the two groups | 19:55 |
| ignas | th1a: yep, and i find it easier to add code, than to change and add new data structures | 19:55 |
| ignas | because we can change the code any time we want, and data structure modifications require evolution | 19:56 |
| aelkner_ | yes, i would wnat to use the existing data structure | 19:56 |
| aelkner_ | and just add the two groups | 19:56 |
| aelkner_ | and use them them in the code | 19:56 |
| ignas | so if we will decide we don't want groups or want more groups - we just stop using it, and tada it's as it was before | 19:56 |
| ignas | and if we want to have groups instead of a simple list - we must remove the list and move it's members to groups | 19:57 |
| ignas | which is not about just changing code | 19:57 |
| th1a | Here is what I'm proposing: | 19:57 |
| th1a | 1) make an intervention dudes group which is created when you initialize the interventions package; | 19:57 |
| th1a | 2) add job title to demographics, which we need anyhow. | 19:58 |
| th1a | 3) interventions form appends the members of dudes with their job titles to the list of possible email recipients. | 19:58 |
| ignas | here is the problem - intervention then works only with persons who have job titles (a.k.a. either I add it to basic person and to simple person, or intervention does not work) | 19:59 |
| ignas | so it depends on the implementation of the person object | 19:59 |
| th1a | If there is no title then it just doesn't use a title. | 19:59 |
| th1a | So you are saying just make two groups and use the title of the group? | 20:00 |
| ignas | doable I guess | 20:00 |
| ignas | group titles are simpler | 20:00 |
| ignas | now i am thinking whether job title is better | 20:00 |
| ignas | and how to do the "no title - show no title" properly | 20:01 |
| th1a | It is kind of absurd to not have job title somewhere. We'll need it. | 20:01 |
| ignas | th1a: any change that requires everyone to change their code is complicated | 20:01 |
| ignas | aelkner_: can you pull off a view lookup for job title in your code? | 20:02 |
| ignas | aelkner_: i mean - i'd make job title a view, that would show an empty string for IPerson | 20:03 |
| ignas | and a proper job title for SLA Person | 20:03 |
| ignas | so everything will work without SLA person and I could update basic person to have a job title | 20:03 |
| ignas | later whenever I want without making people not use intervention while I am doing it | 20:03 |
| ignas | and no - if ISLAPerson.providedBy(person): return person.job_title is not a good solution | 20:04 |
| aelkner_ | why can't leverage what we got as much as possible? | 20:05 |
| ignas | aelkner_: because the solution that tom wants does not add much code | 20:05 |
| ignas | aelkner_: and is a bit better than the group one | 20:06 |
| ignas | so you still add a group | 20:06 |
| ignas | but only 1 group | 20:06 |
| ignas | that anyone can be in, without restricting people to some specific roles | 20:06 |
| ignas | it will be a "function" based group | 20:06 |
| ignas | instead of "role" based group | 20:06 |
| ignas | which is a good thing in this case | 20:07 |
| aelkner_ | so are we agreeing to th1a's plan: | 20:08 |
| aelkner_ | 1) have an interventions group | 20:08 |
| aelkner_ | 2) membership causes the peson to appear in the email list | 20:08 |
| aelkner_ | 3) add a job title to intervention.demos | 20:08 |
| aelkner_ | 4) if present, use it as prefix | 20:09 |
| aelkner_ | ? | 20:09 |
| ignas | yes | 20:09 |
| th1a | Yes. | 20:09 |
| aelkner_ | ok, it's a plan | 20:09 |
| ignas | but instead of having the if check - you have a job title view in the right layer, or for the right person class | 20:09 |
| aelkner_ | can i change the subject? | 20:09 |
| aelkner_ | oops | 20:09 |
| th1a | I think if we have a sprint early next year it is going to have to be about the final rationalization of persons. | 20:10 |
| aelkner_ | yeah to that | 20:10 |
| aelkner_ | but for now, i'm just going to add job title to intervention deoms | 20:10 |
| *** ignas has quit IRC | 21:12 | |
| *** replaceafill has quit IRC | 21:15 | |
| *** mgedmin has quit IRC | 21:20 | |
| *** mgedmin has joined #schooltool | 22:54 | |
| *** mgedmin has quit IRC | 23:42 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!