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 <lcr...@2paths.com> 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 <l...@dhis2.org> > 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 <lcr...@2paths.com> 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 <mor...@dhis2.org> >>> 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 <lcr...@2paths.com> >>>> 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 <lcr...@2paths.com> >>>>> 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 <lcr...@2paths.com> >>>>>> 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 < >>>>>>> halvda...@gmail.com> 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 <morte...@gmail.com>: >>>>>>>> >>>>>>>>> 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 < >>>>>>>>> halvda...@gmail.com> 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" <morte...@gmail.com> >>>>>>>>>> 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 <elma...@hisp.org> >>>>>>>>>>> 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.row...@gmail.com> >>>>>>>>>>>> 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.a...@gmail.com> 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 < >>>>>>>>>>>>>> halvda...@gmail.com> 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.row...@gmail.com> 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.picker...@gmail.com> 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.a...@gmail.com> 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.picker...@gmail.com> 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.hedb...@gmail.com> 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.row...@gmail.com> 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@lists.launchpad.net >>>>>>>>>>>>>>>>>>>>> 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.hedb...@gmail.com >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Skype: calle_hedberg >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> ******************************************* >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> Jason P. Pickering >>>>>>>>>>>>>>>>>>> email: jason.p.picker...@gmail.com >>>>>>>>>>>>>>>>>>> tel:+46764147049 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> Jason P. Pickering >>>>>>>>>>>>>>>>> email: jason.p.picker...@gmail.com >>>>>>>>>>>>>>>>> tel:+46764147049 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> *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@lists.launchpad.net >>>>>>>>>>>>>>>> Unsubscribe : https://launchpad.net/~dhis2-devs >>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> *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@lists.launchpad.net >>>>>>>>>>>>> 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 disclai...@hisp.org 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 disclai...@hisp.org 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@lists.launchpad.net >>>>>>>>>>> Unsubscribe : https://launchpad.net/~dhis2-devs >>>>>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> 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 >>> >>> >> >> >> -- >> Lars Helge Øverland >> Lead developer, DHIS 2 >> University of Oslo >> Skype: larshelgeoverland >> l...@dhis2.org >> http://www.dhis2.org <https://www.dhis2.org/> >> >> >
_______________________________________________ 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
