Forem: Bug: Can't delete RSS-based posts that I don't want to ever publish

[SeanKilleen]

Big fan here by the way.

_BUG_

Steps to replicate

• Set up the RSS import on dev.to so that I can link it to my blog
• See articles come in, publish some, etc.
• Delete an article that I don't ever want to publish on dev.to

Current Behavior

• The article comes back into my dashboard as unpublished, so I have several articles that will forever sit in my dashboard.

Expected Behavior

• When I delete the article, I shouldn't see it in my dashboard again.

Screenshots

[shindakun]

It looks like they would come back when the RSS refreshes and annoyingly it seems to be at the top of the article list. That's an interesting issue... The backend would need to keep a list of articles from RSS that you've removed to remove them again each time it refreshes. But what happens if you deleted an article by accident?

[SeanKilleen]

Those were my thoughts exactly. I agree, it would be a list of IDs or some other identifiers for that RSS article. If you don't track IDs for the imports, then maybe a list of canonical URLs to exclude perhaps? My thinking from user experience perspective is that if I delete an article by accident from my RSS list, it would still be easily achievable to republish that article on the site, because I still have the original content from wherever the source of the RSS file is.

[jessleenyc]

Thanks @SeanKilleen for bringing this up and @shindakun for jumping in. We've added this issue to our backlog.

[stale[bot]]

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue in 7 days. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If this issue still requires attention, please respond with a comment. Happy Coding!

[SeanKilleen]

Commenting on this to keep it open because I think it still makes sense as a backlog item and I haven't seen it addressed elsewhere. /cc @jessleenyc as FYI because she'd commented previously.

[stale[bot]]

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue in 7 days. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If this issue still requires attention, please respond with a comment. Happy Coding!

[maestromac]

not stale

[daneah]

This has cropped up for me a few times as well, and I wonder if adding some additional "hidden" status for an article would be a way forward.

1. Add RSS feed
2. See existing posts pop up as drafts
3. Click "Remove from this list" or something with better words
4. It goes in a list that can still be accessed and has options like "Move to drafts"

Another, simpler option that could address a majority of the issue as I'm experiencing it would be to move the drafts to a separate list below the published posts. That way it always extends downward out of view and doesn't get in the way, but is accessible should someone want to look at it.

[stale[bot]]

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue in 7 days. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If this issue still requires attention, please respond with a comment. Happy Coding!

[daneah]

Still seems like an interesting thing to discuss!

[SeanKilleen]

Agreed it's still worth doing. I may jump in for a PR on this.

I'd suggest the following as a minimal first pass:

• Add a boolean column in the db to capture whether a post is hidden, default to false
• Allow people to enter "hidden: true" in YAML. On save, if the field is present, set the boolean in the DB.
• If you want, add a "hidden: false" by default on import from RSS to make authors aware
• Add logic to only display non hidden drafts
• Add a querystring or similar to show hidden drafts
• Add a button that redirects to that query string
• Add a post explaining how it works

Do folks agree with this? If so we could probably get some PRs started.

[devjack]

I love the idea and have colleagues who would love to use it too.

From a taxonomy/terminology perspective, perhaps the ability to 'ignore' draft posts (rather than overloading 'hidden' and 'deleted' fields, and 'muting' notifications? For example, it could look like this:

The ability to hide or archive posts that are created manually (i.e. not a feed) is certainly useful, but the intent here is to specifically ignore external content being fed in.

Potential problems:

• Identifying RSS content - there's no definitive "id" in RSS but there is a required URL field, and an optional guid field. I'd suggest using the guid where available, and the url by default. It's unlikely a url will change, and if it does, its in frequent enough to not be wildly inconvenient to re-ignore in the dashboard.
• UI clutter around 'filtering' ignored content. I'm no UX expert and I'm conscious of cramming in more buttons and text in what is currently a nice simple UI.

[jessleenyc]

We could have an 'ignore' option _and_ an 'archived' option but I also think just 'archived' will likely accomplish what we're looking for, even if the intent is slightly different.

Instead of handling this in the front matter, let's do it from the dashboard. The buttons are starting to clutter and we want to move them (mute notifications + this new button) as dropdown options. We can add an ellipses similar to where additional options appear on individual comments.

[SeanKilleen]

Makes sense. 👍

To recap: from a UX perspective, it sounds like what we want to do is:

• Allow the users to mark a draft post as archived via an ellipsis menu
• Avoid resurfacing a draft post from RSS on the UI if it's already been archived
• Determine how to display archived posts for the user (the small text & link from @devjack above seems to cover this well if there are no objections).

Technical Analysis:

• Is there an RSS ID or URL associated with posts that come in through the RSS feeds? (it seems like there is currently)
• Seems like we'll need to add the "archived" bool (which there didn't seem to be any objection on)

Acceptance Criteria (as I understand it)

• Can Archive an item in draft posts
• Archive link appears when there are archived items
• Archive link does not appear when no archived items exist
• Can view archived items by clicking on the link
• Items from feeds don't re-appear in drafts once archived

[SeanKilleen]

(oops, accidentally closed). No triage necessary hopefully (though I would like confirmation on the A/C)

[jessleenyc]

If we're able to get filtering in soon, we can probably have 'archived posts' as one of those options but I think what @devjack suggested for now makes sense -- https://github.com/thepracticaldev/dev.to/issues/2351 (cc @omenking )

If you're going to tackle this, please post a mockup of the ellipses/dropdown design just to make sure we're on the same page. We can also take care of any last mile design stuff.

[maestromac]

@SeanKilleen guid seems to be the only reasonable one we can use to uniquely associate posts.

[danascheider]

@SeanKilleen I'm happy to start a PR on this if you think the specs/acceptance criteria you outlined above are well enough finalised.

[SeanKilleen]

I welcome a PR since I'm a hit swamped at the moment but the acceptance criteria etc. belongs to the dev.to folks :) I just made the original observation.

[danascheider]

Cool, well in that case I'll wait for some confirmation from them so I don't end up going too far down the wrong path. The fact that that little Author label means the author of the PR and not of the project always messes me up on here.

[danascheider]

@maestromac What do you think?

[maestromac]

Yep, give it a go @danascheider !

[danascheider]

Sounds good, I'm on it :)

[danascheider]

@devjack @maestromac The RSS specification indicates that all fields under <item> are optional, including URL. In fact, every field under <item> is optional, with the exception that the item has to have either a title or a description. I'm trying to think of a workaround for how we can uniquely identify RSS content but any suggestions are welcome.

[SeanKilleen]

@danascheider for the purpose of this PR, would it make sense to address it using whatever method is currently in use? If URL is being used, I'd recommend using that for now and creating a follow up PR later.

I'm assuming they already have a way of doing this (via URL or another method) because posts don't repeat in my dashboard when they come in via my RSS)

[danascheider]

@SeanKilleen Ah true! Yeah, I'll figure out how they are already being differentiated.

[devjack]

New archive UI (and functionality) looks great @danascheider! I feel it solves our 'delete rss posts' bug scenario well, so suspect this can be closed now?

[SeanKilleen]

@devjack totally agree. Thanks to @danascheider for making this happen!

[kievsash]

Still observing that issue - imported mediums articles through rss, they are saved as draft on dev.to.
I delete them and they re-appear on my dashboard

[maestromac]

Hello @kievsash . The workaround we currently have in place is if you archive the said post, it won't be re-imported back.

[kievsash]

Thanks! Now I cannot archive)
"Failed to update article."
POST https://dev.to/articles/128728 404 - in Dev console

[maestromac]

Hey @kievsash thank you for reporting that! That is indeed a bug and I've created a bug report for it
https://github.com/thepracticaldev/dev.to/issues/3334