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, its issues are no longer accessible. However, the agile boards that reference the archived project are still available in the application.
If you open an agile board that refers to an archived project, the board shows a configuration error. This error tells you that at least one of the projects in the board settings has been archived. If the board settings reference fields that are unique to the archived projects, these are also listed as configuration errors.
References to archived projects are not removed from the boards that store them. If the project is restored at a later date, its issues are accessible in the system and can be shown on the agile boards that reference the project. The configuration error related to the archived project is no longer shown.
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:
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.