Gitea: У администраторов сайта должен быть интерфейс для удаления проблем в панели администратора.

~ Как мы уже говорили о gitter, я не думаю, что для этого есть требование, и почти все программное обеспечение хоста git не позволяет удалять проблему. ~

ИМХО это не баг, это фича. Это гарантирует, что никто не манипулирует видимостью проблемы.

Я не вижу проблемы, если проблема в том, что ее может удалить кто угодно, почему бы просто не обратиться к «владельцу» или тому, кто действительно создал проблему с самого начала?

Я имею в виду, допустим, я сделал это, а затем я думаю об этом и знаю, что в этом была какая-то необходимость, или мой запрос был глупым, или по какой-либо другой причине, которая заставила бы меня удалить его, чтобы просто не произошло ничего.

В моих глазах это не имеет никакого смысла

Вопросы, которые затем оказываются "глупыми" и закрываются, очень полезны! Скажем, у кого-то есть такое же сомнение или проблема, закрытая проблема - это «документация» по чему-то, что, как оказалось, не было проблемой, и если создатель проблемы добавит ее, она также будет содержать инструкции о том, как ее решить.

Единственный случай, когда я вижу, что проблемы с удалением имеют смысл, - это нелегальный контент. В этом случае просто удалите комментарий или отредактируйте проблему, чтобы не было незаконных материалов.

Я понимаю, о чем вы говорите, но я все еще не согласен в моем случае, я единственный, кто запускает мой репозиторий, поэтому я пропускаю эту функцию, удаляйте вещи, которых там не должно быть

Если вы создаете проблему с моей ошибкой, вы можете просто изменить заголовок и тело на Invalid и закрыть

Мне все еще это не нравится, но я вижу, что никто другой не согласен со мной.

В моих глазах это нечисто

Нечисто да, но непротиворечиво 🙂

Например, когда вы тестируете ISSUE_TEMPLATE или пытаетесь понять ход проекта, было бы очень полезно удалить свои собственные проблемы ...

По крайней мере, когда вы являетесь владельцем репозитория.

Эта функция должна быть доступна, потому что владелец репозитория должен решать, какой рабочий процесс подходит для его / ее проекта.

Также владелец мог просто удалить его из базы данных :)

Спамеры оставляют проблемы с рекламой, и я, как администратор, не могу их удалить 🤦‍♂️ Приходилось каждый раз чистить БД ...

Администраторы сайта должны иметь разрешение на удаление проблем в панели администратора для упрощения обслуживания сайта.

Эта проблема была автоматически помечена как устаревшая, поскольку в последнее время не было активности. Он будет закрыт, если в течение следующих 2 недель не будет никакой активности. Спасибо за ваш вклад.

Одна проблема, о которой еще не говорилось, заключается в том, что некоторый контент может потребовать удаления по юридическим причинам. Скажем, например, что пользователь X публикует действительно действительно незаконные материалы в проблеме. Конечно, их учетная запись удаляется мгновенно, но теперь администратор сайта имеет незаконный контент на своем сайте и не может его удалить.

Также обратите внимание, что не всегда администратор знает, как удалить проблему из базы данных; возможность сделать это из пользовательского интерфейса является обязательной, если администраторы не могут доверять своим пользователям на 100% (что бывает редко).

не всегда администратор знает, как удалить проблему из базы данных;

Я хочу удалить запрос на перенос. Достаточно ли хорош следующий SQL до того, как станет доступен графический интерфейс?

delete from pull_request where issue_id = 10;
delete from issue where id = 10;

Предполагая, что число в конце URL-адреса запроса на вытягивание равно 10
http: // локальный: 3200 / имя_организации / имя_репо / вытягивает / 10

Немного мнения, но вот список вещей, которые, по моему мнению, следует удалить, а не закрыть:

• Вопросы, содержащие незаконный, оскорбительный или иным образом нежелательный контент.
• Полностью несвязанный контент, не имеющий отношения к проекту.
• Реклама других (похожих) проектов
• Сильные выражения, которые автор отказывается смягчать

Вещи, которые можно было просто закрыть, но некоторые специалисты по сопровождению и / или администраторы все же могут захотеть удалить, чтобы сохранить более чистый бэклог:

• Повторяющиеся проблемы, не добавляющие новой информации
• Безосновательная критика или предложения по улучшению а-ля ur s0ftware suxx

Я надеюсь, что это подчеркивает тот момент, что как для администраторов, так и для сопровождающих репозитория часто имеет смысл полностью удалять проблемы в определенных ситуациях.

Устранена проблема с БД, как это исправить сейчас?

В качестве сервера репозитория git на собственном сервере я также считаю, что администратор сайта должен иметь возможность разрешать владельцам репозиториев делать «все, что им нравится».

Например, я являюсь владельцем своего сервера (и даже если бы у меня не было, но у меня были бы включенные опции для этого, это было бы то же самое), и я также как владелец моего репо хотел бы сам открывать проблемы чтобы показать другим людям работу, которую я делаю с течением времени, и что я добавляю полезные вещи, а не просто глупую чушь (только потому, что 90% людей, которых я знаю, никогда не смотрят историю коммитов и совершают контрдоказательство моего усердия и просто говорят: "черт возьми, вы делаете весь день? тупой бесполезный код? »).

Однако, когда я работаю над своими собственными проблемами (а также 90% из вас, вероятно, делали это хотя бы один раз), обычно не знаю, где разместить вещи даже под моей собственной схемой ярлыков, поэтому я обычно добавляю ярлык, затем удаляю его и присвоить этот вопрос под другим лейблом, и так далее , так далее , пока моя «история вопроса» выглядит что - то вроде этого ...

Было бы очень хорошо иметь возможность удалить эту дрянную нерешительность и начать новую проблему (или, по крайней мере, удалить "историю ярлыков" моей нерешительности в отношении того, кем быть) ...

Устранена проблема с БД, как это исправить сейчас?

Я действительно понял это после того, как у меня была такая же проблема. Перейдите к таблице repository вашей базы данных. Количество открытых проблем - это вычитание двух столбцов num_issues и num_closed_issues . Я изменил 47 num_issues на 46 и обновил счетчик.

@DJFraz
Уменьшение num_issues вызывает ошибку 500 при попытке создать новую задачу, мне пришлось вместо этого увеличить num_closed_issues .

Изменение num_closed_issues тоже не было хорошей идеей :) Gitea обновляет его в соответствии с таблицей проблем.
Таким образом, он либо удаляет проблемы, а затем проверяет, что num_issues + 1 не конфликтует с существующим индексом проблем, либо просто закрывает проблему и очищает ее содержимое.

: point_up: именно поэтому удаление проблем не реализовано. По соображениям производительности количество проблем кэшируется ( num_issues ) в БД, это число также используется для того, каким будет следующий номер проблемы ( num_issues + 1 ).

Можно продублировать это значение в БД и использовать last_issue_nr или next_issue_nr в качестве исправления. Или можно добавить hidden -boolean в таблицу задач. В последнем случае проблема скрыта только от пользовательского интерфейса (и API), но при необходимости на нее позже можно будет ссылаться (юридические причины были упомянуты ранее в потоке)

Только мои 2 цента

этот номер также используется для того, каким будет следующий номер проблемы ( num_issues + 1 ).

Не совсем. В настоящее время это SELECT MAX(index)+1 FROM issue WHERE repo_id = ? .

именно поэтому удаление проблем не реализовано

Нет, поэтому не стоит связываться с ними вручную :)
Меня не волнуют причины, я хочу полный контроль над своим сайтом, эта функция должна быть реализована.

это необходимо для общедоступных установок gitea, особенно если вы стали объектом рассылки спама.

для меня функция закрытия должна быть для закрытия проблемы, связанной с проектом, а не для закрытия несвязанного спама, который лучше удалить.

Мы должны сохранить последний index в таблице репозитория или что-то еще.

Мы должны сохранить последний index в таблице репозитория или что-то еще.

Это определенно звучит как решение проблемы индекса обновления, если xorm поддерживает SELECT FOR UPDATE на всех наших базах данных. Я думаю, да, не так ли?

Что касается создания последовательных значений, которые должны быть последовательными (то есть без дыр), в проекте, который я делал давно, у нас была отдельная таблица для их создания. например:

SQL> SELECT * from max_values;
table        | key          | last_value
-------------+--------------+-------------
repository   |          445 |          3
repository   |          446 |          1
repository   |          447 |        745
repository   |          448 |         92
repository   |          449 |         60
repository   |          450 |         46

Таким образом, чтобы вычислить следующий номер проблемы, мы сделали следующее:

PSQL> UPDATE max_values SET last_value = last_value + 1
      WHERE table = 'repository' and key = '448';
PSQL> SELECT last_value + 1 FROM max_values
      WHERE table = 'repository' and key = '448';

(read value)

Таким образом, мы создали только одну блокировку, чтобы добавить проблему (т. Е. Фактическая строка репозитория не была заблокирована для оставшейся части транзакции). Другие транзакции, пытающиеся добавить строки, будут заблокированы в ожидании разрешения первого UPDATE, поэтому нет шансов на дублирование. Если первая транзакция откатывается, вторая получит для нее правильное следующее значение.

Это также гарантирует, что никакие значения не будут использоваться повторно, даже если мы удалим последнюю проблему.

@ guillep2k звучит лучше.

Решение @lunny, предложенное @ guillep2k, кажется законным, как босс; но, как отметил @DJFraz 27 августа 2019 года, поскольку счетчики проблем рассчитываются во время выполнения, но затем сохраняются в базе данных для кеширования, как вы думаете, как следует реализовать их обработку?
Спасибо.

Решение @lunny, предложенное @ guillep2k, кажется законным, как босс; но, как отметил @DJFraz 27 августа 2019 года, поскольку счетчики проблем рассчитываются во время выполнения, но затем сохраняются в базе данных для кеширования, как вы думаете, как следует реализовать их обработку?

Это всего лишь вопрос перерасчета «кешированных» значений, как мы это делаем, когда открываем / закрываем любую проблему.

Проблема в этом комментарии заключается в том, что пользователь попытался удалить строку, не обновив соответствующие столбцы, чтобы отразить изменение.

Проблема в этом комментарии заключается в том, что пользователь попытался удалить строку, не обновив соответствующие столбцы, чтобы отразить изменение.

Так, ... Технически , это можно _manually_ УДАЛИТЬ вещи из базы данных и уйти с ним , не нарушая ничего?

Так, ... Технически , это можно _manually_ УДАЛИТЬ вещи из базы данных и уйти с ним , не нарушая ничего?

Проблема с повторным использованием номеров выпусков. Если вы удалите плохой комментарий #999 и он окажется последним, следующий хороший комментарий тоже получит номер #999 , что не является нет. Фактически новый комментарий должен быть #1000 а номер #999 следует оставить "неиспользованным". Но я работаю над PR, который исправит эту проблему и подготовит почву для удаления комментариев в будущем.

Людям, которые против того, чтобы задачи удалялись: хорошо, но затем разрешите удалять историю редактирования.

в качестве альтернативы: как насчет того, чтобы полностью скрыть нежелательные проблемы от просмотра и добавить возможность администраторам просматривать скрытые проблемы?

Это решит как проблему с невозможностью удалить юридически опасный контент с вашего собственного сайта, так и устранит загромождение списка проблем.

Это устранило бы обе проблемы, связанные с невозможностью удалить юридически опасный контент с вашего собственного сайта.

@DarkWiiPlayer, дело в том, что потенциально незаконный контент, такой как педо-порнографическое изображение, все еще доступен на вашем сервере и доступен после запрошенной проверки ваших услуг у полицейского ...

Скрытие проблем: отлично подходит для людей, которые не хотят иметь повторяющиеся проблемы и загроможденный материал с историей проблем, полной добавления и удаления ярлыков и людей и решений, меняющих разум.
Однако это не нормально для незаконного контента, хранящегося на дисках сервера ...

@DarkWiiPlayer, дело в том, что потенциально незаконный контент, такой как педо-порнографическое изображение, все еще доступен на вашем сервере и доступен после запрошенной проверки ваших услуг у полицейского ...

Неплохо подмечено. Думаю, я смотрел на это с точки зрения: «Если полиция никогда этого не увидит, все в порядке», но есть множество причин, по которым это все еще может навредить владельцу сайта, от кого-то случайно найденного кем-то преднамеренная загрузка такого контента с последующим сообщением в полицию.

Я по-прежнему считаю, что скрытые проблемы лучше, чем ничего, и в сочетании с редактированием проблемы и очисткой ее истории изменений это все равно будет работать.

Тем не менее, в идеале лучшим решением была бы возможность по-настоящему «удалить» проблему, даже если это означает просто очистить все данные и установить для них значение «удалено».

Неплохо подмечено.

Спасибо.

Думаю, я смотрел на это с точки зрения: «Если полиция никогда этого не увидит, с тобой все в порядке».

К сожалению, это не работает, когда у вас есть незаконные файлы на вашем носителе ... даже если они не являются общедоступными через URL-адрес, если создается отчет и подана проверка, вы облажались, неважно сколько "но это загруженный пользователем контент" можно сказать ...

Чтобы добавить к списку причин для этого: в настоящее время я организую работу в частном репо с двумя другими соавторами, поэтому наше сообщение в настоящее время включает детали, которые мы не будем раскрывать публично. Однако есть вероятность, что репо будет обнародовано в будущем, когда мы решим открыто выпустить проект. На этом этапе было бы здорово иметь способ полностью стереть раздел проблем, прежде чем устанавливать видимость проекта для публики и, таким образом, открывать его.

Было бы здорово увидеть эту функцию в какой-то момент, в любом случае спасибо за всю работу над gitea и продолжайте в том же духе!