Gitea: साइट व्यवस्थापकों के पास व्यवस्थापक पैनल पर समस्याओं को हटाने के लिए UI होना चाहिए

~जैसा कि हमने गटर पर कहा, मुझे नहीं लगता कि इसके लिए कोई आवश्यकता है और लगभग सभी गिट होस्ट सॉफ़्टवेयर समस्या को हटाने की अनुमति नहीं देते हैं।~

आईएमएचओ यह एक बग नहीं है, यह एक विशेषता है। यह सुनिश्चित करता है कि कोई भी इस मुद्दे की दृश्यता में हेरफेर न करे।

मुझे समस्या नहीं दिख रही है, अगर समस्या यह है कि कोई भी इसे हटा सकता है, तो इसे "मालिक" या उस व्यक्ति को क्यों न देखें जिसने वास्तव में शुरुआत से ही इस मुद्दे को बनाया है?

मेरा मतलब है कि मान लें कि मैंने इसे बनाया है, और फिर मैं इसके बारे में सोचता हूं और जानता हूं कि इसकी कोई आवश्यकता थी या मेरा अनुरोध मूर्खतापूर्ण था या कोई अन्य कारण जो मुझे इसे हटा देगा, बस कुछ भी नहीं होने के बजाय।

मेरी नजर में इसका कोई मतलब नहीं है

तब मुद्दे "बेवकूफ" साबित होते हैं और बंद हो जाना बहुत मददगार होता है! मान लें कि किसी के पास एक ही संदेह या समस्या है, बंद मुद्दा किसी चीज़ पर "दस्तावेज़ीकरण" है जो तब कोई मुद्दा नहीं साबित हुआ, और यदि समस्या निर्माता इसे जोड़ता है तो इसमें इसे हल करने के निर्देश भी होंगे।

एकमात्र मामला जिसमें मैं अवैध सामग्री के मामले में समझ में आने वाले मुद्दों को हटा रहा हूं। उस स्थिति में, केवल टिप्पणी हटाएं या समस्या को संपादित करें ताकि अवैध सामग्री न हो।

मैं देख सकता हूं कि आपकी बात क्या है, लेकिन मैं अभी भी अपने मामले में सहमत नहीं हूं, मैं अकेला हूं जो मेरी रिपॉजिटरी चलाता है, इसलिए मुझे वह फ़ंक्शन याद आती है जो उस सामान को हटा देता है जो वहां नहीं होना चाहिए

यदि आप मेरी गलती से कोई समस्या पैदा करते हैं, तो आप शीर्षक और मुख्य भाग को बदलकर Invalid और इसे बंद कर सकते हैं

मुझे अभी भी यह पसंद नहीं है, लेकिन मैं देखता हूं कि कोई और मुझसे सहमत नहीं है।

मेरी नज़र में वह अशुद्ध है

अशुद्ध हाँ, लेकिन लगातार

उदाहरण के लिए जब आप किसी ISSUE_TEMPLATE का परीक्षण कर रहे हों या प्रोजेक्ट प्रवाह को समझने की कोशिश कर रहे हों, तो यह आपके लिए अपनी समस्याओं को

कम से कम जब आप रिपॉजिटरी के मालिक हों।

यह सुविधा उपलब्ध होनी चाहिए क्योंकि यह रिपॉजिटरी के मालिक पर निर्भर करता है कि वह यह तय करे कि उसके प्रोजेक्ट के लिए कौन सा वर्कफ़्लो उपयुक्त है।

मालिक इसे डीबी से भी हटा सकता है :)

स्पैमर विज्ञापनों के साथ मुद्दों को छोड़ रहे हैं और मैं व्यवस्थापक के रूप में उन्हें हटा नहीं सकता ‍♂️ हर बार डीबी को साफ करना पड़ता था ...

साइट को आसान बनाए रखने के लिए साइट व्यवस्थापकों के पास व्यवस्थापक पैनल पर समस्याओं को हटाने की अनुमति होनी चाहिए

इस समस्या को स्वचालित रूप से पुराने के रूप में चिह्नित कर दिया गया है क्योंकि इसमें हाल की गतिविधि नहीं है। यदि अगले 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/puls/10

बस एक राय है, लेकिन यहां उन चीजों की एक सूची है जो मुझे लगता है कि बंद होने के बजाय हटा दी जानी चाहिए:

• अवैध, आपत्तिजनक या अन्यथा अवांछित सामग्री वाली समस्याएं.
• पूरी तरह से असंबंधित सामग्री जिसका परियोजना से कोई लेना-देना नहीं है।
• अन्य (समान) परियोजनाओं के लिए विज्ञापन
• मजबूत भाषा जिसे लेखक ने कम करने से इंकार कर दिया

चीजें हैं जो सिर्फ बंद कर दिया जा सकता है, लेकिन कुछ देखरेख और / या प्रशासकों अभी भी एक क्लीनर बैकलॉग रखने के लिए हटाना चाह सकते हैं:

• डुप्लीकेट मुद्दे जो कोई नई जानकारी नहीं जोड़ते
• बिना किसी आधार के आलोचना या सुधार के लिए सुझाव la ur s0ftware suxx

मुझे उम्मीद है कि यह इस बात को रेखांकित करता है कि यह अक्सर समझ में आता है, दोनों प्रशासकों और रिपॉजिटरी अनुरक्षकों के लिए कुछ स्थितियों में मुद्दों को पूरी तरह से हटा देना।

डीबी से हटाई गई समस्या, अब इसे कैसे ठीक करें?

एक स्व-होस्ट किए गए गिट रेपो सर्वर के रूप में मुझे यह भी लगता है कि साइट व्यवस्थापक को रिपोजिटरी मालिकों को "जो कुछ भी पसंद है" करने की अनुमति देने में सक्षम होना चाहिए।

उदाहरण के तौर पर, मैं अपने सर्वर का मालिक हूं (और यहां तक ​​कि अगर मैं ऐसा करने के लिए सक्षम विकल्प नहीं था, तो यह वही होगा), और मैं अपने रेपो के मालिक के रूप में भी मुद्दों को खोलने के लिए चाहता हूं अन्य लोगों को दिखाने के लिए कि मैं समय के साथ काम करता हूं और मैं उपयोगी सामान जोड़ता हूं, न कि केवल बेवकूफ बकवास (केवल इसलिए कि 90% लोग जिन्हें मैं जानता हूं वे कभी भी इतिहास नहीं देखते हैं और मेरे परिश्रम को साबित करने के लिए काउंटर करते हैं और बस कहते हैं "'नरक तुम करते हो सारा दिन? बेवकूफ बेकार कोड? ")।

हालाँकि जब मैं अपने स्वयं के मुद्दों पर काम करता हूँ (और आप में से 90% ने शायद कम से कम एक बार किया था) तो आमतौर पर यह नहीं पता होता है कि चीजों को अपनी लेबल योजना के तहत कहाँ रखा जाए, इसलिए मैं एक लेबल जोड़ता हूं, फिर उसे हटा देता हूं और किसी अन्य लेबल के तहत इस मुद्दे असाइन करते हैं, और इतने पर इतना आगे तक मेरी "मुद्दा इतिहास" की तरह कुछ लग रहा है इस ...

उस भद्दे अनिर्णय को हटाने और एक नया मुद्दा शुरू करने में सक्षम होना बहुत अच्छा होगा (या कम से कम मेरे अनिर्णय के "लेबल इतिहास" को हटा दें) ...

डीबी से हटाई गई समस्या, अब इसे कैसे ठीक करें?

मेरे पास एक ही समस्या होने के बाद मुझे वास्तव में यह पता चला। अपने डेटाबेस के repository टेबल पर जाएं। ओपन इश्यू काउंट 2 कॉलम num_issues और num_closed_issues । मैंने 47 num_issues को 46 और इसने गिनती को अपडेट कर दिया।

@DJFraz
num_issues से त्रुटि 500 ​​हो जाती है जब नया मुद्दा बनाने का प्रयास किया जाता है, तो मुझे इसके बजाय num_closed_issues बढ़ाना पड़ा।

num_closed_issues को बदलना भी एक अच्छा विचार नहीं था :) गीता इसे मुद्दों की तालिका के अनुसार अपडेट करती है।
तो यह या तो मुद्दों को हटा रहा है और फिर यह सुनिश्चित कर रहा है कि num_issues + 1 मौजूदा अंक अनुक्रमणिका के साथ विरोध नहीं करेगा या सिर्फ एक समस्या को बंद कर और इसकी सामग्री को खाली कर देगा।

:point_up: यही कारण है कि मुद्दों को हटाना लागू नहीं किया गया है। प्रदर्शन कारणों से डीबी में मुद्दों की संख्या कैश की जाती है ( num_issues ), इस संख्या का उपयोग अगले अंक संख्या ( num_issues + 1 ) के लिए भी किया जाता है।

कोई इस मान को डीबी में डुप्लिकेट कर सकता है और एक फिक्स के रूप में last_issue_nr या next_issue_nr सकता है। या कोई hidden -बूलियन को इश्यू-टेबल में जोड़ सकता है। बाद के मामले में मुद्दा केवल यूआई (और एपीआई) से छिपा हुआ है, लेकिन बाद में यदि आवश्यक हो तो संदर्भित किया जा सकता है (कानूनी कारणों का उल्लेख पहले धागे में किया गया था)

बस मेरे 2 सेंट

इस नंबर का उपयोग अगले अंक संख्या ( num_issues + 1 ) के लिए भी किया जाता है।

काफी नहीं। वर्तमान में यह SELECT MAX(index)+1 FROM issue WHERE repo_id = ? ।

यही कारण है कि मुद्दों को हटाना लागू नहीं किया गया है

नहीं, इसलिए आपको उनके साथ मैन्युअल रूप से गड़बड़ नहीं करनी चाहिए :)
मुझे कारणों की परवाह नहीं है, मैं अपनी साइट पर पूर्ण नियंत्रण चाहता हूं, इस सुविधा को लागू किया जाना चाहिए।

यह सार्वजनिक रूप से उपलब्ध गीता प्रतिष्ठानों के लिए आवश्यक है, खासकर यदि आपको स्पैम के साथ लक्षित किया गया है।

मेरे लिए क्लोज फीचर प्रोजेक्ट से संबंधित किसी मुद्दे को बंद करने के लिए होना चाहिए और एक असंबंधित स्पैम को बंद करने के लिए उपयोग नहीं करना चाहिए जिसे हटाना बेहतर होगा।

हमें अंतिम 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)

इस तरह, हमने एक मुद्दा जोड़ने के लिए केवल एक लॉक का उत्पादन किया (यानी वास्तविक रिपोजिटरी पंक्ति को शेष लेनदेन के लिए लॉक नहीं किया गया था)। पंक्तियों को जोड़ने का प्रयास करने वाले अन्य लेन-देन को पहले अद्यतन के हल होने की प्रतीक्षा में लॉक कर दिया जाएगा ताकि डुप्लिकेट की कोई संभावना न हो। यदि पहला लेन-देन वापस आ जाता है, तो दूसरे को इसके लिए सही अगला मूल्य मिलेगा।

इससे यह भी सुनिश्चित होगा कि किसी भी मूल्य का पुन: उपयोग नहीं किया जाता है, भले ही हम नवीनतम अंक को हटा दें।

@ guillep2k जो बेहतर लगता है।

@ guillep2k द्वारा प्रस्तावित लूनी समाधान एक मालिक की तरह वैध लगता है; लेकिन जैसा कि @DJFraz ने 27 अगस्त 2019 को नोट किया था, चूंकि इश्यू काउंटर की गणना रनटाइम पर की जाती है, लेकिन फिर कैशिंग के लिए डेटाबेस में संग्रहीत की जाती है, आपको क्या लगता है कि उन्हें कैसे हैंडल करना चाहिए?
धन्यवाद।

@ guillep2k द्वारा प्रस्तावित लूनी समाधान एक मालिक की तरह वैध लगता है; लेकिन जैसा कि @DJFraz ने 27 अगस्त 2019 को नोट किया था, चूंकि इश्यू काउंटर की गणना रनटाइम पर की जाती है, लेकिन फिर कैशिंग के लिए डेटाबेस में संग्रहीत की जाती है, आपको क्या लगता है कि उन्हें कैसे हैंडल करना चाहिए?

यह केवल "कैश्ड" मानों की पुनर्गणना करने की बात है, ठीक वैसे ही जैसे हम किसी मुद्दे को खोलते/बंद करते समय करते हैं।

उस टिप्पणी में समस्या यह है कि उपयोगकर्ता ने परिवर्तन को दर्शाने के लिए उपयुक्त कॉलम को अपडेट किए बिना पंक्ति को हटाने का प्रयास किया।

उस टिप्पणी में समस्या यह है कि उपयोगकर्ता ने परिवर्तन को दर्शाने के लिए उपयुक्त कॉलम को अपडेट किए बिना पंक्ति को हटाने का प्रयास किया।

तो, techincally ... यह संभव डेटाबेस से हटाने की बातें _manually_ और इसके साथ कुछ भी तोड़ने के बिना प्राप्त करने के लिए है?

तो, techincally ... यह संभव डेटाबेस से हटाने की बातें _manually_ और इसके साथ कुछ भी तोड़ने के बिना प्राप्त करने के लिए है?

अंक संख्या के पुन: उपयोग की समस्या है। यदि आप खराब टिप्पणी #999 हटाते हैं और यह अंतिम होती है, तो अगली अच्छी टिप्पणी को #999 भी नंबर मिलेगा, जो कि नहीं नहीं है। नई टिप्पणी वास्तव में #1000 #999 होनी चाहिए और संख्या

उन लोगों के लिए जो मुद्दों को हटाने योग्य बनाने के खिलाफ हैं: ठीक है, लेकिन फिर संपादन इतिहास को हटाने की अनुमति दें।

वैकल्पिक रूप से: अवांछित मुद्दों को पूरी तरह से छिपाने और व्यवस्थापकों के लिए छिपे हुए मुद्दों को देखने के लिए एक विकल्प जोड़ने के बारे में क्या?

यह आपकी साइट से कानूनी रूप से खतरनाक सामग्री को हटाने में सक्षम नहीं होने और समस्या-सूची को अव्यवस्थित करने वाली दोनों समस्याओं को ठीक करेगा

यह आपकी अपनी साइट से कानूनी रूप से खतरनाक सामग्री को हटाने में सक्षम नहीं होने के साथ दोनों समस्याओं को ठीक करेगा

@DarkWiiPlayer बात यह है कि संभावित रूप से अवैध सामग्री, जैसे कि एक पीडो पोर्नोग्राफ़िक छवि, अभी भी आपके सर्वर ड्राइव पर उपलब्ध है, और एक पुलिस अधिकारी से आपकी सेवाओं पर अनुरोधित चेक द्वारा पहुँचा जा सकता है ...

मुद्दों को छुपाना: उन लोगों के लिए ठीक है जो डुप्लिकेट मुद्दों और अव्यवस्थित सामान को लेबल और लोगों और लोगों को जोड़ने और हटाने से भरा मुद्दा इतिहास और दिमाग बदलने वाले निर्णय नहीं लेना चाहते हैं।
हालांकि सर्वर की डिस्क पर संग्रहीत अवैध सामग्री के लिए ठीक नहीं है...

@DarkWiiPlayer बात यह है कि संभावित रूप से अवैध सामग्री, जैसे कि एक पीडो पोर्नोग्राफ़िक छवि, अभी भी आपके सर्वर ड्राइव पर उपलब्ध है, और एक पुलिस अधिकारी से आपकी सेवाओं पर अनुरोधित चेक द्वारा पहुँचा जा सकता है ...

ये एक अच्छा बिंदु है। मुझे लगता है कि मैं इसे इस दृष्टिकोण से देख रहा था कि "अगर पुलिस इसे कभी नहीं देखती है, तो आप ठीक हैं", लेकिन इसके कई कारण हैं कि यह अभी भी साइट के मालिक को नुकसान पहुंचा सकता है, किसी को बेतरतीब ढंग से इसे खोजने से जानबूझकर ऐसी सामग्री अपलोड करना, फिर पुलिस को सूचित करना।

मुझे अभी भी लगता है कि छिपे हुए मुद्दे कुछ भी नहीं से बेहतर हैं, और इस मुद्दे को संपादित करने और इसके संपादन इतिहास को साफ़ करने के संयोजन में, यह अभी भी काम करेगा।

आदर्श रूप से हालांकि, समस्या को वास्तव में "डिलीट" करने का एक विकल्प, भले ही इसका मतलब सभी डेटा को स्क्रब करना और इसे डीबी में "डिलीट" पर सेट करना हो, सबसे अच्छा समाधान होगा।

ये एक अच्छा बिंदु है।

धन्यवाद।

मुझे लगता है कि मैं इसे इस नजरिए से देख रहा था कि "अगर पुलिस इसे कभी नहीं देखती है, तो आप ठीक हैं"

दुर्भाग्य से यह उस तरह से काम नहीं करता है जब आपके स्टोरेज माध्यम में अवैध फाइलें होती हैं ... भले ही वे यूआरएल के माध्यम से सार्वजनिक रूप से उपलब्ध न हों, अगर कोई रिपोर्ट बनाई जाती है और चेक दायर किया जाता है, तो आप खराब हो जाते हैं, कोई फर्क नहीं पड़ता कितना "लेकिन वह उपयोगकर्ता द्वारा अपलोड की गई सामग्री है" आप कह सकते हैं ...

इसके होने के कारणों की सूची में जोड़ने के लिए: मैं वर्तमान में 2 अन्य सहयोगियों के साथ एक निजी रेपो में काम का आयोजन कर रहा हूं, इस प्रकार हमारे संचार में वर्तमान में वे विवरण शामिल हैं जिन्हें हम सार्वजनिक रूप से प्रकट नहीं करेंगे। हालांकि संभावना है कि रेपो को भविष्य में सार्वजनिक किया जाएगा जब हम परियोजना को खुले तौर पर जारी करने का निर्णय लेंगे। उस समय परियोजना दृश्यता को जनता के लिए सेट करने और इस प्रकार इसके साथ खुले में जाने से पहले मुद्दों के खंड को पूरी तरह से मिटा देने का एक तरीका होना बहुत अच्छा होगा।

किसी बिंदु पर इस सुविधा को देखना बहुत अच्छा होगा, वैसे भी गीत पर सभी काम के लिए धन्यवाद और महान काम जारी रखें!