Gitea: 사이트 관리자는 관리자 패널에서 문제를 삭제하는 UI가 있어야 합니다.

~우리가 gitter에서 말했듯이, 나는 이것에 대한 요구 사항이 있다고 생각하지 않으며 거의 ​​모든 git 호스트 소프트웨어는 문제 삭제를 허용하지 않습니다.~

IMHO 버그가 아니라 기능입니다. 아무도 문제 가시성을 조작하지 못하도록 합니다.

나는 문제가 보이지 않습니다. 문제가 누구든지 삭제할 수 있다는 것이라면 "소유자" 또는 처음부터 실제로 문제를 만든 사람에게 확인하지 않는 이유는 무엇입니까?

내 말은, 내가 이것을 만들었다고 말해보자. 그리고 나는 그것에 대해 생각하고 그것이 필요하거나 내 요청이 어리석었다는 것을 알고 있다.

내 눈에는 전혀 말이 안 된다

그 이후의 문제는 "바보"로 판명되고 닫히면 매우 도움이 됩니다! 누군가가 같은 의심이나 문제를 가지고 있다고 가정해 보겠습니다. 닫힌 문제는 문제가 아닌 것으로 판명된 무언가에 대한 "문서"이며 문제 작성자가 추가하면 해결 방법에 대한 지침도 포함됩니다.

삭제 문제가 의미가 있는 유일한 경우는 불법 콘텐츠의 경우입니다. 그런 경우에는 댓글을 삭제하거나 문제를 수정하여 불법적인 내용이 없도록 하세요.

나는 당신의 요점이 무엇인지 알 수 있지만 내 경우에는 여전히 동의하지 않습니다. 나는 내 저장소를 실행하는 유일한 사람입니다.

내 실수로 문제를 만든 경우 제목과 본문을 Invalid 하고 닫을 수 있습니다.

나는 여전히 그것을 좋아하지 않지만, 나는 다른 누구도 나에게 동의하지 않는 것을 본다.

내 눈에는 그것이 불결하다

깨끗하지 않지만 일관성이 있습니다 🙂

예를 들어 ISSUE_TEMPLATE를 테스트하거나 프로젝트 흐름을 이해하려고 할 때 자신의 문제 를

적어도 당신이 저장소의 소유자일 때.

이 기능은 저장소 소유자가 자신의 프로젝트에 적합한 워크플로를 결정하기 때문에 사용할 수 있어야 합니다.

소유자는 db에서 삭제할 수도 있습니다. :)

스패머들이 광고에 문제를 남기고 있는데 제가 관리자로서 지울 수가 없어요 🤦‍♂️ 매번 DB를 정리해야 해서...

사이트 관리자는 사이트를 보다 쉽게 ​​유지 관리하기 위해 관리자 패널에서 문제를 삭제할 수 있는 권한이 있어야 합니다.

이 문제는 최근 활동이 없었기 때문에 자동으로 오래된 것으로 표시되었습니다. 앞으로 2주 동안 더 이상 활동이 없으면 폐쇄됩니다. 귀하의 기여에 감사드립니다.

아직 제기되지 않은 한 가지 우려는 일부 콘텐츠가 법적 이유로 제거해야 할 수 있다는 것입니다. 예를 들어 사용자 X가 문제에 정말 불법적인 내용을 게시했다고 가정해 보겠습니다. 물론 계정은 즉시 해지되지만 현재 사이트 관리자는 사이트에 불법 콘텐츠가 있어 삭제할 수 없습니다.

또한 관리자가 데이터베이스에서 문제를 제거하는 방법을 항상 알고 있는 것은 아닙니다. UI 내에서 이 작업을 수행하는 옵션은 관리자가 사용자를 100% 신뢰할 수 있는 경우가 아니면 필수입니다(드물게 그런 경우임).

관리자가 데이터베이스에서 문제를 제거하는 방법을 항상 알고 있는 것은 아닙니다.

풀 리퀘스트를 삭제하고 싶습니다. GUI를 사용할 수 있기 전에 다음 SQL이 충분합니까?

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

풀 리퀘스트 URL 끝에 있는 숫자가 10이라고 가정
http://localhost :3200/org_name/repo_name/pulls/10

약간의 의견이지만 다음은 닫는 대신 삭제해야 한다고 생각하는 항목의 목록입니다.

• 불법적이거나 공격적이거나 원치 않는 콘텐츠가 포함된 문제.
• 프로젝트 whatsoeve와 관련이 없는 완전히 관련 없는 콘텐츠입니다.
• 기타(유사) 프로젝트 광고
• 저자가 톤다운을 거부하는 강한 언어

닫을 수 있지만 일부 유지 관리자 및/또는 관리자는 더 깨끗한 백로그를 유지하기 위해 여전히 삭제를 원할 수 있습니다.

• 새로운 정보를 추가하지 않는 중복 문제
• ur s0ftware suxx 개선을 위한 근거나 제안이 없는 비판

이것이 관리자와 저장소 유지 관리자가 특정 상황에서 문제를 완전히 삭제하는 것이 종종 의미가 있다는 점을 강조하기를 바랍니다.

DB에서 문제가 제거되었습니다. 지금 해결하는 방법은 무엇입니까?

자체 호스팅 git repo 서버로서 사이트 관리자는 저장소 소유자가 "원하는 모든 작업"을 수행할 수 있어야 한다고 생각합니다.

예를 들어, 나는 내 서버의 소유자이며(그렇지 않지만 그렇게 할 수 있는 옵션이 있는 경우에도 동일할 것입니다), 내 저장소의 소유자로서 직접 문제를 열기를 원합니다. 시간이 지남에 따라 내가 하는 일을 다른 사람들에게 보여주고 어리석은 헛소리뿐만 아니라 유용한 것들을 추가한다는 사실을 알리기 위해 하루 종일? 바보 같은 쓸모없는 코드? ").

그러나 내가 내 문제에 대해 작업할 때(또한 당신의 90%가 적어도 한 번은 했을 것입니다) 일반적으로 내 자신의 레이블 구성표 아래에도 항목을 어디에 넣어야 하는지 모르기 때문에 레이블을 추가한 다음 제거하는 경향이 있습니다. 내 "이슈 기록"이 다음과 같을 때까지 다른 레이블 아래에 문제를 할당하는 등의 작업을 계속 합니다 .

그 진부한 우유부단함을 삭제하고 새로운 문제를 다시 시작할 수 있다면 매우 좋을 것입니다.

DB에서 문제가 제거되었습니다. 지금 이 문제를 해결하는 방법은 무엇입니까?

나는 같은 문제가 발생한 후에 실제로 이것을 알아 냈습니다. 데이터베이스의 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: 이것이 바로 삭제 문제가 구현되지 않는 이유입니다. 성능상의 이유로 이슈 번호는 DB에 캐싱됩니다( num_issues ). 이 숫자는 다음 이슈 번호( num_issues + 1 )에도 사용됩니다.

DB에 이 값을 복제하고 last_issue_nr 또는 next_issue_nr 를 수정 사항으로 사용할 수 있습니다. 또는 hidden -boolean을 이슈 테이블에 추가할 수 있습니다. 후자의 경우 문제는 UI(및 API)에서만 숨겨져 있지만 필요한 경우 나중에 참조할 수 있습니다(법적 이유는 스레드의 앞부분에서 언급됨).

그냥 내 2 센트

이 번호는 다음 발행 번호( num_issues + 1 )에도 사용됩니다.

좀 빠지는. 현재 SELECT MAX(index)+1 FROM issue WHERE repo_id = ? 입니다.

이것이 바로 문제 삭제가 구현되지 않는 이유입니다

아니요, 그렇기 때문에 수동으로 엉망으로 만들어서는 안됩니다. :)
이유는 중요하지 않습니다. 내 사이트를 완전히 제어하고 싶습니다. 이 기능을 구현해야 합니다.

이것은 특히 스팸의 대상이 된 경우 공개적으로 사용 가능한 gitea 설치에 필요합니다.

나에게 닫기 기능은 프로젝트와 관련된 문제를 닫기 위한 것이며 관련 없는 스팸을 닫는 데 사용해서는 안 되며 삭제하는 것이 좋습니다.

마지막 index 는 저장소 테이블이나 다른 곳에 저장해야 합니다.

마지막 index 는 저장소 테이블이나 다른 곳에 저장해야 합니다.

xorm이 모든 db에서 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)

이런 식으로 문제를 추가하기 위해 하나의 잠금만 생성했습니다(즉, 실제 저장소 행은 나머지 트랜잭션에 대해 잠기지 않았습니다). 행을 추가하려는 다른 트랜잭션은 첫 번째 업데이트가 해결될 때까지 잠기므로 중복 가능성이 없습니다. 첫 번째 트랜잭션이 롤백되면 두 번째 트랜잭션은 올바른 다음 값을 얻습니다.

이렇게 하면 최신 문제를 삭제하더라도 값이 재사용되지 않습니다.

@guillep2k 더 나은 소리.

@guillep2k가 제안한 @lunny 솔루션은 상사처럼 합법적인 것 같습니다. 하지만 @DJFraz가 2019년 8월 27일에 언급했듯이 이슈 카운터는 런타임으로 계산되지만 캐싱을 위해 데이터베이스에 저장되기 때문에 이를 어떻게 처리해야 한다고 생각하십니까?
감사 해요.

@guillep2k가 제안한 @lunny 솔루션은 상사처럼 합법적인 것 같습니다. 하지만 @DJFraz가 2019년 8월 27일에 언급했듯이 이슈 카운터는 런타임으로 계산되지만 캐싱을 위해 데이터베이스에 저장되기 때문에 이를 어떻게 처리해야 한다고 생각하십니까?

문제를 열거나 닫을 때와 마찬가지로 "캐시된" 값을 다시 계산하면 됩니다.

해당 주석의 문제는 사용자가 변경 사항을 반영하도록 적절한 열을 업데이트하지 않고 행 삭제를 시도했다는 것입니다.

해당 주석의 문제는 사용자가 변경 사항을 반영하도록 적절한 열을 업데이트하지 않고 행 삭제를 시도했다는 것입니다.

그래서, techincally ... 데이터베이스에서 삭제 일을 _manually_ 아무것도 파괴하지 않고 넘어갈 수 있습니까?

그래서, techincally ... 데이터베이스에서 삭제 일을 _manually_ 아무것도 파괴하지 않고 넘어갈 수 있습니까?

문제 번호가 재사용되는 문제가 있습니다. 잘못된 댓글 #999 을 삭제하고 마지막에 발생하면 다음 좋은 댓글에도 #999 번호가 부여됩니다. 이 번호는 no no no입니다. 새 주석은 실제로 #1000 #999 여야 하고 숫자

문제를 삭제 가능하게 만드는 것에 반대하는 사람들에게: 괜찮지만 편집 기록 삭제를 허용합니다.

대안: 보기에서 원치 않는 문제를 완전히 숨기고 관리자가 숨겨진 문제를 볼 수 있는 옵션을 추가하는 것은 어떻습니까?

이렇게 하면 자신의 사이트에서 법적으로 위험한 콘텐츠를 삭제할 수 없는 문제가 해결되고 문제 목록이 정리됩니다.

이렇게 하면 자신의 사이트에서 법적으로 위험한 콘텐츠를 삭제할 수 없는 문제가 모두 해결됩니다.

@DarkWiiPlayer 문제는

문제 숨기기: 레이블과 사람 및 마음을 바꾸는 결정의 추가 및 제거로 가득 찬 문제 기록이 있는 중복 문제와 복잡한 내용을 원하지 않는 사람들에게 좋습니다.
그러나 서버 디스크에 불법 콘텐츠가 저장된 경우에는 좋지 않습니다...

@DarkWiiPlayer 문제는

그건 좋은 지적이야. '경찰이 안봐도 괜찮을거야' 라는 관점에서 봤던거 같은데 그래도 사이트 소유자에게 피해를 줄 수 있는 이유는 무작정 찾는 사람부터 찾아내는 사람까지 다양하다. 이러한 콘텐츠를 의도적으로 업로드한 다음 경찰에 알립니다.

나는 여전히 숨겨진 문제가 없는 것보다 낫다고 생각하며, 문제를 편집하고 편집 기록을 지우는 것과 함께 여전히 작동할 것입니다.

이상적으로는 문제를 진정으로 "삭제"하는 옵션이 모든 데이터를 스크러빙하고 DB에서 "삭제됨"으로 설정하는 것을 의미하더라도 최선의 솔루션이 될 것입니다.

그건 좋은 지적이야.

감사 해요.

'경찰이 한 번도 보지 않으면 괜찮다'는 관점에서 바라보고 있었던 것 같다.

유감스럽게도 저장매체에 불법파일이 있을 경우에는 그렇게 되지 않습니다.. URL을 통해 공개적으로 사용할 수 없는 경우에도 신고를 하고 확인을 하면 망합니다. "하지만 그것은 사용자가 업로드한 콘텐츠"라고 말할 수 있는 정도...

이것을 갖는 이유 목록에 추가하려면: 저는 현재 2명의 다른 공동 작업자와 비공개 저장소에서 작업을 구성하고 있으므로 현재 우리의 커뮤니케이션에는 공개적으로 공개하지 않을 세부 정보가 포함되어 있습니다. 그러나 우리가 프로젝트를 공개적으로 발표하기로 결정한 미래 시점에 리포지토리가 공개될 가능성이 있습니다. 그 시점에서 프로젝트 가시성을 공개적으로 설정하여 공개하기 전에 문제 섹션을 완전히 지우는 방법이 있으면 좋을 것입니다.

언젠가는 이 기능을 보는 것이 좋을 것입니다. 어쨌든 gitea에 대한 모든 작업에 감사하고 훌륭한 작업을 계속하십시오!