@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" ?
|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|
- Mentioned In
- rENLT7c335b8371c1: Implement Special:Newsletter
rMEXTc5b09c0dce2c: Updated mediawiki/extensions Project: mediawiki/extensions/Newsletter…
- Mentioned Here
- T107555: Consistency of names across Newsletter extension special pages
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
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.
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.
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.