dhis2-devs team mailing list archive

[Kim-Anh Vo <catakim@xxxxxxxxx>]

Thanks to all... I see the points!

On Tue, May 11, 2010 at 11:10 PM, Bob Jolliffe <bobjolliffe@xxxxxxxxx>wrote:

> Hi Ola
>
> On 11 May 2010 15:41, Ola Hodne Titlestad <olatitle@xxxxxxxxx> wrote:
> > Hi,
> >
> > Have a look at the maintenance manual I distributed yesterday, it
> describes
> > how to deal with metatdata conflicts in data import; the meaning of New
> and
> > Updates and the use of compare to existing, and match new to existing.
>
> I've had a quick look yesterday but need to study more carefully.  I
> think we need to tighten up a bit on the notion of metadata
> governance.  Establishing the human practices is of course the first
> step.  Having the system support those practices is next ..
>
> >
> > This way of dealing with metadata synchronisation and conflicts is well
> > established in DHIS since the early versions of DHIS 1.
> >
> > I had some discussions with Lars last week as to how we can make the data
> > import process more robust and safer, and the option to force more strict
> > metadata update procedures during data import is one approach, as in not
> > allowing any new or updates to metadata by default (which is useful in
> > situations where you know that there should be no changes taking place at
> > the lower levels). This can e.g. be triggered by import settings.
>
> agreed
>
> >
> > The default data import now automatically adds all New meta data items,
> > which is not always a good idea when there are sloppy implementers not
> > paying attention to the New and Updates statistics in the import Preview
> > section.
>
> Its maybe not fair to blame the implementors entirely.  If we know
> what is good practice the system should support the implementors in
> practicing it :-)  I suspect the best setting would be for a data
> import NEVER to trigger a metadata update ie. the metadata import part
> of the transaction should always be in a preview/analysis mode.  The
> metadata import should be a separate "button" with a different
> authority required in order to click it.  Admittedly with everyone
> logged in as admin this might have limited effect but at least we
> ensure that the import of metadata is a deliberate rather than
> accidental process.
>
> Regards
> Bob
>
> >
> > Ola
> > ----------------
> >
> > On 11 May 2010 05:30, Kim Anh Vo <catakim@xxxxxxxxx> wrote:
> >
> >> Public bug reported:
> >>
> >> Currently with DHIS2.0.4, when running import/export function for DHIS2
> db,
> >> and through import-analysis show that identifier for daels, dataset,
> >> categoryoptions, indicator, etc. is the NAME, not ID.
> >> It seems messy, for example: a dataset/dael (which already exists in the
> >> center db) is renamed in the local db when exported/imported into the
> center
> >> (or upper levels db) it's recognized as a new one for importing.
> >> So, if lacking user's notice/awareness, this "new" element would be
> added
> >> into the destination db but later on when opening the equivalent session
> of
> >> that element type (dael, sataset, ect.) conflicts occur.
> >>
> >> Suggestion: unify the management/strategy for import/export identifier,
> >> what's it called "updates", "new"?
> >>
> >> ** Affects: dhis2
> >>     Importance: Undecided
> >>         Status: New
> >>
> >> --
> >> import/export based on name not ID
> >> https://bugs.launchpad.net/bugs/578621
> >> You received this bug notification because you are a member of DHIS 2
> >> coordinators, which is the registrant for DHIS.
> >>
> >> Status in DHIS 2 - District Health Information Software: New
> >>
> >> Bug description:
> >> Currently with DHIS2.0.4, when running import/export function for DHIS2
> db,
> >> and through import-analysis show that identifier for daels, dataset,
> >> categoryoptions, indicator, etc. is the NAME, not ID.
> >> It seems messy, for example: a dataset/dael (which already exists in the
> >> center db) is renamed in the local db when exported/imported into the
> center
> >> (or upper levels db) it's recognized as a new one for importing.
> >> So, if lacking user's notice/awareness, this "new" element would be
> added
> >> into the destination db but later on when opening the equivalent session
> of
> >> that element type (dael, sataset, ect.) conflicts occur.
> >>
> >> Suggestion: unify the management/strategy for import/export identifier,
> >> what's it called "updates", "new"?
> >>
> >>
> >>
> >
> > --
> > import/export based on name not ID
> > https://bugs.launchpad.net/bugs/578621
> > You received this bug notification because you are a member of DHIS 2
> > coordinators, which is the registrant for DHIS.
> >
> > Status in DHIS 2 - District Health Information Software: New
> >
> > Bug description:
> > Currently with DHIS2.0.4, when running import/export function for DHIS2
> db, and through import-analysis show that identifier for daels, dataset,
> categoryoptions, indicator, etc. is the NAME, not ID.
> > It seems messy, for example: a dataset/dael (which already exists in the
> center db) is renamed in the local db when exported/imported into the center
> (or upper levels db) it's recognized as a new one for importing.
> > So, if lacking user's notice/awareness, this "new" element would be added
> into the destination db but later on when opening the equivalent session of
> that element type (dael, sataset, ect.) conflicts occur.
> >
> > Suggestion: unify the management/strategy for import/export identifier,
> what's it called "updates", "new"?
> >
> >
> >
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
> More help   : https://help.launchpad.net/ListHelp
>



-- 
-- 
Best regards,
Kim-Anh Vo

+84.906612246
kavo@xxxxxxxxxx
Coordinator of HISP(hisp.info) in Vietnam
Master of Information Systems
at the University of Oslo
------------------------------------
join facebook at www.facebook.com join LinkedIn at www.linkedin.com