RefractTrack Projects: Difference between revisions
Nerdofepic (talk | contribs) No edit summary |
Nerdofepic (talk | contribs) No edit summary |
||
| Line 29: | Line 29: | ||
* [[RefractTrack_Tasks|Tasks]] | * [[RefractTrack_Tasks|Tasks]] | ||
* [[RefractTrack_Permissions_and_Roles|Permissions and Roles]] | * [[RefractTrack_Permissions_and_Roles|Permissions and Roles]] | ||
[[Category:RefractTrack]] | |||
Latest revision as of 03:31, 3 September 2026
Projects
A project is how RefractTrack keeps different games (or different teams, or different chunks of a bigger game) cleanly separate from each other. Each one gets its own board, its own tasks, its own set of columns and tags, and its own task numbering — nothing you do in one project ever spills over into another.
When you create a project, you give it a name and a short prefix, like RPG or SFRPG. That prefix is what shows up in every task code in that project — the first task you create is RPG-1, the next is RPG-2, and so on. Short prefixes make for tidy, easy-to-say task codes, so it's worth picking something memorable.
Every new project also starts out with a ready-made set of columns and tags — you don't have to build a workflow from scratch. See Stages and Groups for what comes built in and how to customize it.
Switching between projects
If your team works across more than one project, a switcher in the navigation bar lets you jump between them instantly. A couple of nice touches make this smoother:
- RefractTrack remembers which project you were last working in, so the next time you log in, it opens exactly where you left off instead of always starting on your first project.
- Switching projects keeps you on the same kind of page — if you were looking at the list view, you'll land on the list view for the new project too, rather than being bounced back to the board every time.
- Any search or filter you had active is cleared when you switch, since a filter that made sense for one project (like a specific column) might not mean anything in another.
Archiving a project
Projects aren't deleted outright — instead, an admin can deactivate one once it's no longer active (a finished or shelved game, for example). A deactivated project's history is preserved and nothing is lost; it simply stops showing up in everyday use. This is a deliberate safety net: there's no way to permanently wipe out a whole project's history by mistake.
Who can access a project
Team access to a project can be controlled independently for each person — someone can be a full admin overall but still only see the specific projects they've been given access to. See Permissions and Roles for more on how this works.