Gitea: Notification API bugs.

[opyale]

• Gitea version (or commit ref): 1.13.0+dev-218-gec40e593c
• Git version: N/A
• Operating system: N/A
• Database (use [x]):
  
  
  
  • [ ] PostgreSQL
  
  
  • [ ] MySQL
  
  
  • [ ] MSSQL
  
  
  • [ ] SQLite
  
  
  • [x] N/A
  
  
• Can you reproduce the bug at https://try.gitea.io:
  
  
  
  • [ ] Yes (provide example URL)
  
  
  • [ ] No
  
  
  • [ ] Not relevant
  
  
  • [x] Tried at gitea.com
  
  
• Log gist:

Description

There are two major bugs when trying to load a selection of notifcations using the API. These bugs were already confirmed by @6543.

1. Bug

From what I've seen, any request with all=true leads to an internal server error (Response code: 500).

2. Bug

Any pinned notifications are not included in the results.

Screenshots

[zeripath]

Hi!

I can't seem to reproduce this.

curl -u user:password 'localhost/gitea/api/v1/notifications?all=true' seems to work for me and it gives the pinned results too.

[opyale]

Hi, this is weird. With which version of Gitea did you test your request and did you try the same on gitea.com?

[zeripath]

I tested this on master right now

[opyale]

curl -X GET "https://gitea.com/api/v1/notifications?all=false&since=2003-02-22T00%3A00%3A00%2B00%3A00&page=1&limit=50" -H  "accept: application/json" -H  "Authorization: token censored"

The upper call works for me, but this one does not:

curl -X GET "https://gitea.com/api/v1/notifications?all=true&since=2003-02-22T00%3A00%3A00%2B00%3A00&page=1&limit=50" -H  "accept: application/json" -H  "Authorization: token censored"

[opyale]

I've also tested this directly using the built in swagger documentation of gitea.com. Same results:

[zeripath]

master is v1.13.0-dev-276-g217647f33 - I guess this might already be fixed.

[opyale]

Okay. Then I apologize for the inconvenience. I will now run the same query on the latest version of Gitea and will inform you if there are still issues.

[opyale]

Okay, i can confirm that the notifications API in 1.13.0+dev-275-g0d03fbf2c works so far. But I wonder why pinned notifications can only be seen when all is true. Is this behavior expected, and if so, why is it not mentioned in the documentation?

[zeripath]

Oh I see what you mean - I think this API is slightly poorly written.

Ok we need these to return pinned and unread by default.

[opyale]

That would be great! Thanks a lot for your help!

[6543]

I think this API is slightly poorly written.

@zeripath It just imitates github ones - and yes I missed pined one somehow :/

[zeripath]

@6543 sorry poor choice of words.

The issue with pinned is that it doesn't quite match with GitHub's saved notifications - so there is always going to be a slight inconsistency. I guess given we have a pinned status rather than saved it's probably best to just show the pinned ones by default.

TBH I've only really understood the pinned notifications since messing around with the event source - I would have forgotten about the pinned ones too!

[zeripath]

The issue is that the plain GH API doesn't quite match what we have, (and doesn't match theirs either tbh) so in that sense it's a poor API that's too simplistic. However it appears simple to extend so as long as we can do that sensibly that's fine.