• server status, ping it once every 60-120 seconds
• downloading files to a cache + then copying them to their proper location
• a way for users to see how much space the cache takes up and a way to delete the cache

Will require some amount of refactoring

Add a button in the client settings page to delete all files in the AppLocalData directory

There are some logic that the frontend handles (e.g. determining download/upload/conflict lists) that may be better suited on the Rust side. At the very least we could move the logic into its own TS file to make the UI code shorter.

• Measure time elapsed for functions

• permission dashboard when setting someone's permission
• when downloading/uploading files

Currently we make a GET request for each file to get its S3 link; If we make one big request for all the S3 links we need we should be able to see some sort of performance increase. This will require a change on the server side too.

• measure time elapsed while downloading files
• supported change on server side
• implement change, measure time elapsed

This will provide more feedback when downloading/uploading a large amount of files when increments in the progress bar are difficult to see.

only occurs in production, not yarn tauri dev

• sometimes occurs after making a change

this will allow us to easier describe file changes in the website. this will require some changes on the server and database (e.g., adding a new column to the file table)

As a result this blocks the close/upload button

• reported by ian u

• crashes when solidworks is open (experiement more with this)
• text is broken (says 4 of 4 reset, then 5 of 5... etc)

#17 could potentially fix/mitigate this; something could also be borked with base.json or compare.json too after downloading non-conflicting files

to reproduce:

• make changes in project dir
• sync
• download changes
• sync

at this point the client doesn't recognize your changed files as things to upload

edit:

• on download, use results from /info/project to populate base.json
• on upload, current implementation is likely ok but could change it to upsert uploaded files into base.json
• when updating project directory, reset base.json

Current implementation is fine (ish), just slow. we can do better

This is most apparent when there is a file conflict. If A.txt has updates available and A.txt was edited locally, resetting A.txt will download the most recent changes instead of resetting A.txt to before the changes.

The current implementation doesn't make it clear that the user needs to hit Save Changes in order to save the new project directory.
So either:
a) Warn the user to save changes when they try to navigate away

b) Save the project directory immediately upon selecting one

reported by a couple users

Since we moved + refactored much of the logic for syncing changes, this issue is for tracking what has been tested.

download:

• identifying files to create/update
• identifying files to delete
• initializing a fresh install
• format presented for toDownload.json is parsed properly by download page
• partial downloads supported

upload:

• identifying files with the right change type
• format presented for toUpload.json is parsed properly by upload page
• partial uploads

conflicts:

• properly identify conflicts