eclipse-apoapsis / ort-server

A scalable server implementation of the OSS Review Toolkit.
https://eclipse-apoapsis.github.io/ort-server/
Apache License 2.0
19 stars 8 forks source link

Expose enumerable data as enum types in V1 API data model #281

Open Etsija opened 5 months ago

Etsija commented 5 months ago

In create run form of the ORT Server UI, we are currently required to duplicate the list of the available package managers for the Analyzer, and subsequently, a list or report formats for Reporter. This requires manual code maintenance, which is not optimal.

In V1 API 's data model (Repository.kt), the repository types are specified with an enum class

    enum class RepositoryType {
        GIT,
        GIT_REPO,
        MERCURIAL,
        SUBVERSION,
        CVS
    }

This generates an enum type for UI query schemas, which we can use straight away.

In AnalyzerJobConfiguration() data class (JobConfigurations.kt), enum type is not used for package managers, but rather

    val disabledPackageManagers: List<String>? = null,
    val enabledPackageManagers: List<String>? = null,

so the list of possible package managers is not exposed to the UI.

Same goes for ReporterJobConfiguration(), where the report formats are specified as

    val formats: List<String> = emptyList(),

It should be investigated, whether the list of available package managers and report formats could be specified with enum types, which could then be used in the UI directly, without manual maintenance.

There are some other examples in the data model, where enum types would be of use to the UI, for example

    val projectScanners: List<String>? = null,
    val scanners: List<String>? = listOf("ScanCode"),
sschuberth commented 4 months ago

we are currently required to duplicate the list of the available package managers for the Analyzer

This becomes esp. important once https://github.com/eclipse-apoapsis/ort-server/issues/377 is implemented, as additional package manager plugins for the analyzer could be added dynamically.

Etsija commented 1 month ago

@wkl3nk your PR #753 implemented the "Groups" endpoints, for which I am now implementing the UI support. The groupId parameter is not specified as an enum class, but a string (although semantically it is of enum type, as there is only a finite number of groups available). This means we need to repeat the possible groups in the UI code when validating the add/remove user forms:

const GroupEnum = z.enum(['admins', 'writers', 'readers']);

As described in this issue, it would reduce repetitive code if the groupId would use an enum type.