Jump to content

RefractTrack Projects: Difference between revisions

From Pixel Refraction Studio
Created page with "== Projects == RefractTrack tracks tasks across one or more independent '''projects'''. Every project has: * A '''name''' and a short '''prefix''' (e.g. <code><nowiki>RPG</nowiki></code>, <code><nowiki>SFRPG</nowiki></code>) — every task inside the project is numbered off its prefix (<code><nowiki>RPG-1</nowiki></code>, <code><nowiki>RPG-2</nowiki></code>, ...), giving Jira-style task codes with matching clean URLs (<code><nowiki>/task/RPG-12</nowiki></code>). * Its..."
 
No edit summary
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
== Projects ==
== Projects ==


RefractTrack tracks tasks across one or more independent '''projects'''. Every project has:
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.


* A '''name''' and a short '''prefix''' (e.g. <code><nowiki>RPG</nowiki></code>, <code><nowiki>SFRPG</nowiki></code>) every task inside the project is numbered off its prefix (<code><nowiki>RPG-1</nowiki></code>, <code><nowiki>RPG-2</nowiki></code>, ...), giving Jira-style task codes with matching clean URLs (<code><nowiki>/task/RPG-12</nowiki></code>).
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.
* Its own independent set of [[RefractTrack_Stages|Stages]], [[RefractTrack_Groups|Groups]], and [[RefractTrack_Bulk_Task_Creation_and_Saved_Lists|Saved Lists]] — every new project is seeded with a standard starter set of each at creation time, and changes to one project's stages/groups/lists never affect another project's.
* Its own task numbering sequence.


=== Creating and managing projects ===
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 [[RefractTrack_Stages|Stages]] and [[RefractTrack_Groups|Groups]] for what comes built in and how to customize it.


Projects are managed from Manage → Projects (<code><nowiki>projects.php</nowiki></code> / <code><nowiki>project_form.php</nowiki></code>), gated by the <code><nowiki>projects:*</nowiki></code> permissions (<code><nowiki>view</nowiki></code>, <code><nowiki>create</nowiki></code>, <code><nowiki>edit</nowiki></code>, <code><nowiki>activate</nowiki></code> — see [[RefractTrack_Permissions_and_Roles|Permissions and Roles]]).
=== Switching between projects ===


=== Soft delete only ===
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:


Projects support '''deactivation''' (<code><nowiki>is_active</nowiki></code> flag), not hard deletion — this is deliberately the only kind of project removal offered; there is no hard-delete path in the application. A deactivated project's data (tasks, stages, groups, history) is preserved but the project stops appearing in normal use.
* 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.


=== Access control ===
=== Archiving a project ===


Which users can see or work in a given project is controlled independently of a user's global permissions, via <code><nowiki>user_project_access</nowiki></code>. A user can hold a permission like <code><nowiki>tasks:edit:content</nowiki></code> globally but still be denied for a specific project they haven't been granted access to — see "Project-scoped permissions" in [[RefractTrack_Permissions_and_Roles|Permissions and Roles]].
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.


=== Switching projects ===
=== Who can access a project ===


The nav bar includes a project switcher. Choosing a different project there:
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 [[RefractTrack_Permissions_and_Roles|Permissions and Roles]] for more on how this works.
 
* Immediately remembers the new project as the user's last-used project (see [[RefractTrack_Per_User_Preferences|Per User Preferences]]).
* Returns the user to the '''same kind of page''' they were on rather than always bouncing to the board — Export stays on Export, List stays on List, and so on, for the top-level project-scoped list pages (board, list, groups, stages, bulk create, bulk lists, approvals, export, import, archived). Sub-forms (new/edit forms) and single-resource pages (a specific task, a specific stage's edit form) fall back to the new project's board instead, since there's no equivalent page to stay on.
* Deliberately drops any active view filters (search/sort/group/assignee/stage) rather than carrying them over, since a filter like a specific stage could point at a stage that doesn't exist in the newly-selected project.


=== Related pages ===
=== Related pages ===
Line 33: Line 29:
* [[RefractTrack_Tasks|Tasks]]
* [[RefractTrack_Tasks|Tasks]]
* [[RefractTrack_Permissions_and_Roles|Permissions and Roles]]
* [[RefractTrack_Permissions_and_Roles|Permissions and Roles]]
* [[RefractTrack_Per_User_Preferences|Per User Preferences]]
 
[[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.