Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add toot source to delete result to ease Delete & Redraft #10669

Merged
merged 3 commits into from
May 11, 2019

Conversation

ClearlyClaire
Copy link
Contributor

Currently, a client has to parse the formatted status when doing Delete & Redraft.
This is not trivial, and even the WebUI does not do it correctly for mention to users with weird URIs.

This PR returns the status in the delete reply with an additional raw_content field containing exactly the text that was initially input.

@ClearlyClaire ClearlyClaire changed the title Add toot source to delete result to ease Delte & Redraft Add toot source to delete result to ease Delete & Redraft May 3, 2019
@ClearlyClaire ClearlyClaire requested a review from Gargron May 7, 2019 21:21
@Gargron
Copy link
Member

Gargron commented May 10, 2019

I am a little concerned/unsure about the naming and the semantics of adding stuff to entities--I am not a fan of the source property in the Account entity either. One option is to simply return the content unformatted from that particular response, without adding it into a new property. Since the previous response is empty, it would not mess with current applications...

Another option, instead of creating a raw_content property, is to return a text property instead of the content property, since the real column name is text after all.

@ClearlyClaire
Copy link
Contributor Author

I'm weary of directly returning the content because it may be an issue for us down the road if we want to add stuff later on. I think having the complete status could be useful for clients as well, depending on how they handle various things… but it probably isn't necessary.

If you prefer text instead of raw_content, that's an easy change I can do right now. I can also remove the content property in that particular case, but I'm not too sure why that would be necessary.

@ClearlyClaire
Copy link
Contributor Author

I am a little concerned/unsure about the naming and the semantics of adding stuff to entities--I am not a fan of the source property in the Account entity either. One option is to simply return the content unformatted from that particular response, without adding it into a new property. Since the previous response is empty, it would not mess with current applications...

Oh, I think I misunderstood what you meant. Returning the full status but with the contents as plaintext rather than formatted? I think this would be more confusing and error-prone, the nature of the field changing depending on the context does not sit right with me.

@Gargron Gargron merged commit 6d44f24 into mastodon:master May 11, 2019
hiyuki2578 pushed a commit to ProjectMyosotis/mastodon that referenced this pull request Oct 2, 2019
…0669)

* Return Status with raw text in raw_content when deleting a status

* Use raw content if available on delete & redraft

* Rename raw_content to text; do not serialize formatted content when source is requested
hiyuki2578 pushed a commit to ProjectMyosotis/mastodon that referenced this pull request Oct 2, 2019
…0669)

* Return Status with raw text in raw_content when deleting a status

* Use raw content if available on delete & redraft

* Rename raw_content to text; do not serialize formatted content when source is requested
messenjahofchrist pushed a commit to Origin-Creative/mastodon that referenced this pull request Jul 30, 2021
…0669)

* Return Status with raw text in raw_content when deleting a status

* Use raw content if available on delete & redraft

* Rename raw_content to text; do not serialize formatted content when source is requested
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants