It’s an interesting use case, because it breaks with the scenario assumed with current tracker design.
Firstly, note that you CAN move/transfer TEIs temporarily or permanently to another orgunit - you do this by clicking the curved arrow icon on the Tracker Dashboard. Doing so will also “force” you to open another event (which you subsequently can delete without capturing any data).
Secondly, NOTE that a permanent transfer - which I presume is what you are mostly interested in - will move the Teacher to another school BUT all existing events will remain linked to the previous school. Only new events generated after the permanent transfer will be linked to the new school.
Thirdly, it is important to understand that the transfer functionality is predicated on a rather narrow use case scenario: that of the TEI being a patient that temporarily or permanently is referred to, or prefers to shift too, another health facility. With that relatively narrow (but in health terms common) scenario, any previous events will normally be a health service provided and it thus “naturally” belong with the health facility providing it and not with the patient’s “new” facility. Or to say it differently: The current Tracker Design is 80-90% determined by the perspectives and “systems view” emanating from the Palestinian Mother & Child instance, which has been driving a lot of development (the Tracker team leader and Deputy Team leader have both been heavily involved in that project).
Fourthly, in your use case - and other similar use cases - the events are only indirectly linked to the orgunit in the sense that a school can benefit from a teacher’s training and skills, but obtaining said training and skills will typically be independent of any specific school. Or in other words, the data in those events are in reality a form of “extended” Tracked Entity Attributes and primarily linked to the teacher and not the school. So ideally you want to move the teacher AND all her/his training etc to the new school.
This is very similar to use cases where the TEI is a health worker - most skills, training, etc are then also not on-the-job but a result of continuous education, courses, and the like. There MIGHT be countries where courses and distance education etc are paid for by the health facility - and thus you want such events to remain with that facility so that they can report on them and link those events to their expenditure - but I think those are exceptions: in most cases health workers will be funding courses and education etc from other sources. Which means they are in the same position as teachers - all the events “belong” with the worker and not the workplace.
Fifthly, I recognised the limitations of the current transfer approach some time back also in relation to cases where e.g. data capturers by mistake capture cases under the wrong orgunit (happens regularly), or capture events under the wrong orgunit (VERY easy to do because of the way the search function has been designed, it will open any case found even if the currently “active” orgunit is another orgunit, and then enable the user to capture new events under that other orgunit) - and wrote two JIRA issues for it:
DHIS2-5951 (permanent transfer of TEI with all enrollments/events)
DHIS2-5952 (opening cases from search causes incorrect event capturing).
Nothing has happened with these two issues (but I discussed it with Markus and he agrees in principle). So please add your use case to the above and vote for it etc.
In the meantime, you CAN use the permanent transfer functionality - cumbersome as it is - to move teachers from school A to School B, which in reality means that the “organisationunit” field in the table “programinstance” will be updated. There must be some “available” stage for you to add, but you can immediately delete that again after the transfer.
In order to ensure that all existing events belonging to that teacher is also moved, you can set up the following script as a daily script:
Daily Script: Fixing TEIs with differing event orgunits:
UPDATE programstageinstance psi
SET organisationunitid = pi.organisationunitid
FROM programinstance pi
WHERE pi.programinstanceid=psi.programinstanceid AND psi.organisationunitid <> pi.organisationunitid;
The script will ensure that all events are linked to the same orgunit as the main enrollment (= TEI in your case).