Page MenuHomePhorge

Set default menu item to Project Details when archiving a project
AbandonedPublic

Authored by aklapper on Jul 11 2024, 23:07.

Details

Summary

When archiving a project, other views than the "Project Details" offer no indicator that a project has been archived apart from the blurred profile picture.
The Project Details page however shows a red "Archived" indicator (and the description may provide pointers what happened if someone updated it after archiving).
Showing the Project Details page allows users to more likely realize that a project has been archived (and the workboard or other menu item view of the archived project have likely become less relevant at this stage anyway).

Thus when archiving a project which has its default view not set to the "Project Details" page (use the "Manage > Edit Menu" to check), (re)set the default menu item to the Project Details page.

Closes T15882

Test Plan
  • Archive a project with its existing Workboard set as default; go to its /tag/projectname URI: After applying the patch, it shows the project Profile
    • After applying the patch and archiving, SELECT menuItemKey, builtinKey, visibility FROM phabricator_search.search_profilepanelconfiguration cp JOIN phabricator_project.project p ON p.phid = cp.profilePHID WHERE (p.name = "MyLittleProject"); shows that project.workboard changed its visibility from default to visible and project.profile from visible to default
  • Activate an archived project with its existing workboard set as default; go to its /tag/projectname URI: After applying the patch, still shows the project Workboard as expected, thus only applied when archiving.

Diff Detail

Repository
rP Phorge
Branch
T15882archiveProject
Lint
Lint Passed
Unit
Tests Passed
Build Status
Buildable 1437
Build 1437: arc lint + arc unit

Event Timeline

Thanks. Feature makes sense and implementation seems good (but I have untested).

I think there is also an expandTransactions() possibility in PhabricatorProjectTransactionEditor. That's extra work and probably not leading anywhere, but that would cover also API (if ever desired - and, anyway, API can already manually change this thing... via API). I also do not think it would be a good idea to use foreign editors in an expandTransactions().

So, seems good to me as-is. Will hard-accept after some extra testing.

Since you helped a lot in D25774 - I'm not sure this is needed anymore. Maybe better to get better opinions. For example I found this a bit irritating for my archived Milestones.

An additional check to make milestone owners happy might be: look to see if the board shows at least one task. If not, proceed.

But I wouldn't know how to do that :D

Since you helped a lot in D25774 - I'm not sure this is needed anymore. Maybe better to get better opinions. For example I found this a bit irritating for my archived Milestones.

Yeah, I'd be fine abandoning this patch and implementing this patch as-is in the downstream instance which I maintain.

An additional check to make milestone owners happy might be: look to see if the board shows at least one task. If not, proceed.

I don't favor implementing non-obvious behavior ("why does it sometimes do this but not always"). :)

I don't favor implementing non-obvious behavior ("why does it sometimes do this but not always"). :)

Eh my friend, I don't know. But if the root cause is that an empty Workboard increases confusion, I think it's fine to "hide" that as default. Instead, we have not enough use-cases to demonstrate that non-empty workboards should be hided as default.

Abandoning in favor of T15890 and D25774 per previous discussion