Potential hosting a database as part of the protocol?

[Martin-Jung]

Although it is aimed so that end users can upload their protocol files as appendix to a peer-reviewed manuscript or similar, it might be a very helpful idea to save the filled out protocols somewhere, possibly as part of the repository (for example in a branch or specific folder like examples).

Storing information on a server and github repository however comes with several potential issues and security risks:

1. Spam prevention: There needs to be some soft of profanity and dummy checks (avoid people adding advertising, spam or insults as entries).
2. The storing of the information should not open security holes (people uploading malware). Ideally only text information is stored
3. How to handle private information that people would not be willing to share? For example, the corresponding email.
4. How to avoid duplicate entries?
5. Considering the use case of someone wanting to update a previously entered protocol? How can this be supported?
6. Where exactly should the protocols be stored apart from the server? One idea could be to regularly make a commit/push to a separate branch of the repository?
7. How to handle different mirrors of the protocol, for example hosted on shiny-apps? Ideally this needs to be regularly synchronized.

Potential implementation upon clarification of the above cases:

• [ ] Add a checkbox option to the export page where users can clarify if they want to host the filled out protocol in the database.
• [ ] Store entered protocols either as csv or in a simple self-contained database file (e.g. sqlite, duckdb ?).
• [ ] Add a database entry to the menu that simply renders all previously entered protocols as Name | Lead | URL together with two buttons with the csv and docx file.

[jeffreyhanson]

Yeah, this a great idea! I like your idea of a checkbox that users can toggle to have their data stored permanently. If the app is hosted on a private server, this might not be too difficult to implement. But if on a service like shinyapps (or in a docker container), then it might be a bit more complicated to ensure that the storage is persistent. You'll probably want some storage solution that can handle concurrency well (e.g., ensuring you get sensible results if two people try saving data at approximately the same time). Happy to chat about this if it would be helpful?

[Martin-Jung]

Yeah, It might be more practical to support this only on the IIASA hosted instance and add a check internally that transfers entered protocols to the instance (and adds them there) somehow. I don't think I can open an API port or similar and I would prefer storage of simple text files and exports to avoid unnecessary risks. Current idea is to essentially store a self-contained sqlite database file somewhere on the folder and then simply access it.

Anyway, for any of this to work a still missing thing to implement some checks that mandatory and other fields have been entered correctly upon export/submission. Really scared that as soon as the platform parsesand collates inputs, it gets used as a spam dump requiering lots of manual curation 🥲