System administrators

Page tree

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »


Introduction & Background

If an error occurs in the graphical user interface of translate5, detailed information is required by the user in order to be able to reproduce the error and thus be able to correct it.

theRootCause.io provides an easy way to capture and analyze errors in the frontend.

Without therootcause.io, only the information (if any) that is obvious on the surface is transmitted by the respective user by telephone, is therefore technically incomplete, and rarely allows the error to be reproduced, as the necessary detailed information is missing (eg where errors occurred in the program code).

This is significantly improved by the use of the external service therootcause.io, because this way many technical information and data about the state of use in the case of an error (and if the user so desires) are stored. For this purpose, usage data of the application is transmitted to the external service therootcause.io. The collected data is only visible there after authentication by username and password. Depending on your request, therootcause.io can either set up a separate account (if desired, also with direct access for MittagQI to the account), or the data will be collected in the MittagQI account.

The use of the service contributes significantly to the improvement of translate5.

Enable reporting bugs

Step 1: Enable reporting bugs by configuration

By configuration, the admin can

  • enable theRootCause in the translate5 instance ( Zf_configuration flag: enableJsLogger)

Step 2: User can send reports

If theRootCause is enabled in Zf_configuration and an error occurs, the user will be asked to decide if this error gets reported or not.

Enable Video-Recording

Step 1: Enable video recording in general for your users by configuration

By configuration, the admin can

  • enable video recording of bugs in the translate5 instance (Zf_configuration flag: enableJsLoggerVideo)

The video-recording only starts when a segment is opened for editing and stops when the editing ends.

Step 2: User can activate video-recording after login

If the video recording is activated in Zf_configuration and by the user and the user reports an error that occured, a video is sent to the server.

Every user decides by himself, if s/he wants video recording activated, after s/he logs into translate5.  Directly after log in, the user is presented the following text:

Help translate5's development with screen videos in case of errors

For a number of errors it is only possible for translate5's Open Source development team to reproduce and fix them, if user actions that led to the error are recorded as video. Only what happens inside translate5 will be recorded. The video-recording only starts when a segment is opened for editing and stops when the editing ends.

translate5's team would be very thankful, if you activate this feature - thank you very much in advance!

If the video recording is activated, video recordings are only sent, when you report an error that occurred.

Otherwise videos are deleted automatically, when your browser session ends.

Videos that are connected to an error and have been sent to the server are deleted, when they are not needed any more for fixing of the error. The only usage purpose of the videos is translate5s development, and the data will be only used for this purpose.

More information about video recording with theRootCause and data protection you can find at ...

Then the user can click 2 buttons: "Activate" and "Disable".

Step 3: User can send reports with or without video

When an error occurs, the user still can choose to not report the error at all (and thus the video is not kept, but deleted).

By disabling the “Steps to reprocude”-checkbox before sending the error, the user can report the error, but the video will not be sent.

Data Protection

Background to the therootcause.io

The service is offered by Bryntum based in Sweden.
For the data collected, Bryntum writes in the Terms of Use:
7. Personal data
7.1 BAB processes all customer data, including any personal data therein, solely for the customer's purposes and according to the customer's written instructions. BAB acts as data processor with regards to the processing of customer data in relation to the customer which acts as the data controller.
7.2 BAB wants to take any technical and organizational measures to protect customer data as required by law.
BAB stands for Bryntum.
Complete version: https://therootcause.io/terms-of-service/

Location Of Personal Data

For the location of personal data, Bryntum writes in the Privacy Policy:
• The database servers for the Service are located in The Netherlands, hosted by Digital Ocean (GDPR compliant)
Complete version: https://therootcause.io/privacy-policy/

Data collected

From a technical point of view, translate5 from therootcause.io loads program code (under the responsibility of Bryntum), which then has access to the application.
A data transfer from the application to therootcause.io can only be triggered if an application error occurs: Before sending the data, the user must actively agree (the "Feedback Button" function offered by theRootCause is not used by translate5).

Data in case of an application error

If an application error occurs, the user is presented with a window that informs about this. If the user agrees, the error, as well as some application data for the error (selectable by the user) will be transmitted to therootcause.io.
The user can also add a remark and an e-mail address. These fields are not preassigned and optional.
The user can also partially select in the window which of the following information will be sent:
1. Application-specific data for the error (this data is always sent along)
◦ where in the Javascript code in which context (stack trace) the error occurred (here, no content data is transmitted)
◦ other logged events (further errors, which API calls were made from the interface - also without content)
◦ the error message itself
2. Screenshot
◦ a screenshot of the application at the time of the error
◦ enabled by default, can be disabled by the user before sending
3. Actions of the user (this allows the cause of the error to be reproduced completely)
◦ all actions of the user in the form of mouse movements, clicks and keystrokes within the application (does not affect the login window!)
◦ enabled by default, can be disabled by the user before sending the error information.
◦ not mandatory for MittagQI
4. Cookies
◦ contains the session number with which the current user session can be accepted
◦ enabled by default, can be disabled by the user before sending the error information
◦ not necessary for MittagQI
5. System information (always transferred)
◦ operating system version, browser and browser version, date / time of the user, plugin of the browser, window size of the application window
◦ disabling the “system information”-checkbox by the user before sending the error information does NOT prevent the transfer of the system information
• Data on the logged-in user (name or e-mail address) as well as data on the open review task or overview of review tasks are transmitted at most in the form of the optional screenshot, or the user actively gives this as an optional name / comment on.

Video recording

If configured and activated by the user at login, an additional video is transmitted from the segment editing, where the error occurred.

◦ Disabling the “Steps to reprocude”-checkbox before sending the error will prevent the transfer of the video.






  • No labels