Board Thread:General Discussion/@comment-9605025-20200607065113/@comment-9605025-20200608182749

I see. Thanks for pointing that out. I was just checking the talk page assuming they would respond with something. I guess that isn't the case. Now I know for future occurrences. Only CzechOut could tell us which he was most concerned about. However, I assumed it was the mobile comparability since that is what he spent the most time on and he brought it up in other rejections (of other people's scripts) I have come across since. It just seemed like a common thread throughout the rejections. Though I suppose it is a legitimate concern if a key feature depends on JS. - I was actually thinking of just creating a separate script and crediting you in the "using code by" section. Which is why I was concerned about getting it approved. The concern about getting approval was also in part caused by the previous rejection; which you have pointed out has since been accepted. I actually have most if it already written but I suppose I could see if I can adapt it to just integrate with yours. Which approach do you think would be better? - The basic idea I am going for is to extend the blocking (i.e. automarking as read) capability beyond just announcements. For instance, Fandyllic finds upvote notifications annoying and can hide them via CSS but that doesn't actually dismiss them. This would be particularly useful if some users are getting spammed by upvotes or @mentions; which I have seen some people complain about from time to time. The main enhancements over the current script, in my opinion, would be the following: For example, I could block all upvote notifications except those from the dev wiki that are also not from Fandyllic.
 * 1) Block any notification type.
 * 2) *Based on legacy wikis since the UCP code base isn't open yet.
 * 3) Construct compound blacklist/whitelist criteria based on wiki, user, notification type, and exceptions.

To address your concern about accidentally dismissing a notification, the script would block conservatively. In other words, if it isn't clear if a notification should be allowed through, it will allow it. For instance (though I haven't seen it happen), if the count of unique actors is higher than the list of latest actors, the notification is automatically allowed just in case one of the unlisted actors should be permitted. The script also has a built-in whitelist based on user groups. Currently, staff, wiki managers, helpers, and VSTF cannot be blocked regardless of a user's list criteria.

If you would like, I could go into more details. Since the criteria parsing portion is complete (I think), I could also post that somewhere if you want to take a look at it.