search

orppst / pst-gui

web based front end for the tool
Mozilla Public License 2.0
0 stars 0 forks source link

export / import #86

Closed alan-stokes closed 4 months ago

alan-stokes commented 6 months ago

This ticket covers the augmentation of download (to be renamed export) to include a xml / json version of the proposal and a import which takes a exported xml / json and reloads it with new ids etc. The expectation if the imported version is a submitted proposal is to ask the user if its to be considered a new proposal or a submitted proposal.

testing will include making a unsubmited proposal, download / export, import and modify values, and ensure the original project doesn't exhibit changes.

testing will also include making a submitted proposal (linked to ticket: https://github.com/orppst/pst-gui/issues/87) which when imported, will ask the user in which form to include it (submitted or a new un-submitted version). modify values, and ensure the original project doesn't exhibit changes if un-submitted, and ensure no changes are possible if submitted.

pahjbo commented 5 months ago

The only other thing to consider is that there might be accompanying files (images, plots) with the proposal - for now perhaps we can consider separate downloading for those, but I guess that it would be nice for the end user if both the xml/json of the main proposal as well as the accompanying files were exported as a zip/tar bundle

alan-stokes commented 5 months ago

@pahjbo those "supporting documents" are already downloaded into the zip. That came from the original download work. That means from the point of view of the export, its not needing to worry about that. Unless of course, there's other files outside of "supporting documents" field.

the upload of these documents is the bit which is nasty. The draft PR description discusses it in a wee bit of detail, but basically, unless we can find a good way to create a REST request with 1. a JSON object 2. a list of file data. So that we can have a stateless REST API, and allows us to use a transaction on the server side to handle any failures in such a way as to avoid loads of delete requests. I personally dont know how to do that. I've done 1 file stream before, ................. I guess we could send the entire zip to the server.............. mmmmmmmmm....................

slightly annoyed at this, coz im about 80% through the initial client implementation........ but sending the zip would allow the rest API to be stateless............... I think i'll stick with this initial implementation, so that we can get it done by end of play next week. But with a new ticket to convert this to server side at a later date. Im on ANDES this week, so maybe in the week ill decide to go the other way..... lol

alan-stokes commented 5 months ago

I have decided that I need to do it via the server. it got to the point with the client side that it was getting errors about objects not being saved, and I felt it was at a point where i might as well do it the proper way. So the PR is getting gutted now.

that being said, i did realise i needed to prefix all supporting docs with some text to stop any risk of overwriting the json object (i probably actually need to also ensure they dont have documents with the same name, to avoid that issue as well).

AllanEngland commented 4 months ago

This is now complete.