job config in api

master
Martin Polanka 8 years ago
parent 167422a9b3
commit c937137dda

@ -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 allow extending the system with additional authentication methods, login details
are stored in separate entities. There is the `Login` entity class which are stored in separate entities. There is the `Login` entity class which
contains a user name and password for our internal authentication system, and 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. 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 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 ### 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 ### Solution Loading

Loading…
Cancel
Save