Hi
I have 80 teachers in school, in an academic year if one teacher leaves the school the work load of the teacher is shared with 5 teachers and say about 15 teacher in overall is effected. but remaining 65 teachers time table is still the same. If i re generate the time table all 80 teachers time table will be effected, i want to retain the time table same for 65 teachers and only change for 15 how can i achieve this?
Thanks
go to the fet-result folder.
open the saved data+timetimetable file.
fet -> constraints -> all time constraints -> filter -> search teacher name -> delete the fixed time constraints.
you maybe also need to remove fixed room constraints.
Liviu: this is not a good workaround, because rooms might be a problem.
we should add into TODO:
fet -> timetable -> advanced lock/unlock -> lock/unlock all activities of a specific teacher is needed.
Thanks.
When is lock the time table of the teachers and re generate the time table will the locked teachers time table not be effected?
Quote from: Volker Dirr on May 29, 2015, 11:33:24 PM
Liviu: this is not a good workaround, because rooms might be a problem.
we should add into TODO:
fet -> timetable -> advanced lock/unlock -> lock/unlock all activities of a specific teacher is needed.
Generate a locked timetable, then View teachers timetable, select all activities in the view, Lock/Unlock both time and space.
Hallo chintu.
You are using FET 5.21.2. We already fixed that problem in newer versions. So you won't need to do Livius workaround. Please use a newer FET version.
Quote from: Volker Dirr on May 30, 2015, 11:55:25 AM
Hallo chintu.
You are using FET 5.21.2. We already fixed that problem in newer versions. So you won't need to do Livius workaround. Please use a newer FET version.
Volker, I don't understand. In FET-5.27.2 he needs to generate, then open view teachers timetable, then for a teacher select all activities and click toggle lock/unlock. He needs to generate the timetable.
ah.. sorry. I didn't read carefully and though you was talking about fet -> timetable -> lock/unlock all
So my workaround is bad.
Livius way is fine.
But not perfect. I still think we should add that TODO:
Reason: similar to the reason why we fixed/added that feature in 5.22.0.
Guys might modify the data a bit before regenerating. Generating will fail then of course, so they can't unlock specific teachers after modifications (without regenerating).
EDIT: hmm... maybe it is unneeded. i am not sure at the moment.
and maybe a second TODO:
in the view forms:
if no activity is selected, it should automatily select all activities of that teacher.
so it shouldn't say "no activities locked", because the user maybe don't know why no activity is locked/unlocked. (So maybe you can say "no activities locked, because no one is selected", but that is a bit stupid in my opinion, because it has no effect.
I suggest it should say (and of course do) "All x activities of that teacher/students/room are locked/unlocked, because you didn't select specific ones."
Quote from: Volker Dirr on May 30, 2015, 01:48:43 PM
But not perfect. I still think we should add that TODO:
Reason: similar to the reason why we fixed/added that feature in 5.22.0.
Guys might modify the data a bit before regenerating. Generating will fail then of course, so they can't unlock specific teachers after modifications (without regenerating).
OK, I'll add this in the TODO. If chintu really needs it, we'll implement it (if he needs to unlock without generating). But we need to do this also for students?
Quote from: Volker Dirr on May 30, 2015, 02:20:27 PM
and maybe a second TODO:
in the view forms:
if no activity is selected, it should automatily select all activities of that teacher.
so it shouldn't say "no activities locked", because the user maybe don't know why no activity is locked/unlocked. (So maybe you can say "no activities locked, because no one is selected", but that is a bit stupid in my opinion, because it has no effect.
I suggest it should say (and of course do) "All x activities of that teacher/students/room are locked/unlocked, because you didn't select specific ones."
I don't agree with this. It is easy for the user to realize the behaviour.
Quote from: Liviu Lalescu on May 30, 2015, 02:26:46 PMOK, I'll add this in the TODO. If chintu really needs it, we'll implement it (if he needs to unlock without generating). But we need to do this also for students?
I am not sure if that will be needed many times (i talk about students and rooms). Also Students will be more difficult to code.
Quote from: Liviu Lalescu on May 30, 2015, 02:26:46 PMI don't agree with this. It is easy for the user to realize the behaviour.
Without phrase "because not selected". I am not sure, i bet not everyone will understand.
But i don't think that phrase is usefull, because
a) ... it has no effect to the activities.
b) ... in normal case you will unlock only a (few) single one or all activities. But never no activity. So it will save a lot mouse movements/clicks if all activities are selected if no activity is selected.
(i don't talk about selecting them by default. So all are "blue" that look stupid. I only talk about FET should select them automaticly if no one is selected an a user press lock/unlock.)
On the other side it doesn't save "so" much, because FET already remember all marked slots if you change the teacher.
Quote from: Volker Dirr on May 30, 2015, 02:36:10 PM
b) ... in normal case you will unlock only a (few) single one or all activities. But never no activity. So it will save a lot mouse movements/clicks if all activities are selected if no activity is selected.
Just click on the upper-left corner.
ok, it save only movement to corner and a click. But i think "improving" the phrase won't hurt (because no new code), but might help some users.