Project

General

Profile

Actions

Idea #18390

closed

Frozen projects

Added by Peter Amstutz almost 3 years ago. Updated about 2 years ago.

Status:
Resolved
Priority:
Normal
Assigned To:
-
Target version:
-
Start date:
03/01/2022
Due date:
07/31/2022
Story points:
-

Description

“Frozen” project state is modeled with a new uuid attribute (database field) of Arvados projects called "frozen_by_uuid”. Users with “can_manage” permission are allowed to set "frozen_by_uuid" (which is set to that user). Once set, "frozen_by_uuid" state cannot be cleared, except by an admin.

The "frozen" state applies recursively to everything owned by the project: collections, workflow provenance, etc. Objects owned by the project cannot be independently un-frozen (but they can be copied). To modify an object inside a frozen project, the entire project must first be un-frozen (which can only be done by admins).

Objects that are frozen or are owned directly or indirectly by a project in the frozen state are read-only and cannot be modified by users that would normally have write permission, including admins.

  • Cannot create/move objects within a frozen project (owner_uuid of a create or update operation cannot be a frozen project)
  • Cannot move objects out of an frozen project (owner_uuid of frozen object 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
  • Cannot freeze a project that contains objects with “trash_at” or “delete_at” set (attempt to set “frozen” will return an error with at least one object uuid which is blocking freezing)
  • Cannot trash a project that contains frozen objects (attempt to set “trash_at” will return an error)
  • Users with “can_manage” permission can still control sharing (create and remove permission links for frozen objects)

Make it configurable that in order to freeze a project, the description field or some other named properties must be non-empty.

In order to freeze a project, update the "frozen_by_uuid" field to the current user. Any other value is rejected. An admin un-freezes a project by setting "frozen_by_uuid" to "" (empty string).

  • optional parameter "dry_run" or "no_op" on the freeze project call which only checks if a project is valid to freeze, but does not commit the change
    • the "dry_run" parameter provides a structured response either indicating the operation would be successful, or a list of reasons it would fail
    • Returns a 200 response on success with content just {"uuid": "..."} and a 4xx response if the operation would fail
  • Trashed items in a frozen project are not returned with "include_trash" (should be explicitly filtered out from the call), from the user's perspective, trashed items in a frozen project are immediately gone, unless the project is un-frozen.

The following Workbench 2 features will be implemented by the customer:

  • Add button to Workbench 2 enabling users to freeze a project (with warning). Workbench 2 will determine if an object or direct/indirect owner is frozen and adds an “Frozen” badge to the display.
  • Workbench 2 feature to assist in making a project valid to freeze: If items exist with “trash_at” or “delete_at”, prompt user if they want to un-trash all of them, or move them out of the project to be frozen.

Related issues

Related to Arvados - Feature #18691: Frozen project supportResolvedTom Clegg03/08/2022Actions
Related to Arvados - Feature #19146: Return can_manage and can_write alongside writable_byResolvedTom Clegg06/07/2022Actions
Related to Arvados - Bug #19145: Frozen project still writableResolvedTom Clegg06/06/2022Actions
Related to Arvados - Feature #18692: Frozen projects workbench supportResolvedDaniel Kutyła05/19/2022Actions
Actions #1

Updated by Peter Amstutz almost 3 years ago

  • Start date set to 01/01/2022
  • Due date set to 04/30/2022
Actions #2

Updated by Peter Amstutz almost 3 years ago

  • Start date changed from 01/01/2022 to 03/01/2022
  • Due date changed from 04/30/2022 to 05/31/2022
Actions #3

Updated by Peter Amstutz almost 3 years ago

  • Description updated (diff)
Actions #4

Updated by Peter Amstutz almost 3 years ago

  • Description updated (diff)
Actions #5

Updated by Peter Amstutz almost 3 years ago

  • Description updated (diff)
Actions #6

Updated by Peter Amstutz almost 3 years ago

Actions #8

Updated by Peter Amstutz over 2 years ago

  • Due date changed from 05/31/2022 to 04/30/2022
Actions #9

Updated by Peter Amstutz over 2 years ago

  • Due date changed from 04/30/2022 to 05/31/2022
Actions #10

Updated by Peter Amstutz over 2 years ago

  • Related to Feature #19146: Return can_manage and can_write alongside writable_by added
Actions #11

Updated by Peter Amstutz over 2 years ago

  • Status changed from New to In Progress
Actions #12

Updated by Peter Amstutz over 2 years ago

  • Due date changed from 05/31/2022 to 07/31/2022
Actions #13

Updated by Peter Amstutz over 2 years ago

  • Related to Bug #19145: Frozen project still writable added
Actions #14

Updated by Peter Amstutz over 2 years ago

Actions #15

Updated by Peter Amstutz about 2 years ago

  • Status changed from In Progress to Resolved
Actions

Also available in: Atom PDF