Missions help teams manage Issues/PRs with a centralized view across organizations/repositories.

Creating a Mission

Go to CNB, click the "+" in the top right corner, and select Create Mission.

• Mission Name: The identifier for the mission, which will also form part of the mission's access path.

• Data Scope: Manages the data sources of Issues/PRs in the mission.

  

Mission Views

In a mission, you can:

• Configure views, and the mission will automatically read the latest status of Issues/Pull Requests.

• Freely configure/switch between table view and kanban view to manage Issues/PRs from different perspectives.

• View Issues/PRs under specific conditions through filtering, sorting, and searching.

• Quickly create Issues for specified target repositories.

• Enter kanban view to quickly modify item priorities through drag and drop.

Table view example:

Kanban view example:

Mission Settings

Click on the right side of the mission, then select Settings to enter the mission settings page. You can configure basic settings, advanced settings, and manage mission members.

Basic Settings

You can modify the mission name and edit the data scope and other basic information of the mission.

Tips

Modifying the mission name will change the mission's access URL, please proceed with caution.

Advanced Settings

You can copy the mission, modify its visibility, and delete the mission.

Tips

Modifying mission visibility will affect its access scope, and deleting a mission cannot be undone, please proceed with caution.

Mission Members

By default, all member permission relationships from the parent organization are inherited. Additionally, you can click Invite Members to directly invite members to join the current mission as either "Mission Members" or "External Collaborators." External collaborators are suitable for users who temporarily participate in the collaboration.

The roles and permissions of members are as follows:

Mission Permissions

1. For a user to access the mission view, the following two permissions must be satisfied simultaneously:

   • The user is a member of the mission.
   • The user is a member of the repository associated with the mission.

2. Within the mission, a user's permissions for operating on Issues/PRs are consistent with their permissions in the corresponding repository.

Example: Mission A is associated with Repository A and Repository B. Tom has permission to edit the titles of Issues in Repository A but only has read-only permission for Issues in Repository B. Therefore, in Mission A, Tom can edit the titles of all Issues in Repository A but only has read-only access to all Issues in Repository B and cannot perform any operations on them.