भूमिका हटाएँ

reassignTo body में नहीं, QUERY पैरामीटर के रूप में जाता है। DELETE पर body वैध है और व्यापक रूप से असमर्थित (कई रनटाइम उसे गिरा देते हैं और कई प्रॉक्सी भी), और गिरा दिया गया reassignTo उससे अलग नहीं दिखता जो कभी भेजा ही न गया हो — और ठीक यही वह मामला है जिस पर यह एंडपॉइंट अनुमान लगाने के बजाय मना कर देता है।

जैसे ही कोई उस भूमिका को रखता है, यह आवश्यक हो जाता है: इसके बिना role_in_use, एक 409, param: "reassignTo" लिए हुए, जो असली समाधान है। नीचे कॉलम ON DELETE RESTRICT है, इसलिए ऐसा कोई रास्ता नहीं जहाँ भूमिका हटाने से चुपचाप बदल जाए कि कोई क्या कर सकता है।

API कुंजियाँ अनाथ नहीं छोड़ी जातीं, उन्हें दोबारा इंगित किया जाता है, और यही सूक्ष्म हिस्सा है। जिस कुंजी की भूमिका गायब हो जाए वह NULL सीमा पर लौट आती, और null सीमा उस भूमिका से चौड़ी होती है जो अभी गई — यानी प्रतिबंधात्मक भूमिका हटाना वरना चुपचाप उसकी हर सीमित कुंजी को पदोन्नत कर देता।

दोनों गिनतियाँ अलग हैं क्योंकि जाँचने को वे दो अलग चीज़ें हैं: reassigned लोग हैं, जिन्हें पता चल जाएगा, और keysReassigned प्रोग्राम हैं, जिन्हें नहीं चलेगा।

मालिक की भूमिका हटाई नहीं जा सकती (role_undeletable, एक 409) क्योंकि वह किसी काम का नहीं, बल्कि उस खाते का नाम लेती है जिस पर वर्कस्पेस टिका है। बाकी हर भूमिका जा सकती है — seed की गई Admin, Member, Viewer, Developer और Billing भी उतनी ही, जितनी किसी की लिखी हुई: वे एक शुरुआती बिंदु हैं, और जिस वर्कस्पेस में कोई इंटीग्रेशन नहीं, उसके लिए ऐसी Developer row का कोई उपयोग नहीं जिससे छुटकारा पाने की इजाज़त न हो। बटन दिखाने से पहले deletable जाँचें; केवल मालिक false देता है।

seed की गई भूमिका हटाना स्थायी नहीं है, इसलिए डायलॉग में ऐसा न लिखें जैसे हो। GET /roles जो भी टेम्पलेट row गायब हो उसे दोबारा seed कर देता है, और delete कोई टॉम्बस्टोन नहीं छोड़ता, इसलिए अगली बार सूची पढ़ने पर Developer नई id के साथ लौट आता है। उसे लौटने से रोकने का तरीका है उसका नाम बदल देना (नाम बदली row अपना builtin रखती है और seed से टकराती रहती है), या कोई दूसरी भूमिका वह नाम ले ले, क्योंकि seeder उस row को छोड़ देता है जिसका नाम पहले से लिया जा चुका है।