====== Checklist: Fixes Needed ====== ===== Key ===== * = needs to be done, status unknown * :-) = is finished ===== Items ===== ==== Need Fixing ==== * Change auto email syntax to not mention SSN and to be worded more intuitively; see [[http://umbc.edu/gradbusiness/techdocuments/systems/paradocs/umbc_custom_setup#auto_email|auto email]] for details * After Batch Completing multiple workflows, the workflow frame reloads. The frame reloads too quickly though, and the true status of each of the multiple workflows is not shown in the refresh. A subsequent refresh does show the correct actions took place. This may be a side-effect of another problem that is in this same list, pasted below. * Grouping options assumes the wrong form submission when you hit the ENTER key. On the third frame where you select either to 'Add Document to Existing SSN' or 'Start a new SSN Process'. If you are in the 'start a new ssn process' and hit the enter key after data input, the form for the other choice apparently gets run, causeing the workflow to not be created correctly. * :-( html code corrected by Nick Yeates. There was originally only one form for two submission buttons that have different effects. Now there are 2 seperate html forms which elimenated the effect above. In the PHP, there is actually what looks like 3 forms, but it is because there is a giant IF that has 2 versions of the code for different circumstances. * The above code actually did not appear to be working completly. The first option 'Add Document to Existing SSN' would say to make sure to enter a ssn (it was looking in the field on the second form). In general, multiple forms on one page is CONFUSING and maybe cannot be done. The original problem still exists. * When a different order-by column is selected, and the user or an action causes a refresh of the workflow, the order by column goes back to default. - Marie Ghazanfari * This is likely how it intentionally operates, and we would have to pay for customization. **Need Fixing Non-Critical** * Support documents are bunched into seperate groups as they are scanned (open a workflow, look in the documents pane) - Marie Ghazanfari * If support docs are scanned before an application, and the application finally comes in, the documents appear out of order when opened by the workflow * ** UPDATE** smartlink_exec.php shows documents in the right format, while wf_exec.php shows them in the above explained format ==== Need Testing ==== * :-? Send-Email action for EHS queue does not kick off; unsure if other similar actions work * :-? In scanner profiler application, when typing in an applicants profile fields and moving to the next applicant, the fields are not cleared. This may lead to incorrect data. * DaySpring systems altered code of scanners to have an additional option on the client that allows the above functionality to be turned off or on. Once the upgrade dust has settled, this scanner version should be upgraded ==== Done ==== * :-) Grouping Options window takes long amounts of time to load. In the Documents frame, when check marking some documents and then clicking on the 'Grouping Options' icon, the grouping options pop-up appears, and the frame appears, but the frame takes 10-45 seconds to populate. The more documents that were checked, the more time it takes. It reminds me of extraneous code running a loop or something on the documents. Maybe debug junk? NOTE: it is NOT a problem for user 'Admin', it is a problem for user 'ruth' * :-) Workflows get tasked eratically if the user clicks through too fast on OK boxes when doing a Batch Complete of workflows. **Ex:**A user selects 3 workflows, hits the Batch complete icon,clicks the YES verify button, and then immediatly click the Close Window button on the next page; this was a problem on the old system. * :-) umbc_sweeper.php is taking absurd amounts of time to finish (in particular, a certain SELECT process). So long, that it goes into the next update period. * :-D Batch Print gives 'not enough permissions' error for most users; the error comes up AFTER you have selected the printer to print to and verified * Bryan did a big redo of the grouping options code and this seems to work much better. * Export to spreadsheet under 'Grouping Options' gives sql error: "Invalid query : select distinct doctypeid from fat where fatid in () order by doctypeid" * Bryan did a big redo of the grouping options code and this seems to work much better. * :-)Crossover of day before does not cross over. We had an application entered 6/7/06 on SIS, and it was not importable the next day 6/8/06 11:00am by paradocs. * does not happen anymore. Can check on server daemons/cron jobs if it does. * :-) Kathie Nee and Kathy Ruth scanning machines may not work * :-) Not all documents show up in paradocs after being posted * :-) Envelopes not deleting off local machine * User permissions...installed as incorrect user maybe? * :-)No tree/group box comes up when saving the envelope; Are these documents truly getting posted correctly? * setting simply needs to be turned on in the profiler app up in the menus on the top * :-) CollegeNet import file not quite in the correct format. Need to ascertain from DaySpring the exact format they are expecting. * :-) Verify that the nightly database *.dmp files are getting deleted after a certain # of days. Currently, they keep growing, and each *.dmp file takes up 1.2 Gigs od HDD space. They are located at /usr/local/data/repository * :-) Grouping options cannot add to workflow; sometimes it will work, sometimes it wont; does not work for applicant 901015750 * :-) Turn database and other access logs on * Snort is going to be used after 6/27/06 for IP header logging * will be setup to send emails to me when bad ppl try to do stuff * :-) Grouping options cannot add to workflow; when adding a single document to an existing workflow or a new one, gives query error: "Invalid query : select distinct doctypeid from fat where fatid =" * **UPDATE** code and customization on that code was done originally by Jeremy; Bryan has heard from him and will be fixing the bzcompress related issues in the code for this functionality * Bryan has made 2 rounds of improvements to this and it needs to be thouroughly tested * Selection of certain combinations of documents makes it not work. Some times it works fully too. It is unknown which documents or what pattern makes it not work. * 6/19/06 Attempted fixed grouping options and had limited success. * re workflowing a document to be a new seperate duplicate workflow that already existed. No error message came up denoting that you are making a duplicate workflow. No duplicate workflow was created. The applicant wanted to defer their semester, so the semester had already been updated in SIS, and re workflowing it should bring in the correct semester. The old workflow would be deleted. * Yi-Fan Lee re-workflowing (exactly like case above) failed to workflow. Invalid query given when trying to submit the workflow as 'Add Document to Existing SSN'. * Nick Yeates looked at code changes made, they were most likely changes to alternate files not having to do directly with the before-discovered problem of using http GET instead of POST method to pass variables * bzcompress and bzdecompress functions were providing odd ASCII characters in the data sent in GET statements between frames. bz* was removed from all grouping options files. * :-) Workflow lines are alternating in size; they toggle in size; (login as user marieg) - Marie Ghazanfari * :-) Crossover times need to be altered to what is wanted. See [[:systems:paradocs:umbc_custom_setup#sis_-_t_import_updating]] * Email sent to OIT to change times, then paradocs will need to change times to be a few minutes after * :-) In 'Workflow Configuration Manager', the queue list is not in alphabetic order * :-) 2 reminders sent when reminder is triggered - /added by Eric, Nick, Emanuel/ * (Security) When the workflow frame is closed, and you click the workflow icon and goto 'Workflow Configuration Manager', any user can view any departments workflows and also delete or close any of their workflows. Ideal functionality would be to only allow group admins to have access to it, or some manner of deciding who has access to it. * **NOTE:** If this requires custom paid-for coding, this should not be implemented UMBC. It is still a security risk for us and possibly other paradocs implementations though. * :-) Set workflow to sort by lastname in user prefs, if this was existant on old system * :-) In the Documents frame, there is sometimes excessive text that looks like it is debuging text that says "links:". In the source code it looks like this: links: 4 * :-) In the Tree node tool; not many grouping options are working * :-) When a query is run, the first entry box is not defaulted to by the cursor. The user has to click on the text box and then type. Check out the Search Applications by SSN query. - /added by Nick/ * :-) error.txt in cnetimport samba share directory does not give any useful error information like it used to. It is mostly blank besides the date, and the file is constantly there (never disapeears) * :-) Archive job (paradocs scheduler) needs to be created for nightly system cleaup (ex: cleans up download directory) * :-) Get ParaSync to work * **UPDATE** Was kicked off; is it done now? How can we test it? * **UPDATE** See [[systems:paradocs:technical_documentation#parasync offsite backup]] * :-) FIXME Fix issue of all workflows ending in 'Graduate School' step. There is a necessity to leave all past workflows in its last task because of an unrelated usability issue. This happens when a given applicant applies and the workflow has been completley closed out (a decision has been made), then some extraneous documents for that applicant trickle in weeks or months later. Those extra documents currently trigger the autoworkflow customization and make a new workflow for this already-dealt-with applicant. A fix is needed to block autoworkflow of application instances that have had a workflow in the past. Notification to a user that this has occured would be nice to have also. * **UPDATE** Eric suggests that the cost of system overhead leaving completed workflows on the last step is affecting system performance. It is unknown what the impact would be to return to completing workflows; therefore, we should begin completing steps and evaluate a procedural workaround. * There are odd cases that pop up as well to concern ourselves with: * An applicant applies, gets rejected, documents trickles in, they are blocked , but then the applicant applies again for the same major in a subsequent semester. We dont want the new seperate application to be blocked from starting a new workflow. * **UPDATE** This would not occur if workflows would be completed as suggested. * An arbitrary applicants workflow goes sour. To remedy it, a user passes the workflow on or deletes the workflow entirely with the plans to re-scan the applicant from start. In this case, the re-scanned documents may get autoworkflow blocked. The person scanning in from new will not be aware that the workflow did not start and the entire application will be effectively lost in the shuffle. * **UPDATE** This would not occur if workflows would be completed as suggested. * :-) CollegeNET applic