@Bawolff posted an important question in his review( https://www.mediawiki.org/wiki/User:Bawolff/review/Newsletter#General ), "How does someone delete a newsletter. How does one clean up after a vandal making a bunch of bogus newsletters" ?
Description
Description
Details
Details
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Duplicate | Qgil | T125545 Phabricator Q&A session for Community Liaisons | |||
| Resolved | Qgil | T116025 Goal: Align Community Liaison and Developer Relations project management practices | |||
| Resolved | Qgil | T119387 Community Liaison and Developer Relation quarterly goals for January - March 2016 | |||
| Declined | None | T104131 Exporting existing newsletter to the Newsletter extension | |||
| Resolved | Addshore | T110170 Goal: Deploy Newsletter extension in Wikimedia | |||
| Resolved | Qgil | T110366 Newsletter extension: Technical review | |||
| Resolved | Qgil | T110642 Implement all the features required for running the Newsletter extension in Wikimedia | |||
| Resolved | Glaisher | T110490 Deleting a newsletter and subsequent clean up |
Event Timeline
Comment Actions
I suppose we can have another section in Special:NewsletterManage to carry out the deleting of newsletters ? @01tonythomas, @Qgil, @Glaisher, @Addshore you all agree ?
Comment Actions
Special:NewsletterManage seems to have a lot already -http://newsletter-test.wmflabs.org/wiki/Special:ManageNewsletter. we can even have it as a separate section though ( as we have one for Create ). I'm not the design expert here, so lets wait
Comment Actions
Let's kill the TablePager on the newsletter managing page (It won't be nice on huge wikis like English Wikipedia and Meta-Wiki where there would be lots of newsletters) and have newsletter-manage interfaces for specific newsletters. This page should be doing just one thing only - managing a specific newsletter. Otherwise, there would be too much distraction, imo. See https://meta.wikimedia.org/wiki/Special:CentralNotice for such an example. (It used to be a lot worse when unused campaigns were not archived regularly) The user would've to scroll all the way to the bottom just to create a new campaign there. And this would be even worse from a design point of view in Newsletter extension where dropdown lists are used.
However, we should still let the users mass manage many newsletters from one page but ideally that should be done from another page.
Also, we should investigate more ways to improve user workflow and make this extension more user friendlier.
Comment Actions
Agreed. But where will we give an overview of all the newsletters to users, you know so that can see choose which ones to subscribe ?
Comment Actions
Through Special:Newsletters. We should be merging Special:ManageNewsletter into another page (Special:Newsletter) for T107555. I've also suggested this at T110191#1583704
Comment Actions
Change 236571 had a related patch set uploaded (by Glaisher):
Implement Special:Newsletter
Comment Actions
Yep, Special:Newsletter can be used to delete newsletters now. It needs to be made more reliable though but this can be closed now.
Comment Actions
Routinely having to destroy potentially large amounts of data while holding locks on four tables is not going to fly. I suggest doing this another way, by simply having a flag field which indicates whether a newsletter is active or not.
Comment Actions
Change 281075 had a related patch set uploaded (by Ori.livneh):
Use a flag to mark newsletters as deleted
Comment Actions
In a quick chat with @Tinaj1234 @01tonythomas and @Quiddity we agreed that the good solution would be to adopt the same behavior as wiki pages: they can be "deleted", and by doing so they are removed from the users' UI and access, but administrators can still "undelete" them, restoring their content.
Comment Actions
something broke in between, and it seems like we are actually deleting from the db again :(