#384 run results auditing and tracking enhancement to report option #385
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…rg to kelaberetiv
When \\ is used, it becomes executed as \. When \t is used it becomes executed as tab. This is because eval() is used to derive dynamic variables. This patch converts \ in input to \\ so that the input gets executed as intended and retains its original form after passing through the eval function.
Positive test case signature for patch. When \\ is used, it becomes executed as \. When \t is used it becomes executed as tab. This is because eval() is used to derive dynamic variables. This patch converts \ in input to \\ so that the input gets executed as intended and retains its original form after passing through the eval function.
There is likely a change in Chrome Devtools protocol which returns back DOM.attributeModified event messages after DOM.setFileInputFiles method is used in update step. This causes subsequent steps after upload step not to work. This patch works by filtering and discarding the DOM.attributeModified event messages so that subsequent communication messages with Chrome will continue to work.
There is likely a change in Chrome Devtools protocol which returns back DOM.attributeModified event messages after DOM.setFileInputFiles method is used in update step. This causes subsequent steps after upload step not to work. Patch 1 works by filtering and discarding the DOM.attributeModified event messages so that subsequent communication messages with Chrome will continue to work. Patch 2 works by filtering and discarding DOM. events completely. And also send a DOM.disable call to disable further sending of DOM. event messages.
… errors Sending a PR to handle previously unhandled errors that are outside of missing UI elements, error-handling during step and integrations execution, unrecognizable steps, missing parameters etc. An example would be referencing a variable that is not yet declared - ``` ReferenceError: Can't find variable: abc /Users/kensoh/Cloud Drive/Marketing/Website/api/tagui/src/phantomjs:/code/demo.js:1386 /Users/kensoh/Cloud Drive/Marketing/Website/api/tagui/src/phantomjs:/platform/casper.js:1685 in runStep /Users/kensoh/Cloud Drive/Marketing/Website/api/tagui/src/phantomjs:/platform/casper.js:414 in checkStep ``` --- With this PR, the following standard error message from TagUI will be displayed instead - ``` ERROR - can't find variable: b ```
…port option Sending a PR to enhance report option. In current state when report option is used, TagUI will generate a HTML log file, in addition to the usual text log file. With this enhancement, when the report option is used, TagUI will track the run results in a csv spreadsheet (tagui/src/tagui_report.csv), along with html logs that persist with a running number. This allows users to explicitly decide which automation flows to be tracked and tabulated in tagui_report.csv. This information may be useful for personal reference, to measure time savings from automation, for keeping a trail for auditing purpose, or perhaps facilitate sending a summary to boss. Following is an example of how tagui_report.csv will look like (time taken in seconds) - #| AUTOMATION FLOW | START TIME | FINISH TIME | ERROR STATUS | LOG FILE :--|:--|:--|:--|:--|:-- 1 | /Users/kensoh/Desktop/download_flow | Sun Apr 07 2019 17:33:58 GMT+0800 (+08) | 32.1 | SUCCESS | /Users/kensoh/Desktop/download_flow_1.html 2 | /Users/kensoh/Desktop/upload_flow | NOT STARTED | NOT FINISHED | [LINE 1] cannot understand step self-destruct | /Users/kensoh/Desktop/upload_flow_2.html 3 | /Users/kensoh/Desktop/update_flow | NOT STARTED | NOT FINISHED | [LINE 1] cannot understand step reboot computer | /Users/kensoh/Desktop/update_flow_3.html 4 | /Users/kensoh/Desktop/booking_flow | Sun Apr 07 2019 17:39:00 GMT+0800 (+08) | NOT FINISHED | cannot find confirm_booking | /Users/kensoh/Desktop/booking_flow_4.html
kensoh
added a commit
to tebelorg/TagUI
that referenced
this pull request
Apr 8, 2019
A new release of TagUI. The goal will be to create packaged installations of the changes, bug fixes and enhancements since August 2018, as well as the corresponding documentation updates. Notable changes include PRs from users on Japanese (by @ariarijp), German (@derhackler) and French (@AmirJaballah) TagUI translation engine (prior to that only English and Chinese is vetted manually by me). And the recent PRs I sent on aisingapore#350 enabling dynamic variables in live mode, aisingapore#352 enabling datatable in test mode, aisingapore#371 keyboard step for sending complex keystrokes to the screen, aisingapore#369 mouse step for low-level mouse down and up actions on the screen, aisingapore#366 enabling interacting with UI elements by specifying their (x,y) coordinates, aisingapore#362 mouse_xy() / mouse_x() / mouse_y() helper functions, aisingapore#383 graceful error handling for unexpected and unhandled errors, aisingapore#385 enhancement to report option that has auditing and tracking capability. Last, and most importantly, migration from SikuliX v1.1.3 to SikuliX v1.1.4. This is because in between the 2 versions there is a move from much older OpenCV and Tesseract to major new versions. Performance and accuracy (image finding and OCR from image to text) should improve. However, I would imagine the greater accuracy may cause the automation results of some use cases to be different, as more accurate text gets retrieved and more accurate image gets found. Ie, scripting base on somewhat imperfect anchors and placeholders can sometimes break when the anchors and placeholders improve and are no longer the same, if you know what I mean. Due to this reason, this release will be a major release to v5.0 as users, particularly users of visual automation, are encouraged to validate that the new release with SikuliX v1.1.4 is still giving the kind of automation results they want, or make modifications if needed, before they migrate to the new TagUI release.
kensoh
added a commit
that referenced
this pull request
Apr 8, 2019
…nCV & Tesseract) (#388) Sending some PR(s) on a new release of TagUI. The goal will be to create packaged installations of the changes, bug fixes and enhancements since August 2018, as well as the corresponding documentation updates. Notable changes include PRs from users on Japanese, German and French (removed names otherwise will spam them with notification) TagUI translation engine (prior to that only English and Chinese is vetted manually by me). And the recent PRs I sent on #350 enabling dynamic variables in live mode, #352 enabling datatable in test mode, #371 keyboard step for sending complex keystrokes to the screen, #369 mouse step for low-level mouse down and up actions on the screen, #366 enabling interacting with UI elements by specifying their (x,y) coordinates, #362 mouse_xy() / mouse_x() / mouse_y() helper functions, #383 graceful error handling for unexpected and unhandled errors, #385 enhancement to report option that has auditing and tracking capability, #387 ability to disable generation of .log .raw .js files by default Last, and most importantly, migration from SikuliX v1.1.3 to SikuliX v1.1.4. This is because in between the 2 versions there is a move from much older OpenCV and Tesseract to major new versions. Performance and accuracy (image finding and OCR from image to text) should improve. However, I would imagine the greater accuracy may cause the automation results of some use cases to be different, as more accurate text gets retrieved and more accurate image gets found. Ie, scripting base on somewhat imperfect anchors and placeholders can sometimes break when the anchors and placeholders improve and are no longer the same, if you know what I mean. Due to this reason, this release will be a major release to v5.0 as users, particularly users of visual automation, are encouraged to validate that the new release with SikuliX v1.1.4 is still giving the kind of automation results they want, or make modifications if needed, before they migrate to the new TagUI release. --- In addition, #387 disable logging and generation of .raw .js .log files after each run Sending a PR that lets users switch the logging off by default. The default TagUI behaviour is generating .raw (expansion of modules and subscripts), .js (generated JavaScript code), .log (log of what happened during the automation. This feature would probably be useful by default for developers. For business users, probably they would not be close enough to the nitty gritty of files to bother with these files. However, there may be a use scenario where such logs are explicitly not wanted. Whether for the minimalist movement, save environment with non-excessive use of non-necessary storage or perhaps for privacy and security reasons. With this PR, users only need to put a file tagui_no_logging (can be empty or has contents) in the tagui/src folder. When this file exists, TagUI will delete the .js .raw .log files after executing the script. Thus when `tagui flow` is run there won't be flow.js flow.log flow.raw after execution.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Sending a PR to enhance report option. In current state when report option is used, TagUI will generate a HTML log file, in addition to the usual text log file.
With this enhancement, when the report option is used, TagUI will track the run results in a csv spreadsheet (tagui/src/tagui_report.csv), along with html logs that persist with a running number.
This allows users to explicitly decide which automation flows to be tracked and tabulated in tagui_report.csv. This information may be useful for personal reference, to measure time savings from automation, for keeping a trail for auditing purpose, or perhaps facilitate sending a summary to boss. Following is an example of how tagui_report.csv will look like (time taken in seconds) -