 |
Автоматически ставить отметку о нахождении при правильном ответе не нужно, так как это не всегда коррелирует. Например, нужно фото, или это зимний вопрос а отправлен летом и т.п. |
 |
Можете обсудить это составом СГ и сформировать четкие требования? Ибо много подводных камней и неочевидностей |
|
|
С форума: 1. Автор создаёт вирт, в базу это прописывается, база это знает. В вирте же убирается возможность ставить его внайденные "не дожилаясь подтверждухи" 2. На вирте объединить "ответ на вирт и оставить комментарий" - два поля по одной кнопке. И получается, Игрок берёт вирт и пишет в тайнике комментарий, одновременно отсылая ответ на вирт вопрос. 3. ответ уходит в базу 4. отзыв со статусом комментарий уходит в блокнот виртуального тайника/ (статусы проверка автора, посещенотайникнеискал, тайник не найден остаются, но при выборе их, поле с отсылкой виртответа просто неактивно) 6. в базе ответ проверяется, и после того, как автор или модератор отправляет "правильно" или же приходит автозачёт, статус автоматически меняется на открытый сундук, и тайник автоматически с числом оставленного комментария заисывается в базу найденных игроком тайников. Собственно, более детально развитая идея "предварительного статуса" |
|
|
"Число оставленного комментария" не подходит, так как часто не совпадает с датой нахождения тайника плюс порядок может измениться (а очень многие отмечают строго по порядку) Непонятно, что с оценками и рекомендациями (можно оценивать и рекомендовать только найденные тайники) Я бы предложил следующую схему. При записи в блокноте и установке галки "тайник найден" запись в блокнот записывается как обычно, тут можно ничего не менять, статус записи блокнота ни на что особо не влияет (если полировать, то добавиить отдельный статус "отправлен ответ"). Если в таблице ответов по уникальности тайник-игрок нет записи со статусом "правильно", то запись о "нахождении" пишется не в основную, а в дублирующую таблицу. При проверке автором-модератором и установке статуса "правильно" проверяется, нет ли в дублирующей таблице подходящей записи. Если такая есть, то она копируется в основную, а из дублирующей удаляется. Тот же механизм (вызов этого же кода) при добавлении из ЛК. Почему дублирующая таблица, а не поле с предварительным статусом - чтобы не искать по всему коду, где может быть работа с этой таблицей. В эту же таблицу писать оценку и рекомендацию отдельными полями, затем прописывать в основные. Кстати, не помню как сейчас реализовано, но если таблицы разные, логичнее их объединить, но это можно в рамках другой доработки, не сразу |
- Анонимный Пользователь
