dhis2-devs team mailing list archive

[Lorill Crees <lcrees@xxxxxxxxxx>]

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