Gitea: يجب أن يكون لدى مسؤولي الموقع واجهة مستخدم لحذف المشكلات على لوحة الإدارة

~ كما قلنا في gitter ، لا أعتقد أن هناك متطلبًا لذلك وتقريبًا جميع برامج مضيف git لا تسمح بحذف المشكلة.

IMHO ليس خطأ ، إنها ميزة. يتأكد من أن لا أحد يتلاعب برؤية القضية.

لا أرى المشكلة ، إذا كانت المشكلة هي أنه يمكن لأي شخص حذفها ، فلماذا لا تنظر إلى "المالك" أو الشخص الذي تسبب في المشكلة بالفعل منذ البداية؟

أعني ، دعنا نقول إنني فعلت هذا ، ثم أفكر في الأمر وأعلم أنه كان هناك حاجة إليه أو أن طلبي كان غبيًا أو لأي سبب آخر من شأنه أن يجعلني أزيله من أجل لا شيء.

هذا لا معنى له على الإطلاق في عيني

القضايا التي تثبت بعد ذلك أنها "غبية" ويتم إغلاقها مفيدة للغاية! لنفترض أن شخصًا ما لديه نفس الشك أو المشكلة ، فإن المشكلة المغلقة هي "التوثيق" بشأن شيء ثبت بعد ذلك أنه لا يمثل مشكلة ، وإذا أضافه منشئ المشكلة ، فسيحتوي أيضًا على إرشادات حول كيفية حلها.

الحالة الوحيدة التي أرى فيها حذف المشكلات منطقيًا في حالة المحتوى غير القانوني. في هذه الحالة ، ما عليك سوى حذف التعليق أو تعديل المشكلة حتى لا تحتوي على العناصر غير القانونية.

أستطيع أن أرى ما هي وجهة نظرك ، لكنني ما زلت لا أوافق في حالتي ، فأنا الشخص الوحيد الذي يدير ملفي ، ولهذا السبب أفتقد هذه الوظيفة ، قم بحذف الأشياء التي لا يجب أن تكون هناك

إذا قمت بإنشاء مشكلة عن طريق الخطأ ، يمكنك فقط تغيير العنوان والجسم إلى Invalid وإغلاقه

ما زلت لا أحب ذلك ، لكني لا أرى أي شخص آخر يتفق معي.

في عيني هذا نجس

نعم غير نظيفة ، لكنها متسقة 🙂

عندما تقوم على سبيل المثال باختبار ISSUE_TEMPLATE أو محاولة فهم تدفق المشروع ، سيكون من المفيد جدًا أن تتمكن من حذف المشكلات الخاصة بك ...

على الأقل عندما تكون مالك المستودع.

يجب أن تكون هذه الميزة متاحة لأن الأمر متروك لمالك المستودع لتحديد سير العمل المناسب لمشروعه / مشروعها.

يمكن للمالك أيضًا حذفه من db :)

يترك مرسلو الرسائل غير المرغوب فيها مشكلات مع الإعلانات ولا يمكنني كمسؤول حذفها 🤦‍♂️ اضطررت إلى تنظيف قاعدة البيانات في كل مرة ...

يجب أن يكون لدى مسؤولي الموقع أذونات لحذف المشكلات الموجودة على لوحة الإدارة للحفاظ على الموقع أسهل

تم وضع علامة على هذه المشكلة تلقائيًا على أنها قديمة نظرًا لعدم وجود نشاط حديث لها. سيتم إغلاقه إذا لم يحدث أي نشاط آخر خلال الأسبوعين المقبلين. شكرا لمساهماتكم.

أحد المخاوف التي لم يتم التطرق إليها بعد ، هو أن بعض المحتويات قد تتطلب الإزالة لأسباب قانونية. لنفترض ، على سبيل المثال ، أن المستخدم X ينشر بعض الأشياء غير القانونية حقًا في مشكلة ما. بالطبع ، يتم إنهاء حسابهم على الفور ، ولكن الآن لدى مسؤول الموقع محتوى غير قانوني على موقعه ولا يمكنه حذفه.

يرجى أيضًا ملاحظة أن المسؤول لا يعرف دائمًا كيفية إزالة مشكلة من قاعدة البيانات ؛ يعد خيارًا للقيام بذلك من داخل واجهة المستخدم أمرًا ضروريًا ما لم يتمكن المسؤولون من الوثوق بمستخدميهم بنسبة 100 ٪ (وهذا نادرًا ما يحدث).

لا يعرف المسؤول دائمًا كيفية إزالة مشكلة من قاعدة البيانات ؛

أود حذف طلب سحب. قبل توفر واجهة المستخدم الرسومية ، هل لغة 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

مجرد رأي ، ولكن إليك قائمة بالأشياء التي أعتقد أنه يجب حذفها بدلاً من إغلاقها:

• المشكلات التي تحتوي على محتوى غير قانوني أو مسيء أو غير مرغوب فيه بأي شكل آخر.
• محتوى غير ذي صلة تمامًا ولا صلة له بالمشروع على الإطلاق.
• الإعلان عن مشاريع أخرى (مماثلة)
• لغة حادة يرفض المؤلف تخفيفها

الأشياء التي يمكن إغلاقها للتو ، لكن بعض المشرفين و / أو المسؤولين قد لا يزالون يرغبون في حذفها للحفاظ على تراكم أكثر نظافة:

• قضايا مكررة لا تضيف أي معلومات جديدة
• نقد بدون أي أساس أو اقتراحات للتحسينات على طريقة ur s0ftware suxx

آمل أن يؤكد هذا على النقطة التي غالبًا ما يكون من المنطقي ، بالنسبة للمسؤولين ومشرفي المستودعات حذف المشكلات تمامًا في مواقف معينة.

تمت إزالة المشكلة من DB ، كيف يتم إصلاح ذلك الآن؟

بصفتي خادم git repo مستضاف ذاتيًا ، أعتقد أيضًا أن مسؤول الموقع يجب أن يكون قادرًا على السماح لمالكي المستودعات بالقيام "بما يحلو لهم".

على سبيل المثال ، أنا مالك الخادم الخاص بي (وحتى إذا لم يكن لدي خيارات ممكّنة للقيام بذلك ، فستكون هي نفسها) ، وأود أيضًا بصفتي مالك الريبو الخاص بي ، أن أفتح المشكلات بنفسي لأظهر للآخرين العمل الذي أقوم به بمرور الوقت وأنني أضيف أشياء مفيدة ، وليس مجرد حماقات غبية (فقط لأن 90٪ من الأشخاص الذين أعرفهم لا يشاهدون أبدًا التاريخ ويلتزمون بإثبات اجتهادي ويقولون فقط "بحق الجحيم تفعل طوال اليوم؟ رمز عديم الفائدة غبي؟ ").

ومع ذلك ، عندما أعمل على مشكلاتي الخاصة (وأيضًا 90٪ منكم على الأرجح فعلوا ذلك مرة واحدة) لا أعرف عادةً مكان وضع الأشياء حتى ضمن مخطط التسمية الخاص بي ، لذلك أميل إلى إضافة تصنيف ، ثم إزالته و قم بتعيين المشكلة تحت تصنيف آخر ، وهكذا دواليك حتى يبدو "سجل المشكلات" الخاص بي مثل هذا ...

سيكون من الجيد جدًا أن تكون قادرًا على حذف هذا التردد السيء وبدء مشكلة جديدة من جديد (أو على الأقل حذف "سجل التسمية" الخاص بترددي في ما سأكون عليه) ...

تمت إزالة المشكلة من DB ، كيف يتم إصلاح ذلك الآن؟

لقد اكتشفت ذلك بالفعل بعد أن واجهت نفس المشكلة. انتقل إلى الجدول repository لقاعدة البيانات الخاصة بك. عدد الإصدارات المفتوحة هو المطروح الفرعية للعمودين num_issues و num_closed_issues . لقد غيرت 47 num_issues إلى 46 وتم تحديث العدد.

تضمين التغريدة
أدى خفض 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 منطقية

فقط سنتان

يتم استخدام هذا الرقم أيضًا لما سيكون عليه رقم الإصدار التالي ( num_issues + 1 ).

ليس تماما. حاليًا هو SELECT MAX(index)+1 FROM issue WHERE repo_id = ? .

هذا هو بالضبط سبب عدم تنفيذ حذف المشكلات

لا ، لهذا السبب لا يجب أن تعبث معهم يدويًا :)
لا يهمني الأسباب ، أريد التحكم الكامل في موقعي ، يجب تنفيذ هذه الميزة.

هذا ضروري لعمليات تثبيت gitea المتاحة للعامة خاصة إذا تم استهدافك بالبريد العشوائي.

بالنسبة لي ، يجب أن تكون ميزة الإغلاق لإغلاق مشكلة تتعلق بالمشروع وليس استخدامها لإغلاق بريد عشوائي غير مرتبط والذي يجب حذفه بشكل أفضل.

يجب علينا تخزين آخر index في جدول المستودع أو أي شيء آخر.

يجب علينا تخزين آخر index في جدول المستودع أو أي شيء آخر.

يبدو هذا بالتأكيد كحل لمشكلة فهرس التحديث أيضًا ، طالما أن xorm يدعم SELECT FOR UPDATE على جميع dbs. أعتقد أنه كذلك ، أليس كذلك؟

فيما يتعلق بإنشاء القيم المتسلسلة التي يجب أن تكون متتالية (أي لا توجد ثقوب) ، في مشروع قمت به منذ فترة طويلة كان لدينا جدول منفصل لتوليد هذه القيم. على سبيل المثال:

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 شرعيًا مثل الرئيس ؛ ولكن كما لاحظ DJFraz في 27 أغسطس 2019 ، نظرًا لأن عدادات
شكرا.

يبدو الحل @ guillep2k شرعيًا مثل الرئيس ؛ ولكن كما لاحظ DJFraz في 27 أغسطس 2019 ، نظرًا لأن عدادات

إنها فقط مسألة إعادة حساب القيم "المخزنة مؤقتًا" ، تمامًا كما نفعل عندما نفتح / نغلق أي مشكلة.

تكمن المشكلة في هذا التعليق في أن المستخدم حاول حذف الصف دون تحديث الأعمدة المناسبة لتعكس التغيير.

تكمن المشكلة في هذا التعليق في أن المستخدم حاول حذف الصف دون تحديث الأعمدة المناسبة لتعكس التغيير.

لذا، techincally ... فمن الممكن أن _manually_ الأشياء الحذف من قاعدة البيانات وتفلت من العقاب دون كسر أي شيء؟

لذا، techincally ... فمن الممكن أن _manually_ الأشياء الحذف من قاعدة البيانات وتفلت من العقاب دون كسر أي شيء؟

هناك مشكلة إعادة استخدام أرقام الإصدار. إذا حذفت التعليق السيئ #999 وحدث أنه الأخير ، سيحصل التعليق الجيد التالي على الرقم #999 أيضًا ، وهو ليس "لا". يجب أن يكون التعليق الجديد في الواقع #1000 #999 ويجب ترك الرقم

إلى الأشخاص الذين يعارضون جعل المشكلات قابلة للحذف: جيد ، ولكن بعد ذلك يسمحون بحذف محفوظات التحرير.

بدلاً من ذلك: ماذا عن إخفاء المشكلات غير المرغوب فيها تمامًا من العرض وإضافة خيار للمسؤولين لعرض المشكلات المخفية؟

سيؤدي هذا إلى حل مشكلة عدم القدرة على حذف المحتوى الخطير قانونيًا من موقعك الخاص وإزالة الفوضى في قائمة المشكلات

سيؤدي هذا إلى حل مشكلة عدم القدرة على حذف المحتوى الخطير قانونيًا من موقعك

DarkWiiPlayer ، الشيء هو أن المحتوى غير القانوني المحتمل ، مثل الصورة الإباحية المشوهة ، لا يزال متاحًا على محرك الخادم الخاص بك ، ويمكن الوصول إليه عن طريق التحقق المطلوب من خدماتك من ضابط شرطة ...

إخفاء المشكلات: جيد للأشخاص الذين لا يريدون أن يكون لديهم مشكلات مكررة وأشياء مزدحمة مع سجل المشكلات المليء بإضافة وإزالة التسميات والأشخاص والقرارات المتغيرة للعقل.
ليس جيدًا ولكن بالنسبة للمحتوى غير القانوني المخزن على أقراص الخادم ...

DarkWiiPlayer ، الشيء هو أن المحتوى غير القانوني المحتمل ، مثل الصورة الإباحية المشوهة ، لا يزال متاحًا على محرك الخادم الخاص بك ، ويمكن الوصول إليه عن طريق التحقق المطلوب من خدماتك من ضابط شرطة ...

هذه نقطة جيدة. أعتقد أنني كنت أنظر إليه من منظور "إذا لم تراه الشرطة مطلقًا ، فأنت بخير" ، ولكن هناك مجموعة متنوعة من الأسباب التي قد تؤدي إلى استمرار إلحاق الضرر بمالك الموقع ، بدءًا من شخص يجده عشوائيًا إلى شخص آخر تحميل مثل هذا المحتوى عمدًا ، ثم إبلاغ الشرطة.

ما زلت أعتقد أن المشكلات المخفية أفضل من لا شيء ، وبالاقتران مع تحرير المشكلة وتنظيف محفوظات التحرير الخاصة بها ، فإنها ستظل تعمل.

من الناحية المثالية ، فإن خيار "حذف" المشكلة حقًا ، حتى لو كان هذا يعني فقط مسح جميع البيانات وتعيينها على "حذف" في قاعدة البيانات ، سيكون الحل الأفضل.

هذه نقطة جيدة.

شكرا.

أعتقد أنني كنت أنظر إليه من منظور "إذا لم تراه الشرطة أبدًا ، فأنت بخير"

لسوء الحظ ، لا يعمل الأمر على هذا النحو عندما يكون لديك ملفات غير قانونية في وسيط التخزين الخاص بك ... حتى لو لم تكن متاحة للجمهور من خلال عنوان URL ، إذا تم تقديم تقرير وتم إيداع شيك ، فأنت في حالة من الفوضى ، بغض النظر عن ما المقدار "لكن هذا المحتوى الذي حمّله المستخدم" يمكنك أن تقول ...

للإضافة إلى قائمة أسباب الحصول على هذا: أقوم حاليًا بتنظيم العمل في إعادة شراء خاصة مع متعاونين آخرين ، وبالتالي تتضمن اتصالاتنا حاليًا تفاصيل لن نكشف عنها علنًا. ومع ذلك ، فمن المحتمل أن يتم الإعلان عن الريبو في مرحلة مستقبلية عندما نقرر إطلاق المشروع علانية. في هذه المرحلة ، سيكون من الرائع أن يكون لديك طريقة لمسح قسم المشكلات تمامًا قبل تعيين رؤية المشروع للجمهور وبالتالي الدخول في العلن معه.

سيكون من الرائع رؤية هذه الميزة في وقت ما ، على أي حال ، شكرًا على كل العمل على gitea ومتابعة العمل الرائع!