-
Notifications
You must be signed in to change notification settings - Fork 217
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
#23 UI 4 config proc #1341
base: master
Are you sure you want to change the base?
#23 UI 4 config proc #1341
Conversation
Thank you very much @thiagofuer for helping with this! I plan to review this next week. |
Tasks dependecy/order are not declared in any interface or method. Is this important to order the tasks configuration panel? |
maybe sort in alphabetical order by default |
This can be found in iped.engine.config.TaskInstallerConfig class. The user shouldn't be able to change task sorting, since the execution order/task dependency is VERY sensitive. |
but the task sort could be done only on the config view without reflect on the execution order. It could be only to be easy to user found. |
"order/task dependency is VERY sensitive" |
Mainly the dependency structure needed is not for task list visual ordering. I think the best is to to exhibit on the correct execution order. It is to automatically include dependent tasks (in the correct order) when a task is checked to be included in the processing. |
I prefer to always display the processing pipeline execution order.
Good point, this is important. Notice this situation can already occur without the configuration UI, only changing config files today. Some modules check their dependencies and, if not met, they abort or disable itself printing a warning message in the Console. This approach could be improved for the UI. |
@thiagofuer, a specific task can have more than one configurable. For example, ParsingTask has ParsingTaskConfig, CategoryToExpand, Parsers and ExternalParsers configurables. Maybe a Tree instead of table can be more suitable. Something like this (pardon for the bad UI of the tree, you can improve later): |
Or the table could be kept, and each configurable of the task could be presented as a TAB in the corresponding Task config UI dialog. |
This is exactly how I thought about it. I think this is more user friendly. |
To use a tree certainly is the easy way to show tasks config, but i think that could not be the best solution for unexperienced user.
this is the more user friendly UI option. Most of effort spent in this job is to create a interface that can do IPED "easy" to operate.
|
Maybe as Tabbed panels
Em ter., 1 de nov. de 2022 15:52, Thiago S. Figueiredo <
***@***.***> escreveu:
… @thiagofuer <https://github.com/thiagofuer>, a specific task can have
more than one configurable. For example, ParsingTask has ParsingTaskConfig,
CategoryToExpand, Parsers and ExternalParsers configurables.
Maybe a Tree instead of table can be more suitable. Something like this
(pardon for the bad UI of the tree, you can improve later):
[image: image]
<https://user-images.githubusercontent.com/28692427/199321295-d807768f-a723-4611-b0ec-ee3475f249ea.png>
To use a tree certainly is the easy way to show tasks config, but i think
that could not be the best solution for unexperienced user.
Or the table could be kept, and each configurable of the task could be
presented as a TAB in the corresponding Task config UI dialog.
this is the more user friendly UI option. Most of effort spent in this job
is to create a interface that can do IPED "easy" to operate.
[image: image]
<https://user-images.githubusercontent.com/1029909/199325157-d5d3eb15-7ff1-4b74-86cd-f52f3852da19.png>
On my opinion, we should think on how to add all additional tasks
configurables on this dialog. Tabs is a good one!!
—
Reply to this email directly, view it on GitHub
<#1341 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AG247S4EBXYU6UEVRF6ZTHTWGFYIJANCNFSM6AAAAAAQX73M7A>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Sorry, I'm a bit busy now...
This already exists, but the method is not static. Wouldn't it be enough? |
yes. I found. it is enough.
Em sex., 4 de nov. de 2022 09:36, Luis Filipe Nassif <
***@***.***> escreveu:
… Sorry, I'm a bit busy now...
@lfcnassif <https://github.com/lfcnassif> , I could not find a way to
identify which Configurable objects are used by each AbstractTask. I think
in put it as a static method of class AbstractTask with the signature Set>>
getConfigurables(). So we can identify which configurable classes is used
to instantiate the Task, and look for this kind of objects in the
ConfigurationManager object.
This already exists, but the method is not static. Wouldn't it be enough?
—
Reply to this email directly, view it on GitHub
<#1341 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AG247S3DZTNL5TIQGFHAJ2DWGUGMFANCNFSM6AAAAAAQX73M7A>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
This method (getConfigurables) is implemented in the AbstractTask descendants classes to return empty configurable objects. Not the loaded one from the files. Maybe they are implemented in a little different way from what the Config UI may need. Config UI must know which kind of configurable a Task (or other kind of objects) needs, so it can create the appropriate UI. |
Yes, this should be better. Currently they return a new instance that then is populated by ConfigurationManager. Reusing already existing ones should be better. |
Although the great majority of current AbstractTask implementations is instanced once, ScriptTask and PythonTask is instanced more than once, one for each script file. Maybe, other future AbstractTasks will permit to be instanced more than once. @lfcnassif , what do you think? Do we keep the checkbox style task installation on UI, making some kind of exceptions only to script tasks that needs to be installed more than once, or should find another kind of UI? |
Hi @patrickdalla, this week I'm attending 7th DFEG Interpol Conference, so I may be slow to respond.
I think we should keep the checkbox list layout and write custom code to handle ScriptTasks and PythonTasks. Actually each Worker thread creates his own Tasks instances, so all of them are instantiated more than once on most machines. I think we should avoid putting the same Tak twice in the processing pipeline, that could be confusing. I couldn't think on a more user friendly layout, but I'm open for suggestions. |
Right |
@thiagofuer I tried to push my updates to a new branch in your FORK, but it seems I don't have permission. |
I kept the table UI and created a tabbed panel interfaces to each task. The tabs implements an created abstract ConfigurablePanel class. I have implemented subclasses of this class for UTF8Properties, String and generic Bean objects. I have also implemented profile selection and new profile creation code. Not complete yet, though. |
Should distributed defined profiles be editable, removable? |
Great!!! Thank you @patrickdalla! I haven't seen your code yet, but I thought about some dynamic UI to handle common property types automatically (e.g. String -> JTextField, Boolean -> RadioButton, Integer -> ScrollButton, Enum -> JCombobox, etc), so devs wouldn't need to always implement config panels, although they could override them, maybe you have also implemented that too... Just a final comment (again I haven't seen your code, sorry if this does not fit) AbstractTasks should run on environments without screens, so no Swing or AWT classes should be instantiated from them. |
I think they should be read only (save button disabled), non removable and new profiles could be created based on existing ones. If anyone disagrees, please let us know. |
i sent you an invite to my repo access. |
Hi @marcus6n, how are your tests with this PR going? |
Hi @lfcnassif, I'll finish the tests this afternoon and get back to you with the results. |
iped.app.home.newcase.tabs.caseinfo.CaseException: IPED-SearchApp not found.
at iped.app.home.newcase.tabs.caseinfo.CaseInfoManager.validateCasePath(CaseInfoManager.java:21)
at iped.app.home.opencase.OpenCasePanel.lambda$createTableButtonsPanel$0(OpenCasePanel.java:92)
at java.desktop/javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
at java.desktop/javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
at java.desktop/javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
at java.desktop/javax.swing.DefaultButtonModel.setPressed(Unknown Source)
at java.desktop/javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
at java.desktop/java.awt.Component.processMouseEvent(Unknown Source)
at java.desktop/javax.swing.JComponent.processMouseEvent(Unknown Source)
at java.desktop/java.awt.Component.processEvent(Unknown Source)
at java.desktop/java.awt.Container.processEvent(Unknown Source)
at java.desktop/java.awt.Component.dispatchEventImpl(Unknown Source)
at java.desktop/java.awt.Container.dispatchEventImpl(Unknown Source)
at java.desktop/java.awt.Component.dispatchEvent(Unknown Source)
at java.desktop/java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.desktop/java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.desktop/java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.desktop/java.awt.Container.dispatchEventImpl(Unknown Source)
at java.desktop/java.awt.Window.dispatchEventImpl(Unknown Source)
at java.desktop/java.awt.Component.dispatchEvent(Unknown Source)
at java.desktop/java.awt.EventQueue.dispatchEventImpl(Unknown Source)
at java.desktop/java.awt.EventQueue$4.run(Unknown Source)
at java.desktop/java.awt.EventQueue$4.run(Unknown Source)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
at java.desktop/java.awt.EventQueue$5.run(Unknown Source)
at java.desktop/java.awt.EventQueue$5.run(Unknown Source)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
at java.desktop/java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.desktop/java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.desktop/java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.desktop/java.awt.EventDispatchThread.run(Unknown Source) Cause: This error occurs when the system tries to validate the case path and cannot find the IPED-SearchApp application, even though the application is located within the case folder.
iped.app.home.newcase.tabs.caseinfo.CaseException: The case process is not finished
at iped.app.home.newcase.tabs.caseinfo.CaseInfoManager.validateCasePath(CaseInfoManager.java:23)
at iped.app.home.opencase.OpenCasePanel.lambda$createTableButtonsPanel$0(OpenCasePanel.java:92)
at java.desktop/javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
at java.desktop/javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
at java.desktop/javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
at java.desktop/javax.swing.DefaultButtonModel.setPressed(Unknown Source)
at java.desktop/javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
at java.desktop/java.awt.Component.processMouseEvent(Unknown Source)
at java.desktop/javax.swing.JComponent.processMouseEvent(Unknown Source)
at java.desktop/java.awt.Component.processEvent(Unknown Source)
at java.desktop/java.awt.Container.processEvent(Unknown Source)
at java.desktop/java.awt.Component.dispatchEventImpl(Unknown Source)
at java.desktop/java.awt.Container.dispatchEventImpl(Unknown Source)
at java.desktop/java.awt.Component.dispatchEvent(Unknown Source)
at java.desktop/java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.desktop/java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.desktop/java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.desktop/java.awt.Container.dispatchEventImpl(Unknown Source)
at java.desktop/java.awt.Window.dispatchEventImpl(Unknown Source)
at java.desktop/java.awt.Component.dispatchEvent(Unknown Source)
at java.desktop/java.awt.EventQueue.dispatchEventImpl(Unknown Source)
at java.desktop/java.awt.EventQueue$4.run(Unknown Source)
at java.desktop/java.awt.EventQueue$4.run(Unknown Source)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
at java.desktop/java.awt.EventQueue$5.run(Unknown Source)
at java.desktop/java.awt.EventQueue$5.run(Unknown Source)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
at java.desktop/java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.desktop/java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.desktop/java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.desktop/java.awt.EventDispatchThread.run(Unknown Source) Cause: This error occurs when the system tries to validate the case path, but the process associated with the case has already been completed. PS: @lfcnassif, can you check and confirm these errors I found? |
Thanks @marcus6n for testing. Unfortunately this week I'm with no available time to work on this. @patrickdalla could you take a look at the errors pointed by @marcus6n? |
@marcus6n, I just fixed error 5 and other issue when opening multicases. Error 4 didn't happen to me. |
Examiner and Case ID. |
Stopping for today. Documenting to don't forget:
|
…lternate string for "auto" as is used for parameter num threads for LocalConfig.
"Every time a task is enabled or disabled in the main task table selection, a NPE is printed:" |
"If I enable OCR or some other tasks and create a new profile, processing fails at the beginning with:" |
Thanks @patrickdalla!
Yes, it seemed an issue with LocalConfig->numthreads parameter not being handled/saved correctly. |
I have some suggestions. Place a parameter in LocalConfig.txt to save the default directory for case output folder when clicking the directory choice button. Fix buttons with icons without tooltip... Add the option to choose "portable" processing... The "Evidence Details" and "Choose the disk to be processed" windows should be modal... |
Thanks @gfd2020.
Yes, opening the dialogs always in user home directory is annoying, I noticed that. But I would save those last selected folders in a new file in user.home/.iped folder.
This is important. Unfortunately I'm not sure if I'll have time to implement those enhancements, since I'm becoming the head of the central digital forensic lab in my agency. I'll be on vacation on the next 2 weeks and I will try to finish the very minimum for 4.2.0 version, because it will be impossible to accomplish that during my work hours from now on... If you have available time to help us finish this PR (we need more tests and more tests, and to finish the UI translation to all 6 supported languages) that would be appreciated very much. |
hi, @lfcnassif . I found this GUI test automation tool. |
Hi @gfd2020. I'm not sure, I never used that project. UI testing is a bit difficult to automate and to cover all user interation possibilities, but what I meant was just doing more manual testing with more features/options combinations. |
This is the first part of issue #23 implementation for review and suggestion.
Layout content:
-Home page with logo and options buttons ("Open case" button not implemented yet)
-Config menu (by now it only read properties and do not write)
-New case menu
tab case info: read data but don't save
tab evidences: only "add disk" is missing
tab process options: not implemented yet
-"Start processing" is being implemented now
no internationalization ready (it's in pt-br only)
To test the new UI implementation go to iped.app.home.MainFrame and run main method
you need to setup iped properties location manually (by now its hard coded)