Я не скажу за весь ЛОР, но имхо, это может быть как фичей, так и багом.
Ситуация, когда при редактировании добавили или исправили каст — это один случай. Тогда текущее поведение — баг.
Ситуация, когда комментарий редактировали три раза, а каст не трогали — другой. Скастованному при этом придёт три уведомления, это хорошо или плохо? Вот тут может быть как баг, так и фича. Я бы предпочёл получить три каста, но кого-то это может и раздражать…
Я бы завёл отдельную таблицу с кастами, со связью один ко многим, где на каждый пост был бы список кастов. Когда юзер создаёт или редактирует пост, проверяются все касты, связанные с этим постом - и если какого-то каста ещё небыло, то он добавляется в таблицу и пользователю отсылается уведомление, а если уже такой был - то ничего не происходит.
Как не идёт, если идёт? Пользователь при редактировании может добавить новый каст или уже существующий каст, или удалить каст, или добавить вновь каст, который был удалён ранее. Всё это легко разруливается при помощи связанной таблицы кастов.
@metalbeaver ты можешь оригинальные исходники глянуть и сделать патч, либо, я думаю, соиска тебя к исходникам пустит, если ты захочешь в этом копаться.
Я сейчас глянул исходники. А подскажите, разве это не буквально то самое, о чём я говорил?
/* кастовать только тех, кто добавился. Существующие ранее не кастуются */
Включите, блядь, лоркод.
/**
Редактирование комментария.
@param oldComment данные старого комментария
@param newComment данные нового комментария
@param commentBody текст нового комментария
@param remoteAddress IP-адрес, с которого был добавлен комментарий
@param xForwardedFor IP-адрес через шлюз, с которого был добавлен комментарий
*/
@Transactional(rollbackFor = Exception.class, propagation = Propagation.REQUIRED)
public void edit(Comment oldComment, Comment newComment, String commentBody, String remoteAddress,
String xForwardedFor, User editor, MessageText originalMessageText) {
commentDao.changeTitle(oldComment, newComment.getTitle());
msgbaseDao.updateMessage(oldComment.getId(), commentBody);
/* кастование пользователей */
Set<User> newUserRefs = textService.mentions(MessageText.apply(commentBody, originalMessageText.markup()));
MessageText messageText = msgbaseDao.getMessageText(oldComment.getId());
Set<User> oldUserRefs = textService.mentions(messageText);
Set<User> userRefs = new HashSet<>();
/* кастовать только тех, кто добавился. Существующие ранее не кастуются */
for (User user :newUserRefs) {
if (!oldUserRefs.contains(user)) {
userRefs.add(user);
}
}
if (permissionService.isUserCastAllowed(editor)) {
userEventService.addUserRefEvent(userRefs, oldComment.getTopicId(), oldComment.getId());
}
/* Обновление времени последнего изменения топика для того, чтобы данные в кеше автоматически обновились */
topicDao.updateLastmod(oldComment.getTopicId(), false);
addEditHistoryItem(editor, oldComment, originalMessageText.text(), newComment, commentBody);
updateLatestEditorInfo(editor, oldComment, newComment);
String logMessage = makeLogString("Изменён комментарий " + oldComment.getId(), remoteAddress, xForwardedFor);
logger.info(logMessage);
@Aleksandra
@Aleksandra
Этот форум наш с тобою
https://linuxtalks.co/club/tox/85990?cid=86157
Вот тут не сработало, что странно.
Вообще по-моему, если не ошибаюсь, каст не срабатывает, если его вставляешь при редактировании. И это ещё с лора “фича”.
Спасибо, поняла.
На ЛОРе считают что это фича, а не баг?
Я не скажу за весь ЛОР, но имхо, это может быть как фичей, так и багом.
Ситуация, когда при редактировании добавили или исправили каст — это один случай. Тогда текущее поведение — баг.
Ситуация, когда комментарий редактировали три раза, а каст не трогали — другой. Скастованному при этом придёт три уведомления, это хорошо или плохо? Вот тут может быть как баг, так и фича. Я бы предпочёл получить три каста, но кого-то это может и раздражать…
Что мешает проверять наличие каста пользака к сообщению? Что мешает удалять имеющийся каст при редактировании?
Я не жавист. Я там ноги переломаю себе. Но вообще реализация не ожидается сильно сложной.
Я бы завёл отдельную таблицу с кастами, со связью один ко многим, где на каждый пост был бы список кастов. Когда юзер создаёт или редактирует пост, проверяются все касты, связанные с этим постом - и если какого-то каста ещё небыло, то он добавляется в таблицу и пользователю отсылается уведомление, а если уже такой был - то ничего не происходит.
Таким образом, при создании/редактировании поста проще делать запрос на удаление вида:
DELETE FROM tbl WHERE post_id=N;Так, если это новый пост, то запрос ничего не удалит, а если пост редактируется, то все касты поста будут удалены.
Вторым шагом делаем запрос вида:
Нихуя не понял. Нам нужно не посылать касты повторно.
Даже если каст отправлен, но позднее было редактирование – это не страшно, пост ведь существует. О повторном касте речи не идет.
Как не идёт, если идёт? Пользователь при редактировании может добавить новый каст или уже существующий каст, или удалить каст, или добавить вновь каст, который был удалён ранее. Всё это легко разруливается при помощи связанной таблицы кастов.
@cocucka а где исходники вашего говна лежат? Что-то я в глаза долблюсь.
Оно спрятано от макскома, а то он фичи ворует
Опенсорс, который мы заслужили.
Ага, сначала они банят/замораживают за любое упоминание о ЛТ, а потом у нас фичи берут.
@metalbeaver ты можешь оригинальные исходники глянуть и сделать патч, либо, я думаю, соиска тебя к исходникам пустит, если ты захочешь в этом копаться.
Я сейчас глянул исходники. А подскажите, разве это не буквально то самое, о чём я говорил?
/* кастовать только тех, кто добавился. Существующие ранее не кастуются */
Включите, блядь, лоркод.
/**
}
«Включите, блядь, лоркод.» Он же в настройках профиля включается, или ты про что? https://i.ibb.co/3BrMm6B/lorcode.png
оно видимо не работает, на лоре тоже писали https://www.linux.org.ru/forum/linux-org-ru/16304968?cid=16305728
Я опечатался в нике, потом исправил, но каст в таком случае не работает