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" <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>>>> 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 <[email protected]> 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" <[email protected]> >>>>>>> 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 <[email protected]> >>>>>>>> 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 : [email protected] >>>>>>>>> Unsubscribe : https://launchpad.net/~dhis2-devs >>>>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Mailing list: https://launchpad.net/~dhis2-devs >>>>>>>> Post to : [email protected] >>>>>>>> Unsubscribe : https://launchpad.net/~dhis2-devs >>>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>>> >>>>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Mailing list: https://launchpad.net/~dhis2-devs >>>>> Post to : [email protected] >>>>> Unsubscribe : https://launchpad.net/~dhis2-devs >>>>> More help : https://help.launchpad.net/ListHelp >>>>> >>>>> >>>> >>> >> >
_______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : [email protected] Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
