From d5eca120bcdb2ed1b20cb4afd3ad8c3243244d1c Mon Sep 17 00:00:00 2001 From: John Cardinal Date: Tue, 30 Jun 2020 14:07:13 +0000 Subject: [PATCH] --- ayanova/devdocs/todo.txt | 59 ++++++---------------------------------- 1 file changed, 8 insertions(+), 51 deletions(-) diff --git a/ayanova/devdocs/todo.txt b/ayanova/devdocs/todo.txt index 0c033400..141fb431 100644 --- a/ayanova/devdocs/todo.txt +++ b/ayanova/devdocs/todo.txt @@ -3,54 +3,18 @@ PRIORITY - ALWAYS Lowest level stuff first, i.e. TODO at server, api route changes etc then back here in order lowest level first as affects the most stuff exponentially so best to do it early =-=-=-=- -todo: delete all attachments for object - then make sure it's added to tag and search delete code for all coreobjects at server -qqqqq todo: Administration - Attached files manager replicate v7 - add Attachments checker job that checks on demand all files and stuff as per below - What can go wrong: - Attachment files are accidentally directly deleted or db restored and not files resulting in bunch of fileattachment records with links to non-existent files - SWEEPER JOB - Flags these as non-existent so user can see that in UI and figure out how to fix it, by restoring the file or deleting the attachment record - DB records are deleted but file remains (orphaned) - SWEEPER JOB - Attaches these files to the NOTYPE object - FOREIGN FILES placed in folder directly outside of attachment system - user thinks they can just drop them in or accidentally copies them here - Or, user renames a folder for some reason? - This is a good reason not to delete them, because they can just un-rename them to fix it - SWEEPER JOB - I think it should delete them outright, but maybe that's a bad idea, not sure - ID them to see if they *should* be one of ours by the file name I guess since it's the only identifying characteristic - is it in the correct folder which is named based on it's hash? - Is it X characters long (they all are or not?) - Does it have an extension? None of ours have an extension - - OBJECT DELETED BUT ATTACHMENTS NOT DELETED - so has fileAttachment record but no matching object - it should be checking if the parent corebiz object exists and if not set to type NOTYPE and no ID - - - - - - - - - make a datalist to return this + DELETE bulk OP delete selected file Attachments db record and physical file if present or just the fileAttachment if missing the physical file This is how you fix broken missing file links, because it's bulk it's not too onerous - - download file from dbmanager - rename? - open attached object - show icon of object type in grid - show full physical path and name - (going to be hella long) + + Add physical file path to grid data + REplace notes with physical file path for grid but keep notes in there as an option` + MOVE bulk op Select one ore more files then select MOVE UI pops up to select object type and manually type in the id @@ -69,18 +33,11 @@ todo: Administration - Attached files manager Delete parent object attachments should delete (verify not doing it with user?) - todo: need size in db record to display - todo: need a wayt to display a typeid field in grid - probably rare so just do it to support this exact case and then can expand later if necessary (YAGNI principle) - Need a TID ui data type - change data-table ui column generator to support it - look for email type 11 to find all the spots - way to implement is to include the two column names of the values to use as the tid column at server end - like the db table names but instead they are column names + Test move one or more files from notype to a specific object + Test bulk delete files - todo: pass function to grid to generate virtual column from client side? - But then sort and filter and ....blah blah blah +############################# todo: BUG widget form now always dirty for some fucking reason, fuck this shit, fuck.