doc update

Installation-and-set-up/3-docker-set-up.md

 ## Add you user to the docker group via this command:
 ```bash
      sudo usermod -aG docker $USER
+```
+
+## Check if your user can run docker commands with any example:
+```bash
+     docker container ls
 ```
\ No newline at end of file

cota-frontend/0-moodle-http-security.md

 ## Delete every blocked ip adress and port in HTTP Security
+
+Moodle blocks by default any internet trafic from and to their site, even from the localhost. We need to allow traffic by deleting the needed ip adresses in the HTTP security section.
\ No newline at end of file

cota-frontend/1-moodle-plugin-installation-and-usage.md

+## Installation & Configuration
+
+After approval, install the plugin directly from the Moodle Plugins Directory via Site Administration/Plugins/Install Plugins.
+Before that or alternatively: zip the plugin code from https://transfer.hft-stuttgart.de/gitlab/HFTSoftwareProject/moodledta (here). The readily-zipped current version also sits in the repository’s main directory. Then install the plugin from zip via Site Administration/Plugins/Install Plugins, or by extracting the plugin archive to {Moodle_Root}/mod/assign/submission/dta and visiting the admins notifications page.
+Visit Site Administration/Plugins/Plugin Overview and select Settings next to the Moodle Dockerized Test Agent (MoDTA) entry to enter the URI of your backend as shown in Fig. 1.  Finally, configure via Site Administration/Security/HTTP Security settings permitting communication with the backend URI and port as seen in Fig. 2.  The plugin requires the external DTA REST webservice backend.
+Notes:
+The universal DTA REST webservice backend is available under the GPLv3 as well at https://transfer.hft-stuttgart.de/gitlab/HFTSoftwareProject/dtabackend and the docker image at https://hub.docker.com/r/hftstuttgart/dta-backend . See the documentation in the repository for the necessary setup.
+An example JDK 17 JUnit 5 test runner is available under GPLv3 as well at https://transfer.hft-stuttgart.de/gitlab/HFTSoftwareProject/dtatestrunner and the pre-built docker image at https://hub.docker.com/r/hftstuttgart/dta-jdk17-junit5-testrunner . The repository contains an example docker-compose.yaml for tests with a bitnami Moodle and MariaDB setup and the backend.
+
+## Usage
+With the MoDTA plugin installed and configured backend URI (including Moodle Security/HTTP Security settings permitting communication with that URI):
+
+### Teacher
+When creating an assignment, a teacher can select the MoDTA exercise as a new assignment type via an additional checkbox on the assignment creation page as shown at the bottom of Fig. 3.  A new standard file upload field appears  as indicated in Fig. 4. . There, the teacher must upload a text file with the git repository URI containing the tests  as shown in Fig. 5.  The text file has to adhere to the following format also given in the example repository:
+The text file has to contain the following, each separated by ::
+
+dtt as the URI-type
+<git https repository URI>
+<git user name or the fixed string “none” for publicly accessible repositories>
+<git password for the given user, git read access token for the repository, or the fixed string “none” for publicly accessible repositories>
+<docker hub image for the test runner>
+optionally, an additional line of the same structure containing a ticketing system URI, user name and password or write access token
+
+An example text file content looks like this:
+dtt::https://transfer.hft-stuttgart.de/gitlab/dtt/example_openjdk11-junit5-calculator-test.git::none::none::hftstuttgart/dta-jdk17-junit5-testrunner:latest
+Students use the same format, just without the runner part at the end.
+
+### Student
+Students use an additional MoDTA standard file upload field in the standard submission processs in Moodle like in Fig. 6. Fig. 6: Moodle DTA Student File Upload There, they place either a zip archive or a text file adhering to the same format as the teacher’s file with their code repository URI and optionally credentials and/or a ticketing system URI as shown in Fig. 7. 
+Upon completion, students see a summarized overview of their test results in an additional column of the submission feedback table like in Fig. 8.  Clicking on a new expansion icon in that column, they reach a detailed feedback dialog including stack traces of compile errors and test failures as in Fig. 9.  Optionally, the MoDTA backend creates tickets for compile failures in the ticketing system under the URI provided by the student upon hand-in.
+Note: Teachers have access to the Moodle submission result view to assess student results. However, teacher control and grading are not the focus of MoDTA.
+
+## Technical Workflow
+Assignment creation: The backend creates a temporary directory and checks out the test code from the given repository to that directory's subdirectory test. If the repository contains a file test-competencies.mft in its root directory with a structure described in the backend documentation, this enables the optional competency feedback.
+Assignment submission: The MoDTA plugin passes the submission id and submitted text or zip file – no personal teacher student data – to the external DTA backend REST web service. The DTA backend REST web service fetches or extracts the code to the temporary directory's subdirectory src. It launches via docker a dedicated test runner based on the docker image provided in the teacher’s text file. This test runner compiles and executes the code, running the teacher-defined tests to evaluate the students' submission.
+The runner returns the result in a file named result.json in the temporary directory's subdirectory result. The backend optionally enriches the result with competency feedback. It then returns the json result structure to the MoDTA moodle plugin. The MoDTA moodle plugin adds a new column to the submission result table and shows a result summary as well as an + button. Clicking on the + button, the student sees the detailed test results and, optionally, competency feedback.

cota-frontend/2-plugin-details-doc.md

+# Plugin Detail Documentation – MoDTA Assignment Submission Plugin
+The assignment submission plugin type was the most suitable choice with assignment feedback as another related option.  It empowers you to present customized form fields to students during the assignment submission process and to teachers when configuring assignment settings. Moreover, it grants complete control over how submitted assignments are displayed to both graders and students.
+The primary features of this plugin type include the ability to:
+•	Integrate additional settings into the module settings page for assignments.
+•	Provide a summary of the submission to students and teachers.
+•	Incorporate form fields into the student submission page for added flexibility and customization.
+
+## File Structure
+To ensure proper organization, all files related to the MoDTA assignment submission plugin reside in the directory path "mod/assign/submission/dta" within {Moodle_Root}.
+
+## Language
+The language files for our plugin are found under "lang/<country_code>/assignsubmission_dta.php." These files are organized into different subfolders depending on the language to be supported. For instance:
+
+English: "lang/en/assignsubmission_dta.php"
+
+The filename corresponds to the component name of the plugin, structured as _, which, in our case, is "assignsubmission_dta." The repository delivers only English as requested by the Moodle team.
+Each language file contains various key-value entries formatted as $string["key"] = "Value," with the key provided in English as the most widespread language remaining consistent across different language files, while the value varies according to the chosen language. Moodle incorporates a dedicated String API used In the plugin as required In the approval guidelines, allowing for easy value retrieval based on a given key and the selected language (e.g., get_string("key", "default value")).
+
+### version.php
+This file provides version information about the plugin to manage installation and upgrades.
+
+### settings.php
+The settings file defines two settings for the MoDTA plugin:
+
+
+### Default: 
+This setting offers a checkbox to determine whether the plugin should be enabled by default when creating a new assignment.
+
+
+### Web Service Base URL: 
+It features a text field where you can specify the base URL for the web service, facilitating file communication and actual testing.
+
+### db/upgrade.php
+This file is currently empty, as the data structure for the plugin has not changed so far.
+
+### db/install.xml
+This file defines the necessary database tables and rows for storing data associated with the MoDTA plugin. Moodle offers a specialized XML schema designed for modeling this information, featuring elements like TABLENAME, FIELDS, and KEY. The plugin utilizes two additional tables for cleanliness not to alter moodle standard tables:
+assignsubmission_dta_summary which is related 1:1 to the submission and uses the assignment_id and submission_id as foreign keys, and assignsubmission_dta_result which stores the results of a submission as a 1:n relation to the assignsubmission_dta_summary. Whenever a new MoDTA assignment is submitted, the backend web service is engaged, returning one or more test results or compilation errors in the form of a JSON string. The front end parses this JSON string for the result summary and results and stores them in the appropriate tables.
+
+### locallib.php
+This is where all the functionality for this plugin is defined. All submission plugins must define a class with the component name of the plugin that extends assign_submission_plugin .
+That yields the following class hierarchy:
+The "assign_submission_plugin" class serves as an abstract foundation that all assignment submission plugins must build upon. It incorporates a limited set of supplementary functions tailored exclusively to submission plugins. On the other hand, the "assign_plugin" class is also an abstract class, but it functions as the fundamental class for all assignment plugins, encompassing both feedback and submission plugins. This class facilitates access to the assignment instance, represented as "$this->assignment." Collectively, these two classes offer a series of public functions, often referred to as "hooks," which are designed to be overridden to implement the required functionality.
+The following provides brief descriptions of a selection of functions to illustrate the types of hooks available:
+•	get_settings(): This function comes into play during the creation of the assignment settings page. For the MoDTA plugin, this involves adding a file manager that permits teachers to upload their test repo and docker Image URI as a textfile. This function is overridden from the assign_plugin class.
+•	save_settings(): The save_settings function is invoked when the assignment settings page is submitted, whether for a new assignment or the modification of an existing one. In the MoDTA plugin, this function is responsible for preserving the text file chosen by the teacher and transmitting the file to the backend web service. Like the previous function, this one is overridden from the assign_plugin class.
+•	get_form_elements_for_user(): During the construction of the submission form, this function plays a similar role to the get_settings() function for settings. In the context of the MoDTA plugin, it adds a file manager to enable students to upload their text or zip file. Once again, this function is overridden from the assign_plugin class.
+•	save():This function is invoked to save a user's submission. Within the MoDTA plugin, this function sends the student's submission to the backend and receives the result as the response. For details see the technical details section above.
+•	view_summary(): This function is called to display a summary of the submission to both teachers and students. For the students, this summary will be shown within the submission status table and for the teachers within a column of the grading table. In the MoDTA plugin this method returns a more compact view (only essential data) for the grading table and a detailed view for the students submission status table.
+
+### lib.php
+This file serves as the gateway to various standard Moodle APIs designed for plugins. In the content of the MoDTA plugin, this function is denoted as "assignsubmission_dta_pluginfile."
+
+### Util folder
+The folder contains various utility files, e.g. displaying the new test summary pages is delegated from the locallib.php for brevity of that source.
\ No newline at end of file