> These all look good to me, a small query/something to think about. > > Can siblings be linked ? So that duplicate contacts are not required. > > So a student can have multiple contacts and a contact can have multiple > students. > > Also it might be usefull to think about addresses, an example use case > would be if a student move address, then it is very likely that the > parental contact(s) will move address as well. > > So maybe the contact could optionally inherit some properties from the > student.
But won't that complicate the UI for the rest of students for quite marginal benefits, and suddenly instead of "remove/archive" a student you will have a problem with old parent/guardian data archival/management, and users will have to understand that somehow these things are separate issues, will have to know the rules like "if you archive all the students related with this parent, the parent will be archived automatically" or "if you change address of this student (which he does not have at the moment, as address is only stored for contact persons), you will change all the related addresses". My biggest concern is having another class of objects that have different and not well defined management semantics, like - when and how do you archive/delete contact information for parents? Do you remove any contact information that is not linked to any student? What about undoing such an operation? What about "remove student A" "add student B", do we want to explain everyone that they should never try doing that, or do we want to have a separate UI just for student contact management, effectivelly adding a separate person class just for parents? Ignas _______________________________________________ Schooltool mailing list [email protected] http://lists.schooltool.org/mailman/listinfo/schooltool
