Impossible to update internal_tracker settings on a repo via the API

[Crocmagnon]

Environment

• Gitea version 1.13.2
• Git version: not relevant
• Operating system: Official Docker image running on Ubuntu
• Database:
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes, using swagger
  • No

Description

When using the PATCH /repos/{owner}/{repo} endpoint, values set inside internal_tracker are not applied. I tried with either the full internal_tracker object or a subset, the behavior is the same: the properties are not applied.

Expected: when setting one or more values in the nested internal_tracker object and making a PATCH request, the corresponding settings are updated in the database.

Steps to reproduce (detailed)

• Create an account
• Create a repository
• Go to the settings page
• Ensure both "Use built-in issue tracker" and "Enable time tracking" are enabled
• Create a personal access token for the API
• Go to /api/swagger
• Find the PATCH /repos/{owner}/{repo} endpoint under "repository"
• Fill the fields with your username and the repo just created
• Fill the body with

{
  "internal_tracker": {
    "enable_time_tracker": false
  }
}

• Click on execute
• The request returns a 200 status code
• Go to the settings page of your repo
• Observe the time tracker setting still enabled.

[anton-khimich]

Hmm, it looks like PATCH /repos/{owner}/{repo} does not modify some fields at all (at least the ones I tested). I'll take a look into it.

[anton-khimich]

1. So currently, you must provide "has_issues": true in the PATCH request if you wish to modify any field in "internal_tracker".
2. Additionally, if internal_tracker is provided, any field that you do not provide in internal_tracker will be set to false.
3. Also, the response from PATCH does not contain up to date information on the "has_issues" and "internal_tracker" (and possibly more) fields. You can confirm this by modifying "has_issues" with PATCH, then sending a GET request and the responses will be different.

I believe point 3 is unintentional and should be fixed, but I would need confirmation on if points 1 and 2 are unintentional.

[Crocmagnon]

Thanks ! At least I have a workaround: I can set "has_issues": true 🙂 in the request.

From an API user POV, I'd say point 3 is a bug, point 1 is an unexpected behavior since it's not documented and point 2 can be understood since it's a nested object but should be documented.

[6543]

to 1 & 2 yes intentional and is also described in swagger

to 3 it's a bug