dhis2-devs team mailing list archive

[Lorill Crees <lcrees@xxxxxxxxxx>]

Hi Lars,

Just following up on this. What would the timeline look like for the
implementation of POST support for resources in api/documents?

Thanks,

Lorill

On Thu, May 12, 2016 at 3:26 PM, Lorill Crees <lcrees@xxxxxxxxxx> wrote:

> Thanks Lars, that is helpful.
>
> We have a couple of use cases for this functionality:
>
>    1. There is a desire to upload supporting documents around particular
>    surveys in DHIS 2. For example, there may be a Word doc with the background
>    information around what a particular survey is about and how it was
>    conducted, and users want that linked to the particular survey (Program).
>    2. We had been investigating different options for integrating R with
>    DHIS 2, and were looking for a way to store binary file outputs from R such
>    as pngs etc. These would be related to a Program in general, and we would
>    not want to store those on a data value basis.
>
> Users would also want the above documents to be available on Dashboards.
>
> In regards to the short-term workaround you suggested, what would the
> timeline for that look like?
>
> Thanks again,
>
> Lorill
>
> On Thu, May 12, 2016 at 3:02 PM, Lars Helge Øverland <lars@xxxxxxxxx>
> wrote:
>
>> Hi Lorill,
>>
>> we are not going to deprecate/remove api/documents so it is safe to use
>> it, however like you say we do not have POST support in the API so it is a
>> bit useless at the moment. A short-term workaround would be to simply
>>
>> - implement POST support for files in DocumentController - patch? ;)
>> - use some sort of soft reference like prefixing the document name with
>> the program or data set UID.
>> - documents support the sharing paradigm so you could use that for access
>> control
>>
>> Longer term (around 2.25) we are planning to generalize the file resource
>> concept we did for 2.20 into more of a general purpose file store. As you
>> know this has cloud backend support and is a more scalable solution.
>> However this design of this is still on the drawing board - we will keep
>> you posted!
>>
>> If you could provide a bit more detail about your requirement that would
>> also be helpful to guide us.
>>
>> best regards,
>>
>> Lars
>>
>>
>>
>>
>> On Thu, May 12, 2016 at 10:14 PM, Lorill Crees <lcrees@xxxxxxxxxx> wrote:
>>
>>> Thanks Morten. That's great news about web-api versioning.
>>>
>>> In regards to the /api/documents endpoint, is it possible to create a
>>> document or is it read-only? I can't find documentation on that call.
>>>
>>> Halvdan - I look forward to your responses about the current available
>>> storage methods.
>>>
>>>
>>>
>>> On Wed, May 11, 2016 at 9:18 PM, Morten Olav Hansen <morten@xxxxxxxxx>
>>> wrote:
>>>
>>>> I don't think there are any plans to deprecate this endpoint right now
>>>> (we are hoping to have web-api versioning in 2.24, so that at least would
>>>> make it easier going forward). So you can assume that endpoint will
>>>> continue to live on.
>>>>
>>>> For the current available storage methods, I will let Halvdan answer
>>>> that. We already have a filestore abstraction internally (which allows for
>>>> adding files to data elements), but I'm not sure if the plans is to have
>>>> this as a more generic functionality.
>>>>
>>>>
>>>>
>>>> --
>>>> Morten Olav Hansen
>>>> Senior Engineer, DHIS 2
>>>> University of Oslo
>>>> http://www.dhis2.org
>>>>
>>>> On Thu, May 12, 2016 at 12:54 AM, Lorill Crees <lcrees@xxxxxxxxxx>
>>>> wrote:
>>>>
>>>>> Hi Morten and Team,
>>>>>
>>>>> Following up on this again. Are there still plans to deprecate the
>>>>> /api/documents functionality? And what are your recommendations on how we
>>>>> should approach the storage of dataset & program level documents? Please
>>>>> see my questions below.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Lorill
>>>>>
>>>>> On Mon, May 2, 2016 at 10:59 AM, Lorill Crees <lcrees@xxxxxxxxxx>
>>>>> wrote:
>>>>>
>>>>>> Hi - just following up on this. Any recommendations on how we should
>>>>>> approach the storage of dataset & program level documents?
>>>>>>
>>>>>> On Tue, Apr 26, 2016 at 2:13 PM, Lorill Crees <lcrees@xxxxxxxxxx>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> I just wanted to revive this old thread regarding the storage of
>>>>>>> documents in DHIS 2. We are wanting to programatically upload files into
>>>>>>> DHIS 2 that are related to Data Sets and Programs in general, for users to
>>>>>>> be able to view/download via the DHIS 2 UI.
>>>>>>>
>>>>>>> Using the file resource functionality for this would be clunky, as
>>>>>>> we would not want to have these files related to specific data values. For
>>>>>>> example, if we had District-level survey data, we would want one file to be
>>>>>>> uploaded that was related to *all* data values in this Program for a
>>>>>>> country. We could maybe have a kludge where we add one data value for this
>>>>>>> file associated with the country-level org unit but this does not seem
>>>>>>> ideal.
>>>>>>>
>>>>>>> Additionally it doesn't seem easy via the DHIS 2 UI to actually
>>>>>>> view/download the files themselves. I see the RESTful url for the file is
>>>>>>> shown as a link in the data entry screen, but don't see another way to get
>>>>>>> at the files via the UI without constructing the RESTful url for the Web
>>>>>>> API manually (unless I'm missing something?). It looks like we would likely
>>>>>>> need to make a DHIS 2 app to allow users more easy access to the files
>>>>>>> themselves for our particular use case.
>>>>>>>
>>>>>>> It seems that the Resource (aka Document) functionality would make
>>>>>>> more sense for us to use:
>>>>>>> http://<server>/dhis-web-reporting/displayViewDocumentForm.action
>>>>>>> /api/documents
>>>>>>> We could have a kludge where we reference the Data Set or Program
>>>>>>> via naming convention.
>>>>>>>
>>>>>>> However, in reading this thread I see that the plan is to deprecate
>>>>>>> /api/documents altogether. I also couldn't find documentation regarding
>>>>>>> this API call and how to actually create a resource(document) via the API.
>>>>>>>
>>>>>>> I did notice in another thread "Using DHIS File Store" that
>>>>>>> supporting "standalone" file resources is a feature that is in the
>>>>>>> pipeline. Is there any ETA for that functionality?
>>>>>>>
>>>>>>> Do you have any recommendations for us of how we should tackle this
>>>>>>> use case?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Lorill
>>>>>>>
>>>>>>> On Fri, Jul 31, 2015 at 5:59 AM, Halvdan Grelland <
>>>>>>> halvdanhg@xxxxxxxxx> wrote:
>>>>>>>
>>>>>>>> Yes, eventually we could probably do that.
>>>>>>>>
>>>>>>>> First order of business is really to allow (external) files to be
>>>>>>>> stored in lieu of the value field of DataValue. The details of how the
>>>>>>>> model will look in the end is still to be decided and is very much
>>>>>>>> dependent on the requirements of the storage backend (I'm experimenting
>>>>>>>> with Apache jClouds to do this at the moment) and the range of uses we
>>>>>>>> envision within DHIS2.
>>>>>>>>
>>>>>>>> I would not recommend hacking a solution together using the
>>>>>>>> datavalue.value field. It might work (kind of), but is hardly scalable and
>>>>>>>> will be (I assure you) a complete pain to maintain and will be hard to
>>>>>>>> migrate when we eventually get a more integrated solution to this
>>>>>>>> requirement.
>>>>>>>>
>>>>>>>> As for ETA It's a bit up in the air currently. As said, it's proven
>>>>>>>> to be complex to implement properly.
>>>>>>>>
>>>>>>>> Btw. Morten, there is an api/files endpoint (it's used to manage
>>>>>>>> custom css/js). ;)
>>>>>>>>
>>>>>>>> 2015-07-29 11:38 GMT+02:00 Morten Olav Hansen <mortenoh@xxxxxxxxx>:
>>>>>>>>
>>>>>>>>> We also already have the /api/documents endpoint, is the idea to
>>>>>>>>> somehow merge these similar functionalities? Maybe we need a /api/files
>>>>>>>>> endpoint.. and we can deprecate /api/documents (and then later replace it
>>>>>>>>> with a document store as it has been discussed before... always wanted to
>>>>>>>>> remove /api/documents)
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Morten
>>>>>>>>>
>>>>>>>>> On Wed, Jul 29, 2015 at 6:16 AM, Halvdan Grelland <
>>>>>>>>> halvdanhg@xxxxxxxxx> wrote:
>>>>>>>>>
>>>>>>>>>> Definitely agree! The working title at the moment is 'file
>>>>>>>>>> resource', which seems to be descriptive enough and not too generic.
>>>>>>>>>>
>>>>>>>>>> 'Document' as it exists right now in dhis2 is really only local
>>>>>>>>>> storage with a relative path in the DB. 'File resources' could potentially
>>>>>>>>>> replace that (as a more flexible back end).
>>>>>>>>>>
>>>>>>>>>> (There are other questions brought up that I'd like to address
>>>>>>>>>> but I'm on my phone on terrible hotel wifi at the moment so will come back
>>>>>>>>>> to those).
>>>>>>>>>> On 28 Jul 2015 4:45 pm, "Morten Olav Hansen" <mortenoh@xxxxxxxxx>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> I don't like that we at naming the bp document. Let's file it a
>>>>>>>>>>> file api.
>>>>>>>>>>>
>>>>>>>>>>> As much as possible I want to save the wording document until we
>>>>>>>>>>> implement a proper nosql document storage.
>>>>>>>>>>>
>>>>>>>>>>> We already have /api:documents which I want to remove (I doubt
>>>>>>>>>>> many external apps depend on it)
>>>>>>>>>>>
>>>>>>>>>>> On Tuesday, July 28, 2015, Elmarie Claasen <elmarie@xxxxxxxx>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi all, there is a blueprint for this already
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> https://blueprints.launchpad.net/dhis2/+spec/document-dataelement-attribute-type
>>>>>>>>>>>>
>>>>>>>>>>>> Elmarie
>>>>>>>>>>>> On 28 Jul 2015 11:27 AM, "Greg Rowles" <greg.rowles@xxxxxxxxx>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Halvdan
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sounds great and a good alternative! I'd like to work through
>>>>>>>>>>>>> an example or two:
>>>>>>>>>>>>>
>>>>>>>>>>>>> We have annual performance plans made up of multiple quarterly
>>>>>>>>>>>>> reports so I would expect there to be 2 data sets:
>>>>>>>>>>>>>  - Annual Performance Plans (fYear)
>>>>>>>>>>>>>  - Quarterly Performance Reports (fQuarter)
>>>>>>>>>>>>>
>>>>>>>>>>>>> If we configure these data sets to include a single data
>>>>>>>>>>>>> element of type 'Text' what name would we give to this element? 'Document'
>>>>>>>>>>>>> or 'File'?
>>>>>>>>>>>>>
>>>>>>>>>>>>> We're currently experimenting with ownCloud for document
>>>>>>>>>>>>> storage as an interim solution. I guess nothing stops us from loading the
>>>>>>>>>>>>> ownCloud URL into datavalue.value?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>> Greg
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, Jul 28, 2015 at 10:49 AM, Harsh Atal <
>>>>>>>>>>>>> harsh.atal@xxxxxxxxx> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hello Halvdan,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *We are planning on introducing files as a type for data
>>>>>>>>>>>>>> values, as well as data elements supporting this (document, images). You
>>>>>>>>>>>>>> would then use the datavalue model to implement these types of
>>>>>>>>>>>>>> requirements.*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ^^This is exactly what is needed by us. I didn't know this
>>>>>>>>>>>>>> was already in the works!!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> May be its a bit early to ask but.....for which version is
>>>>>>>>>>>>>> this planned for? It will be of immense use in one of our projects.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> regards
>>>>>>>>>>>>>> harsh
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 28 July 2015 at 14:10, Halvdan Grelland <
>>>>>>>>>>>>>> halvdanhg@xxxxxxxxx> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> We are planning on introducing files as a type for data
>>>>>>>>>>>>>>> values, as well as data elements supporting this (document, images). You
>>>>>>>>>>>>>>> would then use the datavalue model to implement these types of requirements.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The implementation is in the works but is a fairly complex
>>>>>>>>>>>>>>> beast as we're juggling actual files outside of the database (we consider
>>>>>>>>>>>>>>> in-db storage of large blobs uscalable and a generally bad idea). We're
>>>>>>>>>>>>>>> also planning to enable offloading this to third party cloud storage (eg
>>>>>>>>>>>>>>> amazon s3).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm on holiday at the moment but please respond if you have
>>>>>>>>>>>>>>> any comments and I'll get back to you when I can.
>>>>>>>>>>>>>>> On 28 Jul 2015 10:02 am, "Greg Rowles" <
>>>>>>>>>>>>>>> greg.rowles@xxxxxxxxx> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi All
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> These are the concepts we've been thinking about:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> DocumentSet, DocumentSetLevel, Document.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> [DocumentSet] would similar to data sets in that they are
>>>>>>>>>>>>>>>> cyclical. They may have different periodTypes (e.g. yearly, fYealy,
>>>>>>>>>>>>>>>> quarterly, fQuarterly, onChange) and may be compulsory. These include
>>>>>>>>>>>>>>>> performance plans, development plans, mandatory reporting requirements,
>>>>>>>>>>>>>>>> policy documents or content originating in other domains. A DocumentSet may
>>>>>>>>>>>>>>>> have a design template (or default document) from which users borrow layout
>>>>>>>>>>>>>>>> for their submissions.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> [DocumentSetLevel] is the orgunitlevel associated with
>>>>>>>>>>>>>>>> DocumentSet (and possibly a compulsory y/n field). This caters for
>>>>>>>>>>>>>>>> mandatory reporting requirements across different levels of the DHIS
>>>>>>>>>>>>>>>> hierarchy.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> [Document] would be the actual object and associated meta
>>>>>>>>>>>>>>>> data (DocumentID, name, uid, description, owner, creationdate,
>>>>>>>>>>>>>>>> organisationUnitID, DocumentSetID, {startdate:enddate/periodid},
>>>>>>>>>>>>>>>> downloadURL, etc)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Not sure how the actual document content would be hosted,
>>>>>>>>>>>>>>>> stored or even what solutions are available right now but if the following
>>>>>>>>>>>>>>>> concepts were available through API calls - it would make life really easy
>>>>>>>>>>>>>>>> for us here in SA...
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>> Greg
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Tue, Jul 28, 2015 at 9:07 AM, Jason Pickering <
>>>>>>>>>>>>>>>> jason.p.pickering@xxxxxxxxx> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Ah, I get the requirement now. This would be documents
>>>>>>>>>>>>>>>>> which would be uploaded as part of a data set submission. Yeah, this is not
>>>>>>>>>>>>>>>>> really currently supported as far as I can tell, but it would be a good
>>>>>>>>>>>>>>>>> idea.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>> Jason
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Tue, Jul 28, 2015 at 8:37 AM, Harsh Atal <
>>>>>>>>>>>>>>>>> harsh.atal@xxxxxxxxx> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Hi
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Related to this we also have a similar requirement where
>>>>>>>>>>>>>>>>>> the functionality for document upload is required as part of normal data
>>>>>>>>>>>>>>>>>> entry.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Basically, a person has to visit a facility for
>>>>>>>>>>>>>>>>>> inspection and taking photos of the facility is part of that inspection.
>>>>>>>>>>>>>>>>>> These photos then have to be uploaded as a kind of appendix along with the
>>>>>>>>>>>>>>>>>> routine data entry of the inspection form.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> regards
>>>>>>>>>>>>>>>>>> harsh
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 28 July 2015 at 11:08, Jason Pickering <
>>>>>>>>>>>>>>>>>> jason.p.pickering@xxxxxxxxx> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hi Greg,
>>>>>>>>>>>>>>>>>>> You can always simply upload the supporting document as
>>>>>>>>>>>>>>>>>>> a resource and then make it available through a dashboard.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Otherwise, maybe you could write a more specific
>>>>>>>>>>>>>>>>>>> blueprint?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>>> Jason
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Mon, Jul 27, 2015 at 8:59 PM, Calle Hedberg <
>>>>>>>>>>>>>>>>>>> calle.hedberg@xxxxxxxxx> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Greg,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> As far as I know, this is just an idea that Lars and I
>>>>>>>>>>>>>>>>>>>> have been chatting about. I'll bring it up during the expert academy to get
>>>>>>>>>>>>>>>>>>>> wider inputs
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>>>>>> calle
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 27 July 2015 at 12:33, Greg Rowles <
>>>>>>>>>>>>>>>>>>>> greg.rowles@xxxxxxxxx> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Hi Devs
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I heard there is talk for supporting document storage
>>>>>>>>>>>>>>>>>>>>> as part of DHIS2 but I don't find any plans on launchpad. Can anyone
>>>>>>>>>>>>>>>>>>>>> confirm?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Kind Regards,
>>>>>>>>>>>>>>>>>>>>> Greg
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>> *Health Information Systems Program - South Africa*
>>>>>>>>>>>>>>>>>>>>> *- - - - - - - **- - - - - - - **- - - - - - - **- -
>>>>>>>>>>>>>>>>>>>>> - - - - - **- - - - - *
>>>>>>>>>>>>>>>>>>>>> Mobile  :    073 246 2992
>>>>>>>>>>>>>>>>>>>>> Landline:   021 554 3130
>>>>>>>>>>>>>>>>>>>>> Fax:          086 733 8432
>>>>>>>>>>>>>>>>>>>>> Skype:      gregory_rowles
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> *******************************************
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Calle Hedberg
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 46D Alma Road, 7700 Rosebank, SOUTH AFRICA
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Tel/fax (home): +27-21-685-6472
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Cell: +27-82-853-5352
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Iridium SatPhone: +8816-315-19274
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Email: calle.hedberg@xxxxxxxxx
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Skype: calle_hedberg
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> *******************************************
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> Jason P. Pickering
>>>>>>>>>>>>>>>>>>> email: jason.p.pickering@xxxxxxxxx
>>>>>>>>>>>>>>>>>>> tel:+46764147049
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> Jason P. Pickering
>>>>>>>>>>>>>>>>> email: jason.p.pickering@xxxxxxxxx
>>>>>>>>>>>>>>>>> tel:+46764147049
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> *Health Information Systems Program - South Africa*
>>>>>>>>>>>>>>>> *- - - - - - - **- - - - - - - **- - - - - - - **- - - - -
>>>>>>>>>>>>>>>> - - **- - - - - *
>>>>>>>>>>>>>>>> Mobile  :    073 246 2992
>>>>>>>>>>>>>>>> Landline:   021 554 3130
>>>>>>>>>>>>>>>> Fax:          086 733 8432
>>>>>>>>>>>>>>>> Skype:      gregory_rowles
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> *Health Information Systems Program - South Africa*
>>>>>>>>>>>>> *- - - - - - - **- - - - - - - **- - - - - - - **- - - - - -
>>>>>>>>>>>>> - **- - - - - *
>>>>>>>>>>>>> Mobile  :    073 246 2992
>>>>>>>>>>>>> Landline:   021 554 3130
>>>>>>>>>>>>> Fax:          086 733 8432
>>>>>>>>>>>>> Skype:      gregory_rowles
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> 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
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> *This message and any attachments are subject to a disclaimer
>>>>>>>>>>>> published at http://www.hisp.org/policies.html#comms_disclaimer
>>>>>>>>>>>> <http://www.hisp.org/policies.html#comms_disclaimer>.  Please read the
>>>>>>>>>>>> disclaimer before opening any attachment or taking any other action in
>>>>>>>>>>>> terms of this electronic transmission.  If you cannot access the
>>>>>>>>>>>> disclaimer, kindly send an email to disclaimer@xxxxxxxx and a copy will be
>>>>>>>>>>>> provided to you. By replying to this e-mail or opening any attachment you
>>>>>>>>>>>> agree to be bound by the provisions of the disclaimer*.
>>>>>>>>>>>>
>>>>>>>>>>>> *This message and any attachments are subject to a disclaimer
>>>>>>>>>>>> published at http://www.hisp.org/policies.html#comms_disclaimer
>>>>>>>>>>>> <http://www.hisp.org/policies.html#comms_disclaimer>.  Please read the
>>>>>>>>>>>> disclaimer before opening any attachment or taking any other action in
>>>>>>>>>>>> terms of this electronic transmission.  If you cannot access the
>>>>>>>>>>>> disclaimer, kindly send an email to disclaimer@xxxxxxxx and a copy will be
>>>>>>>>>>>> provided to you. By replying to this e-mail or opening any attachment you
>>>>>>>>>>>> agree to be bound by the provisions of the disclaimer*.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> --
>>>>>>>>>>> Morten
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> 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
>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>
>>
>> --
>> Lars Helge Øverland
>> Lead developer, DHIS 2
>> University of Oslo
>> Skype: larshelgeoverland
>> lars@xxxxxxxxx
>> http://www.dhis2.org <https://www.dhis2.org/>
>>
>>
>