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.a...@gmail.com wrote:
One issue that is there with making the user able to see the TEI data at
any orgunit is of
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
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 morte...@gmail.com wrote:
Hi Harsh
You are not allowed to update the orgUnit pointer, this was supposed to be
the
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.
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
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
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
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
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
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
10 matches
Mail list logo
