webhooks don't have an `application_id` or `user` field

(#362) Bug Awaiting confirmation api

Summary

Webhooks should have a field like application_id that has the id of the bot/application which made it.

Steps to reproduce

i don't think this has steps to reproduce other than making a webhook and expecting an application_id field?

Merged posts

These posts were merged into this one. Their comments are now part of the conversation below, marked with where they came from.

Merged from #610 Webhooks don't have `application_id` or `user` fields

RexSystemoriginally by @williamhorning on GitHub

Report details

Summary

Webhooks should have a field like application_id that has the id of the bot/application which made it.

Steps to reproduce

i don't think this has steps to reproduce other than making a webhook and expecting an application_id and/or user field?

Logs or screenshots

see #362, which got mass-closed

6 comments

Sign in with Fluxer to comment and vote.
Comment by Rex
RexSystem 1 vote
Status changed from Fixed to Awaiting confirmation
This was closed in a bulk cleanup before Fluxer V2 without being checked or fixed. It may work now, so it is waiting for someone to confirm whether the bug still happens.
Comment by @williamhorning
RexSystem 1 vote originally by @williamhorning on GitHub OP
webhook also don't have a user field set on them, which makes it impossible to tell if an application-made webhook sent a message or not, which really breaks things for bridges which intend to not send duplicate messages
Comment by @PilkeySEK
RexSystem 1 vote originally by @PilkeySEK on GitHub
This is probably also the reason that webhook "users" can't be clicked on (username or profile picture) to get more info
Comment by @TheFurryGamer2016
RexSystem 1 vote originally by @TheFurryGamer2016 on GitHub
This seems really important so I'm gonna comment here to bump it to the top.
Comment by @williamhorning
RexSystem 1 vote Merged from #610 originally by @williamhorning on GitHub OP
apparently the user field exists in some places, and not others, so this isn't a bug, oops.