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 #13440 REST API: Project shortname is forced to lowercase characters
    Actions
    Infos
    #13440
    Houssem Eddine Azzouz (heazzouz)
    2019-06-28 10:25
    2019-05-30 14:51
    14550
    Details
    REST API: Project shortname is forced to lowercase characters
    This problem occurs when project related information is retrieved using REST API (project & svn). The project's "shortname" figures among the several properties returned in the JSON output. The API subroutines are expected to provide the shortname respecting its case. However, project shortnames are transformed to lowercase.
    API
    All
    Empty
    • [ ] enhancement
    • [ ] internal improvement
    Empty
    Stage
    Empty
    Closed
    2019-06-27
    Attachments
    Artifact links

    Releases

    Fixed in

    Artifact ID Project Tracker Summary Status Last Update Date Submitted By Assigned to
    rel #13415 Tuleap Releases 11.4 Delivered 2019-25-07 10:42 Marie Ange Garnier (marieange)
    By Houssem Eddine Azzouz (heazzouz)
    (36 kB)
    1 -- Project definition - case sensitive.PNG
    1 -- Project creation
    By Houssem Eddine Azzouz (heazzouz)
    (24 kB)
    2 -- SVN-Test-repo.PNG
    2 -- SVN repo creation
    By Houssem Eddine Azzouz (heazzouz)
    (8 kB)
    3 -- Response.PNG
    3 -- The output of the API subroutine
    References
    Referencing request #13440

    Git commit

    tuleap/tuleap/stable

    Merge 'gerrit #15149' into stable/master 1e2145c001
    User avatar Thomas Gerbet (tgerbet) , 2019-06-27 18:42
    request #13440 REST API: Project shortname is forced to lowercase characters f55020ca67
    User avatar Houssem Eddine Azzouz (heazzouz) , 2019-06-27 18:11
    Referenced by request #13440

    Artifact Tracker v5

    rel #13415 11.4

    Other

    gerrit #15149
    Display settings

    Follow-ups

    User avatar
    Thomas Gerbet (tgerbet)2019-06-27 18:47
    gerrit #15149 integrated into Tuleap 11.3.99.6.

    Thanks for your first contribution @heazzouz!
    • Status changed from Waiting for information to Closed
    • Reported in version changed from 11.1 to All
    • Connected artifacts
    • Close date set to 2019-06-27
    • Platform cleared values: EL7 (CentOS|RHEL)
    User avatar
    Manuel Vacelet (vaceletm)2019-06-10 13:41

    Should I develop and propose it as a contribution ?

    If you're willing to, you sure can !

    User avatar
    Houssem Eddine Azzouz (heazzouz)2019-06-10 10:43
    Hello again,

    I also believe that adding the repository URL to the GET /svn/{id} representation is the fittest solution. Should I develop and propose it as a contribution ?
    User avatar
    Thomas Gerbet (tgerbet)2019-06-07 11:44
    Hello,

    Manually building URLs is not something that is supported. To support this use case we probably should add the repository URL in the representation returned by GET /svn/{id}.

    The REST route GET /project/{id} is working as expected.
    User avatar
    Houssem Eddine Azzouz (heazzouz)2019-06-07 11:16
    The problem is related to the use case of constructing the URLs of SVN repositories using the shortname that is retrieved from the API.
    The SVN repos URLs have to include the "real" case shortname otherwise they won't work.
    User avatar
    Houssem Eddine Azzouz (heazzouz)2019-05-31 12:29
    Hello Manuel,

    Here is an example (view screenshots in attachments):
    1. A new project called "A Test Project" is created with its property shortname set to "aTESTproject00"
    2. The SVN service is activated and a repository is created under the name "Test-repo1"
    3. The API subroutine GET /projects/{id}/svn is called to list the SVN repos under "A Test Project" : the JSON outputs the shortname is lowercase characters
    User avatar
    Manuel Vacelet (vaceletm)2019-05-31 09:51

    Could you share an example where the shortname mistmatch in the API ?

    (FWIW, most if not all the API is desgined to rely on IDs and resources URIs to avoid this case issue)