Hi Olav, yes that is the way it is supposed to work at the moment. There are of course arguments on both sides here, but I think its the better solution. If you lock a data set, then you expect that the data will not change, and you could event release reports based on that. If your data changes because someone else has made a data set with the same data elements then it is bad - I think it is better to be on the conservative side here.
Lars On Mon, Jan 20, 2014 at 9:00 PM, Olav Poppe <olav.po...@me.com> wrote: > Hi, > just an observation/comment with regard to how locking of datasets seems > to be handled. > > I saw a case today where some of the same data elements were used in two > different, but related datasets. One of these had locking («Expiry days») > enabled, the other did not. For those data elements that were part of both > data sets, data entry was locked even when entering data for the dataset > that was *not* locked. It took some time (and a suggestion from Ola) > before we figured out what was going on. > > I’m not sure if this behaviour is by design or not, and I can see both > pros and cons of doing it this way. Nonetheless, I found it quite > confusing, so I though I’d share it on the list just as a heads up for > others. > > Olav > > _______________________________________________ > Mailing list: https://launchpad.net/~dhis2-users > Post to : dhis2-us...@lists.launchpad.net > Unsubscribe : https://launchpad.net/~dhis2-users > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : dhis2-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
