RIS: Get list with trashed documents

[sebastianmanger]

Context

RIS be configured to work as an internal application (for staff users), or as a public website.

The public installation of RIS is deployed to a zone without connection to GEVER for security reasons. The internal RIS installation therefore has a publisher module, which transfers data to the public website. GEVER documents are published as PDF files with bumblebee demand jobs.

RIS "polls" GEVER with a cronjob for modified documents (and filters it according to RIS' metadata for publication) and creates PDF for these documents.

This issue should serve as discussion starter, and must not be implemented yet.

Goal

(Please keep in mind that I am not very familiar with GEVER naming. With regards to 'removed' elements this means: I do not know if they technically are trashed/deleted/archived. Basically documents that were once on display, but are not anymore.)

As RIS stores PDFs of GEVER documents, they must be deleted on RIS if they are 'removed' from GEVER.

As of now, this is handled with the @search endpoint (https://ris.onegovgever.ch/kr/@search?portal_type=opengever.document.document&metadata_fields=trashed&metadata_fields=modified&trashed:boolean=1&sort_on=modified&sort_order=descending).

According to @njohner, this may not be 100% accurate, as admins can really-really delete files. Please also talk to @jone if it comes to priority, as this may be more of a theoretical problem.

[lukasgraf]

@sebastianmanger So you need a list of deleted documents, not trashed ones, right? (Resp. both)

[sebastianmanger]

Follow-up after a quick discussion: yes, I think of trashed and deleted (and 'ausgesondert') - and possibly more...
This is a conversation starter and must not be implemented yet. It's likely that it will become an issue once RIS is installed at a place where the clients can delete documents. As of now, they can only trash them.

[sebastianmanger]

The problem (theoretically) still exists - if an admin removes a file, RIS will never know it and keeps a reference, as it is not in the response of the @search endpoint anymore. For priority, I still think this is not very important.