dhis2-devs team mailing list archive

[Lorill Crees <lcrees@xxxxxxxxxx>]

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