Archive a Project
Every now and then you have a project that you aren't working on anymore, but don't feel like deleting just yet. You think you might need the data for reference, but don't want to receive notifications or see the issues from the project on your boards. You want a result similar to deleting a project, but without actually deleting it and losing all its data.
For such cases, you have the option to archive a project.
To archive a project:
Select a project on the Projects page.
- Click the Archive project button.
Under certain conditions (for example, if the project is used in cross-project agile boards), you are asked to confirm the operation.
The selected project is archived. You can no longer create issues in the project.
Restore a Project
Unlike deleting a project, archiving is a reversible operation. You can easily restore an archived project when you need to.
To restore a project:
Click the Projects link in the header and scroll to the bottom of the page.
Expand the list of archived projects.
Click the name of an archived project to open the project profile.
Click the Restore project button.
Archived Projects and Agile Boards
When a project is archived, any agile board associated with it becomes inaccessible. While in the case of a single-project board this is expected, in a cross-project board it is highly undesirable. When you attempt to archive a project that is used in one or more cross-project boards, you get a dialog with three actions:
Option | Description |
|---|---|
Remove from boards | Archive the project and remove it from any cross-project agile board it is associated with in the system. |
Ignore | Ignore the warning, archive the project and make any cross-project agile board that uses the project inaccessible. On your own head be it! |
Cancel | Cancel archiving the project. |
Archived Projects and Workflows
When a project is archived, all of the workflows that are attached to it are deactivated. However, workflows that are attached to active projects can access issues in any project, even if the project is archived. For example, workflows that update issues with specific link types can return issues in any project.
If you have workflows that are applying unwanted updates to issues in archived projects, modify the script to check the isArchived property of the target project. You can reference this property in guard properties and conditional statements to block changes to issues in archived projects.
The Subtasks default workflow contains rules with conditional statements that block updates to issues in archived projects. Here's the conditional statement that references the isArchived property:
if (parent && parent.project && !parent.project.isArchived && parent.isReported && parent.isResolved)Archived Projects and Merged User Accounts
When you merge two user accounts, the resulting set of permissions is the sum of permissions each of the two users had previously. You may encounter strange results when you archive projects with private fields.
Let's say a user (let's call him 'john.d') has permission to view private fields in Project A, and another user (let's call him 'j.doe') does not have this permission. You archive Project A, and and later decide to merge the user account for 'john.d' into 'j.doe'. As result, the user account for 'j.doe' now has permission to view private fields in Project A. If you later restore Project A, this user, who originally did not have permission to view private fields in the project, can now see them.
If the two merged accounts belong to the same person, this might not be a big deal. If you merge two accounts that belong to different users, keep this possibility in mind.