As of now titles of newsletters are logged, but descriptions are not. Logging both could allow easier monitoring and reverting of abusive changes.
14:07 <addshore> well, either tim the description and put it in the params
14:07 <addshore> or a trimmed current description could be magically added to the log line by a formatter
14:08 <tonythomas> addshore: okey.! any preference ?
14:08 → DanielK_WMDE joined (daniel@wikipedia/duesentrieb)
14:08 <addshore> I dont know what is best / what has been done before
14:09 <addshore> going to formatter approach would require a db call to format the log line
14:09 <tonythomas> addshore: yeah. slowy
14:09 <addshore> so just trimming and putting it in params may be better
14:09 <addshore> also are descriptions required?
14:09 <addshore> if not you should make sure you account for if there is none
So Trim ? I am wondering, by what length ?
My initial thinking was that the description field was supposed to not be a short field. But it seems that it has now also been changed to a 'text' field (from 'textarea'). Maybe the short one is better considering that we don't even parse it. If we want to make it a short field, the DB constraint/type should also be changed. I had changed it to a blob sometime ago.
If you are talking about the description field that shows up while creating a new newsletter -- its still a textarea, and we are storing it as a blob. Looks like we are not storing the summary of the newsletter issue anywhere.
Maybe the short one is better considering that we don't even parse it. If we want to make it a short field, the DB constraint/type should also be changed. I had changed it to a blob sometime ago.
This one is for the Main newsletter description ? We will need it as blob ?ref: https://github.com/wikimedia/mediawiki-extensions-Newsletter/blob/master/includes/specials/SpecialNewsletterCreate.php#L54
I meant the description on Special:Newsletter. Since my assumption at the time when I implemented it was that it would be a long field, it was a readonly textarea (since no parsing at that time). It has since been changed to a normal text HTMLForm field.
Looks like we are not storing the summary of the newsletter issue anywhere.
This is a separate issue (not related to this task) but we should add it to the announce log entry. When I added the new announce page form, logging hasn't been implemented so we couldn't show it anywhere except in the notification back then. But now it should be pretty easy to fix it.
The patch linked is adding a truncated description to the log message as a log parameter. That has several issues:
- full text of descripton cannot be properly attributed to users
- no easy way to find the diff of the changes
- vandalism/abuse also cannot be easily detected (by whom and when)
I think we can implement something similar to AbuseFilter's (and even Phabricator tasks!) history system. It should add a log entry linking to a page showing the diff of the full description. This would allow us to show the complete description (with diff) and would make the currently unresolved issues for T132016 significantly easier.
17:33 <Glaisher> We'll probably have to introduce a history table
17:33 <Glaisher> It would have fields like user, timestamp, content(?) etc.
17:34 <Glaisher> the content field would have the description stored in a json serialized blob
17:34 <Glaisher> so that we can store other stuff in the future if we need to
17:35 <Glaisher> tonythomas: We can use the diff engines in core