Feature #17493
Updated by Peter Amstutz over 2 years ago
Feature: user * User can put a project tree in "archive" state which makes it read-only to everyone Proposed design: * New attribute of group "archive_at" * Users with can_manage access can modify "archive_at" ** "archive_at" field itself can be modified when null or "now < archive_at" ** Once "now >= archive_at" the archive_at field cannot be modified by users, only admins * Cutoff means one of these things, need to decide which: ** Read-only behavior takes effect when "now >= archive_at", if "now < archive_at" users with write access can continue to make updates. ** Read-only when archive_at is non-null, *but* if "now < archive_at" a user with can_manage permission is allowed to clear "archive_at" to make updates. * "archived" state applies to everything owned by the project, recursively. (same behavior as "trashed" projects) * Archived objects are read-only for users and admins regardless of permissions (with limited exceptions for the archived_at field itself described above) ** Cannot create/move objects in an archived project (owner_uuid cannot be an archived project) ** Cannot move objects out of an archived project (owner_uuid cannot be changed) ** Cannot update any other field on archived objects, e.g. name, manifest_text ** Cannot delete objects owned by archived project or modify trash_at, delete_at ** Setting "archive" clears any "delete_at" fields of any object in the archived project ** Objects that were trashed before remain trashed, but will not be deleted * Users with can_manage permission can still adjust sharing (create and remove permission links on archived objects)