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
