Xóa vai trò

reassignTo được truyền dưới dạng tham số QUERY thay vì trong body. Body trên DELETE là hợp lệ nhưng không được hỗ trợ rộng rãi (một số runtime bỏ nó đi và nhiều proxy cũng vậy), và một reassignTo bị bỏ đi thì không thể phân biệt với một giá trị chưa bao giờ được gửi, đó chính là trường hợp mà endpoint này từ chối thay vì đoán.

Tham số này bắt buộc ngay khi có ai đó giữ vai trò: nếu thiếu, bạn nhận role_in_use, mã 409, kèm param: "reassignTo", chính là chỗ cần sửa. Bên dưới, cột này là ON DELETE RESTRICT, nên không có cách nào để việc xóa một vai trò lặng lẽ thay đổi những gì ai đó được làm.

Các khóa API được trỏ lại thay vì bị bỏ mồ côi, và đó là nửa tinh tế. Một khóa có vai trò biến mất sẽ rơi về mức trần NULL, và mức trần null RỘNG HƠN vai trò vừa bị xóa, nên nếu không, việc xóa một vai trò hạn chế sẽ lặng lẽ nâng quyền mọi khóa mà nó đang giới hạn.

Hai con số được tách riêng vì đó là hai thứ khác nhau cần kiểm tra: reassigned là con người, những người sẽ nhận ra, còn keysReassigned là chương trình, thứ sẽ không nhận ra.

Không thể xóa vai trò owner (role_undeletable, mã 409) vì nó chỉ tài khoản mà không gian làm việc gắn với, chứ không phải một công việc ai đó làm. Mọi vai trò khác đều có thể xóa, các vai trò được seed sẵn Admin, Member, Viewer, Developer và Billing cũng như vai trò do ai đó tự viết: chúng là điểm khởi đầu, và một không gian làm việc không có tích hợp nào thì không cần một hàng Developer mà nó không được phép loại bỏ. Hãy kiểm tra deletable trước khi hiển thị nút; chỉ owner trả về false.

Việc xóa một vai trò ĐƯỢC SEED không phải là vĩnh viễn, nên đừng viết hộp thoại như thể là vậy. GET /roles seed lại bất kỳ hàng mẫu nào bị thiếu, và việc xóa không để lại tombstone, nên lần đọc danh sách tiếp theo sẽ đưa Developer trở lại với một id mới. Đổi tên là cách khiến nó không quay lại nữa (hàng đã đổi tên giữ builtin và tiếp tục xung đột với bản seed), hoặc một vai trò khác lấy tên đó cũng có tác dụng, vì trình seed bỏ qua hàng có tên đã được dùng.