job config in api

Rewritten-docs.md

@@ -3136,11 +3136,11 @@ The `User` entity class contains data about users registered in ReCodEx. To
 allow extending the system with additional authentication methods, login details
 are stored in separate entities. There is the `Login` entity class which
 contains a user name and password for our internal authentication system, and
-the `ExternalLogin` entity class, which contains an identifier for an external login
+the `ExternalLogin` entity class, which contains an identifier for an external
-service such as LDAP. Currently, each user can only have a single authentication
+login service such as LDAP. Currently, each user can only have a single
-method (account type). The entity with login information is created along with
+authentication method (account type). The entity with login information is
-the `User` entity when a user signs up. If a user requests a password reset, a
+created along with the `User` entity when a user signs up. If a user requests a
-`ForgottenPassword` entity is created for the request.
+password reset, a `ForgottenPassword` entity is created for the request.
 
 A user needs a way to adjust settings such as their preferred language or theme.
 This is the purpose of the `UserSettings` entity class. Each possible option has
@@ -3380,9 +3380,33 @@ does not have to worry about it.
 
 ### Job Configuration Parsing and Modifying
 
-@todo how the YAML is parsed
+Even in the API the job configuration file can be loaded in the corresponding
-@todo how it can be changed and where it is used
+internal stuctures. This is necessary because there has to be possibility to
-@todo how it can be stored to a new YAML
+modify particular job details, such as the job identification or the fileserver
+address, during the submission.
+
+Whole codebase concerning the job configuration is present in the
+`App\Helpers\JobConfig` namespace. Job configuration is represented by the
+`JobConfig` class which directly contains structures like `SubmissionHeader` or
+`Tasks\Task` and indirectly `SandboxConfig` or `JobId` and more. All these
+classes have parameterless constructor which should set all values to their
+defaults or construct appropriate classes.
+
+Modifying of values in the configuration classes is possible through *fluent
+interfaces* and *setters*. Getting of values is also possible and all setters
+should have *get* counterparts. Job configuration is serialized through
+`__toString()` methods.
+
+For loading of the job configuration there is separate `Storage` class which can
+be used for loading, saving or archivation of job configuration. For parsing
+storage uses the `Loader` class which does all the checks and loads the data
+from given strings in the appropriate structures. In case of parser error
+`App\Exceptions\JobConfigLoadingException` is thrown.
+
+Worth mentioning is also `App\Helpers\UploadedJobConfigStorage` class which
+takes care of where the uploaded job configuration files should be saved on the
+API filesystem. Can be also used for copying all job configurations during
+assignment of exercise.
 
 ### Solution Loading