dhis2-devs team mailing list archive

[Abyot Gizaw <abyota@xxxxxxxxx>]

We are aware of the security issue. Our plan is to control that with user
role.

-----
Thank you,
Abyot.

(sent from mobile)
On Mar 5, 2015 8:14 AM, "Harsh Atal" <harsh.atal@xxxxxxxxx> wrote:

>
> One issue that is there with making the user able to see the TEI data at
> any orgunit is of confidentiality. Because with this approach the user at
> district1 (which let's say handles TB programs) can see the TEIs at
> district2(which handles HIV data).This can be a big issue with private data
> like that of HIV or name based data in general. Even when facilities are
> not categorized based on the programs they offer , still , giving the user
> the power to see any TEI data at any org unit is a bit risky.
>
> We are facing a similar requirement as above, that is why we wanted to
> change location of the TEI.I understand that doing that will result in loss
> of data. But I am not sure how else to fulfill this requirement(perhaps we
> have to maintain location history as well)Do you have any idea on how we
> can we tackle this issue?
>
> Thank You
>
> On 4 March 2015 at 16:46, Abyot Gizaw <abyota@xxxxxxxxx> wrote:
>
>> I see your point.
>>
>> But, the situation that you have referred a patient from orgunit A to
>> orgunit B does not change the fact that the patient was registered/enrolled
>> at orgunit A. By doing migration, we are destroying this information which
>> for me is wrong.
>>
>> What we need to probably do is provide a feature for users to decide how
>> to see a list of patients. Currently, by default, you see those patients
>> registered under your orgunit - but of course you can go to advanced search
>> and see those patients from another orgunit.  It would be nice if users can
>> for example say
>> - show patients who are enrolled in my orgunit,
>> - show me patients who are diagnosed (have data recorded) in my orgunit
>> - ...
>>
>> ---
>> Thank you,
>> Abyot.
>>
>> On Wed, Mar 4, 2015 at 11:51 AM, Harsh Atal <harsh.atal@xxxxxxxxx> wrote:
>>
>>> 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
>>>>>
>>>>>
>>>>
>>>
>>
>