dhis2-devs team mailing list archive

[Lorill Crees <lcrees@xxxxxxxxxx>]

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/>
>
>