View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002557||HTML & PERL||Feature Request - Interface||public||2016-09-02 05:48||2020-01-06 11:52|
|Target Version||Fixed in Version|
|Summary||0002557: Acreqs: PM for sub track from soft -> hard + changed to CRC edited behaviour when file is marked CRC does NOT match|
Similar to the PM notification when CRC is edited, a PM should be sent when a sub track is changed to hard. Sample messaging:
A subtitle track you added to [url=xxxxx]this file entry[/url] was changed to type hardsub by an AniDB client. Please check whether the file does in fact have any subtitles at all, soft or hard sub, and issue any needed edit change requests.
For CRC changed by acreq:
1) casing fix at the ** in the PM wording
The CRC value you added to this file entry was wrong and it was changed to the correct value generated by an **AniDB** client. Please check whether you have the proper file (not corrupted) and make adjustments to the CRC status if necessary (matches official CRC; does NOT match official CRC). Or in the case of only you having the corrupted version of the distributed file, please issue a deletion request for that file entry, AniDB is NOT meant to index metadata of files that only you have and which were not distributed publicly.
2) if the file is marked CRC does NOT match, the acreq should NOT change the status from mismatch -> unchecked; it should stay marked as mismatch. If the user consciously selected mismatch, we should assume this case is correct by default, instead of assuming it is wrong by default and acreqing it to unchecked.
|Tags||No tags attached.|
Isn't having a proper creq notify instead of a PM less, you know, invasive, especially for people who add lots of files?
If nothing else, I'd like that at least as an option.
CRA mismatches are currently PMs -- though that does happen a lot less often than the hardsub tracks.
One way to reduce the spam could be to only send 1 soft -> hard convert email per 24 hours, and it will gather all the file IDs of everything that was changed in he past half hour -- though this would require somehow keeping track of it internally before the message is sent.
|2016-09-02 05:48||CDB-Man||New Issue|
|2016-09-02 05:48||CDB-Man||Relationship added||related to 0001501|
|2016-09-02 14:15||Hinoe||Note Added: 0003826|
|2016-09-03 00:19||CDB-Man||Note Added: 0003828|
|2020-01-06 11:52||DerIdiot||Assigned To||=> DerIdiot|
|2020-01-06 11:52||DerIdiot||Status||new => resolved|
|2020-01-06 11:52||DerIdiot||Resolution||open => fixed|