Skip to main content

Public

Project privacy set to public. By default, its content is available to everyone (authenticated or not). Please note that more restrictive permissions might exist on some items.

    •  
      request #36813 Add Validating Tuleap Functions
    Actions
    Infos
    #36813
    Guilhem Bonnefille (CS) (gbonnefille)
    2024-02-09 12:05
    2024-02-09 10:00
    38397
    Details
    Add Validating Tuleap Functions

    As a Tracker Administrator,
    When I configure a Tracker
    I wish to upload a Validating Tuleap Function

    As a Tracker user,
    When I validate the changes on an Artifact
    Then a Validating Tuleap Function verifies the new values and possibly blocks the change, emitting and error message.

    Currently, the Tuleap Functions ensure the role of Mutating hooks: the artifacts values are possibly transformed automatically.

    A Validating Tuleap Function will only do checks on the values. If the checks are OK, the changes are applied. If not, an error is returned and displayed by the Web UI or REST API client.

    As possible use cases:

    • allow finest format validation for string input (verify a CamelCase syntax, verify a syntax like "toto::titi"...)
    • allow cross fields validation
    • etc. (it's a hook)

    Concerning the format:

    {"errors":[{
  "fields":[123],
  "msg":"The expected format for Field1 is CamelCase"
}]}

    Or

    {"errors":[{
  "fields":[123,456],
  "msg":"Only an administrator is able to set this combination of fields"
}]}

    The idea of the fields attribute is to let the Web UI decorate the fields concerned by the error message.

    Trackers
    All
    Empty
    • [ ] enhancement
    • [ ] internal improvement
    Empty
    Stage
    Empty
    New
    Empty
    Attachments
    Artifact links
    Empty
    Empty
    References
    References list is empty
    Display settings

    Follow-ups

    User avatar
    Manuel Vacelet (vaceletm)2024-02-09 12:05

    And what about running this hook directly on the client side?

    That's not enough, for consistency reasons it must be performed server side (REST calls).

    User avatar
    Guilhem Bonnefille (CS) (gbonnefille)2024-02-09 11:57

    Effectively...

    And what about running this hook directly on the client side? There is still the matter of the intermediate representation. Or perhaps letting the code deal with the raw HTTP form. I imagine it is possible as it seems more close to the original use case of WASM.

    In the same idea, having the ability to run such function on the client would permit to hidde/display fields based on other fields values... A use case expected by some of our users... but this is another story.

    User avatar
    Manuel Vacelet (vaceletm)2024-02-09 11:37

    We already thought about this but it's way more complex than one might think for two reasons:

    1. at this stage of request execution, we don't have an intermediate representation of the artifact (as we have for post action). The json representation is build up from [.. steps ..] but ultimately the database.
    2. the verification must be synchronous with the request, here timing are very important, each ms matters. The current execution strategy is not fast enough for this context.