[Feature Request] gitea widget configurable number of issues in search

[mdougher]

Description

i have looked at existing discussions and don't see anything for gitea aside from the initial feature request.

i'm using the gitea widget to display data from a local gitea instance.
i configured it following the documentation at https://gethomepage.dev/latest/widgets/services/gitea/
Not much to get wrong here, its just:
widget:
type: gitea
url: http://gitea.host.or.ip:port
key: giteaapitoken

It supports these fields: ["notifications", "issues", "pulls"]

the "issues" field appears incorrect on my end.
My gitea instance has 46 open issues, so that is the number i expect it to return. However, the homepage widget is displaying 20.
I believe it is because the data returned from gitea is paginated, and returns only the first 20 issues.

I think handling the pagination and performing multiple requests might be rather complex.
the query it sends to gitea also contains a "limit" field to specify how many results per page.
if this were configurable in the widget, i could just bump it up to a number high enough to get my number of issues.

here is the documentation / swagger front end for the API that the widget is using:
https://gitea.com/api/swagger#/issue/issueSearchIssues

if i use my local gitea instance swagger - i get the same 20 results. if i set limit = 100, i get all 46 returned.

while it might be impossible to determine a one-size-fits-all value for this limit field, it is optional. having it configurable could at least give people the ability to opt-into it?

Other

No response

[mdougher]

is there maybe some configuration change on the gitea side that could be done as an alternative?

[shamoon]

We could make a setting for this but it almost seems unnecessary and raising the limit to something like 100 would be fine. For some apis 100 items could be too heavy, I’d guess issue objects are pretty small but would be good to double-check before changing this. Either way an easy change to make but we do require feature-requests to be up-voted by users before implementing.

[mdougher]

Hi, shamoon.

Are you proposing simply hard-coding "?limit=100" to the API call to gitea? i feel like that would certainly cover my use case, not sure if thats just pushing the problem further down the road until someone needs > 100 lol. i don't think i'd be upset if this was the path chosen going forward!

shame that gitea doesn't seem to have an endpoint to just get the raw count, but has to get all of the data for all of the issues...

I’d guess issue objects are pretty small but would be good to double-check before changing this.

i honestly think that it COULD be a lot of data, unfortunately - it depends on what is in each issue object.
My specific case it isn't so bad because i don't have a ton of text. However, looking at the default example when you "try it out" on their swagger page, it is MUCH more data, mostly from the 'body' of the issue - some of their example issues have what looks like a few KB of text in a single issue body.

i'm sure there would be some number of issues where it would just be "too much data" and there would be some kind of performance issue as a result...
suggesting adding the 'limit' field to the widget feels like a bit of a compromise - it would allow each user to define what they feel is acceptable for their use case - and getting the current behavior if they leave the field blank as a default.

heck, you could argue that the other fields of the API are intended to help reduce the number of items returned - priority_repo_id, owner, team, assigned to you, created by you, and so on. But adding all of that is much more work, so i think that might be an unreasonable request ; )

in any event, this is not an urgent request, so i'll not object to however you choose to implement (or not).
thanks for taking the time to respond!

[shamoon]

Ok that’s helpful thanks. If there’s interest in this I’ll implement it as a configurable option