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
