Bug #3336
Feature #1511: Reporting v3
Source code analytics defect punch list
Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
Due date:
% Done:
0%
billable:
No
vendor_id:
GCD
case_num:
Related issues
History
#1 Updated by Eric Faulhaber over 6 years ago
A summary of the remaining, known defects, originally posted in #1514-177:
- Metadata tables/fields not represented in schema reports and source view
- Source view highlight not right for some schema artifacts (ranges not correct for tables and fields in many cases)
- Source view highlight not correct (2 lines off vertically) when viewing very bottom of any source file
- Source/AST view layout not correct when linked from Visualize Call Graph screen (extends beyond containing border horizontally)
- Old height algorithm used when resizing call graph view (new algorithm used for initial view) -- perhaps we add a skip list or selector parameter to
getAvailableHeight
function inmain.js
, so this algorithm can be used when components are already added to DOM. - Loading overlay is stilted/blocked when used with a long-running client-side operation (e.g., when loading filter profiles for large projects), due to single threading on client
- AST view is very closely packed vertically and is illegible for broad trees (e.g., when viewing level 0 for most external procedures). Should extend beyond top and bottom view boundaries, requiring panning or zooming.
- Multi-user use is problematic in some cases
- The
active_file
global temp-table is used in read mode for nearly every report; it is written to whenever a user logs in. If a long-running report is using this table in one session, a user can be blocked from logging in at all, since the request to acquire the write lock on this table will time out. - Activating a filter profile also causes writes to the shared
active_file
temporary table. So, though I have not tested this, I assume we will have similar issue when trying to activate a filter profile in one session while a long-running report is being built in another.
- The
- Clicking on the expand/collapse "twisty" in the tablulator can be tricky. It seems so sensitive as to be error prone.
- Performance issues
- Reports for large projects can take a very long time to build, especially with non-default file filter profiles
- Ad-hoc search and custom reports can take a very long time to run with large projects -- they are single-threaded and visit every AST (except when active filter is applied for search)
- Loading filter profiles causes a long-running client operation for large projects, as it leverages the checkbox tree's logic to manage nested branches/nodes
- Investigate: certain server APIs write to the database (e.g., adding a custom report, updating search history, etc.). Do we need to explicitly synchronize these APIs or is the database's normal locking behavior enough?
#2 Updated by Eric Faulhaber over 6 years ago
- Copied from Feature #1514: implement fully dynamic reports (backed by the database) added