dhis2-devs team mailing list archive

[Harsh Atal <harsh.atal@xxxxxxxxx>]

By migration I meant the same feature as 'change location' in individual
records. Now, as abyot said if it is possible to access a TEI at any org
unit and enter data for any org unit then that is one way to do it but its
not the same as 'change location' in individual records.
The need for 'migration' came in case a TEI was referred to another
orgunit. For eg: a patient diagnosed with HIV is referred to a OU  which
handles the program for HIV, and now all the enrollment and data entry have
to be done in that OU i.e. now the patient is in the jurisdiction of the
user who handles the  OU for HIV based programs, in this case shouldn't
that patient come under the TEI list of that org unit(in the home page).
Even when we consider the possibility of having data entered for a TEI at
any OU, still i feel that the 'change location' feature seems relevant.


Thank You
harsh





On 4 March 2015 at 14:24, Pierre Dane <pierre@xxxxxxxxx> wrote:

> I agree.
> What we are doing is having a placeholder org unit for the TEI, and then
> registering the events against the actual org unit. Then the event reports
> and aggregations work against the event org unit .
>
> This makes it easy (possible!)  to look the TEI up as you will always know
> the org unit (api TEI lookup requires know orgunit)
>
>
> On Wed, Mar 4, 2015 at 10:45 AM, Abyot Gizaw <abyota@xxxxxxxxx> wrote:
>
>> Ok, you know what your needs are.
>>
>> Are you also going to migrate events? What will happen to already
>> submitted/acted report? You need to carefully look into the migration
>> requirement. I am strongly against the idea of migration. With migration,
>> you will lose information. If it is possible to access a TEI and do data
>> entry at orgunit which is not necessarily the same as the
>> registration/enrollment orgunit, then I don't think we need migration.
>>
>> ---
>> Thank you,
>> Abyot.
>>
>> On Wed, Mar 4, 2015 at 9:20 AM, Harsh Atal <harsh.atal@xxxxxxxxx> wrote:
>>
>>> thanks morten  ,I thought it was a bug........
>>>
>>>
>>> @abyot
>>> I want to migrate the tracked entity instance into another organisation
>>> unit. So when the next time i select the orgunit from which i migrated i
>>> dont want to see the tracked instance there but instead it has to come up
>>> in the new org unit. This is a functionality that we require for a project.
>>>
>>> On 4 March 2015 at 13:39, Abyot Gizaw <abyota@xxxxxxxxx> wrote:
>>>
>>>> Hi Harsh,
>>>>
>>>> Do you really want to migrate? Or you want to register data in another
>>>> org unit?
>>>>
>>>> -----
>>>> Thank you,
>>>> Abyot.
>>>>
>>>> (sent from mobile)
>>>> On Mar 4, 2015 9:07 AM, "Morten Olav Hansen" <mortenoh@xxxxxxxxx>
>>>> wrote:
>>>>
>>>>> Hi Harsh
>>>>>
>>>>> You are not allowed to update the orgUnit pointer, this was supposed
>>>>> to be the point of registration.. and was thought of as being read-only
>>>>> after initial registration.
>>>>>
>>>>> That said, I'm 90% sure we are changing this for 2.19, we are having
>>>>> discussion about that now (we would rather have the orgUnit pointer on the
>>>>> enrollment)
>>>>>
>>>>> --
>>>>> Morten
>>>>>
>>>>> On Wed, Mar 4, 2015 at 3:04 PM, Harsh Atal <harsh.atal@xxxxxxxxx>
>>>>> wrote:
>>>>>
>>>>>> Dear All
>>>>>>
>>>>>> I am trying to shift a trackedentityinstance from one
>>>>>> organisationunit to another. For this i tried to use the web API resource
>>>>>> for the updation of trackedEntityInstance.
>>>>>> This ,i have found, is not working for the organisationunit as it is
>>>>>> not changed while the changes in other information like attributes etc are
>>>>>> reflected.
>>>>>>
>>>>>> I am not getting any error and the web api response status is SUCCESS
>>>>>> but the organisationunitid doesn't change in the trackedEntityInstance
>>>>>> table in the db.
>>>>>>
>>>>>> Have you encountered such a problem?
>>>>>>
>>>>>> Thank You
>>>>>> Harsh
>>>>>>
>>>>>> _______________________________________________
>>>>>> Mailing list: https://launchpad.net/~dhis2-devs
>>>>>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>>>>>> Unsubscribe : https://launchpad.net/~dhis2-devs
>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~dhis2-devs
>>>>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>>>>> Unsubscribe : https://launchpad.net/~dhis2-devs
>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>
>>>>>
>>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~dhis2-devs
>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~dhis2-devs
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>