Community
Participate
Working Groups
Need to rework the log import ui as described in the JPG image attached.
Created attachment 52419 [details] New log import wizard
Created attachment 52444 [details] Should replace previous JPEG Should replace previous JPEG
Created attachment 52955 [details] Mockup Made minor updates to previous mockup: 1. Import log sets should have a default path. 2. Show most recent adapters selected at top of list
*** Bug 159446 has been marked as a duplicate of this bug. ***
Some text from duped requirrement: A user typically starts the troubleshooting process knowing that they need the log for a specific product, but may not know specifically which log to look in or even specifically which logs will be there. Currently, if they enter a path, then change the adapter, the path they just typed or selected is erased. Multiple logs of different types in the same path are far more likely than multiple logs of the same type. The process of pointing to a log is cumbersome, and seems to be optimized for importing multiple logs of the same type (which may happen occasionally, but not frequently). The user should be able to point to files first, without specifying the type, then specify the filter and any additional parameters. The flow should be something like this: 1) Start RCP application 2) Click File > Import Log Files (as shown in figure 1.0) 3) A wizard like the TPTP log import wizard appears 4) Select the host name and log file to be imported using an Open dialog that supports multiple select (Note that this is different than the series of dialogs required now). 5) Select the log file type for each one 6) Optionally specify the filter to be used to import log file under “Filter” tab 6) Click on OK 7) Click on Finish 8) System begins import Result: The log files are imported, content of all imported events across event source are displayed under the log view, and imported log show selected in treeview. We can provide designs when needed.
This is for both RCP and IDE
In your mockup, how does remote log import fit in? Import log set dialog is not applicable for remote log import as user are not allowed to broswe remote host, and user will have to define a host first for remote log import. Also, what should the default log location be set?
(In reply to comment #7) > In your mockup, how does remote log import fit in? Import log set dialog is not > applicable for remote log import as user are not allowed to broswe remote host, > and user will have to define a host first for remote log import. I added a second branch to the mockup. I don't have a second machine to connect to remotely, so let me know if I missed anything that is needed. It looked like you could have a list of machines in Eclipse, but I was not sure why that would be the case. Is this a priority list? The approach lets users select remote logs and local ones at the same time if they like. > Also, what should the default log location be set? > Default should be the last valid location entered. It will be wrong much of the time, but will probably be partially right. I would think most people would set up a temp directory, and have a seperate directory for each issue, so they can edit the text that is there.
Created attachment 56070 [details] Mockup -includes remote paths
The list of hosts is for user to quickly select any host that was added in history from previous run. localhost(RAC connection) and direct connection (IAC connection) are the default items in the list. The new mockup looks okay to me. I assume the 'Add Log' button in the first shot will show a drop down menu that list 'local' and 'remote', and the user flow splits base on the choice there. I suggest the test connection button to be grouped with host and port and layout to the right side of the two input fields, as it is logically related to the two input fields only. Thanks Jeff!
(In reply to comment #10) > The list of hosts is for user to quickly select any host that was added in > history from previous run. localhost(RAC connection) and direct connection (IAC > connection) are the default items in the list. > > The new mockup looks okay to me. I assume the 'Add Log' button in the first > shot will show a drop down menu that list 'local' and 'remote', and the user > flow splits base on the choice there. > > I suggest the test connection button to be grouped with host and port and > layout to the right side of the two input fields, as it is logically related to > the two input fields only. > > Thanks Jeff! > Yes, I think these make sense. it would probably make sense to make the host a dropdown that defaults to the last host entered.
Host name should be configurable if needed by the tooling. If log is transfer by tooling from the remote host to local host by any other file transfer method and then all the processing is done on the local host, there should be a way to add that log/s to remote host node in the navigator. This is also applies to the FTP transfer log from the remote machine and then import locally in the tooling, but host node should be with remote host name. This is very important because then delta time (Time offset) can be apply based on host. With the current implementation delta time offset can not apply correctly because all the remote logs are added in local host node. Also there should be a way to enable/disable the host name TAB in the import wizard. Need UCD input on this how actually this would look like in above scenarios
(In reply to comment #12) I am going on vacation for the week after today, so we should talk before I leave if possible. > Host name should be configurable if needed by the tooling. I don't understand this comment. In the design I sent users can change the name. Are you saying the tooling should be able to do this automatically from the context file? > If log is transfer by tooling from the remote host to local host by any other > file transfer method and then all the processing is done on the local host, > there should be a way to add that log/s to remote host node in the navigator. > This is also applies to the FTP transfer log from the remote machine and then > import locally in the tooling, but host node should be with remote host name. > This is very important because then delta time (Time offset) can be apply based > on host. With the current implementation delta time offset can not apply > correctly because all the remote logs are added in local host node. > Also there should be a way to enable/disable the host name TAB in the import > wizard. > Need UCD input on this how actually this would look like in above scenarios > I understand what you are asking in general, but am confused about a lot of the details. Basically: 1. Where the filtering is done depends on the protocol used for transfering files. 2. This also affects the delta time filtering. I do not see where this stuff is done in the current LTA Eclipse. Can users select the protocol? I don't see the time skew either. Are you talking about the default TPTP part or some of the IBM extensions?
I am talking about the default TPTP part. Currently in TPTP user can add delta time per log and/or per host. If log is imported by other means like FTP but not using RAC, log is added in the Local host node. SO now if user wants to apply the delta time to that log, user needs to apply on perticulare log. User can't apply delta time to host which may not be valid in this case.
We have shown the proposed enhancement to the import flow based on feedback from users. The basic idea is that the Log Import flow should be reversed. Users should be able to select files first, then map to the filters to the files afterwards. This is a more efficient flow, for several reasons (Figure numbers refer to attachment): 1. Users can point to an entire directory at a time to select all of the files. Right now, they can do this BUT they all need to be the same log types. The scenario can happen, but is less likely than a directory with heterogeneous file types. 2. Users do not have to specify an adapter for file types that should not need an adapter such as CBE formatted logs. 3. This approach allows the user to use a history to reuse commonly-used adapters. This will be far more common than reusing file/path combinations. The flow should be as follows (the assumption is that the user has completed the flow several times and has history menus populated): 1. User opens Import Log dialog (Figure 1) 2. User clicks Add / Add Logs and points to one or more directories (Figure 2). This dialog supports multiple-select and also the ability to specify the host. 3. The selected files appear in the Import Log dialog (Figure 3). 4. The user clicks the dropdowns under Adapter and Version for the systemout, systemerror and trace (these values are all already in the history). At this point, the user can also specify filters for each log. 5. The user clicks the dropdown icons under Adapter and Version for the activity log. For most logs, these two settings would suffice, but in this case another parameter is required, so an icon appears next to the checkbox (See Figure 4). In this case, the user has to click Edit and provide values in the Choose Adapter dialog (Figure 5). The Choose Adapter dialog also provides a history list. Selecting an item from this menu pre-populates the dialog with those values, but they can still be changed. 6. User specifies all the required properties for the db2diag.log and the Finish button is enabled.
Created attachment 61684 [details] Updated import flow
Created attachment 62132 [details] Mockup
Resolving this as WONTFIX because it is no longer required by the consumer that requested it.
Change target to 4.4.1 when the resolution happened.
Additionally, we should include a better way of selecting version and adapter. -The options should be for the ranges of adapters, not the version of the product. -Static vs rules should be a separate decision. We should have whichever one makes the most sense selected by default.
Closing.
