Page MenuHomePhabricator

Allow task statuses to "lock" them, preventing additional comments and interactions
ClosedPublic

Authored by epriestley on Mar 2 2017, 9:27 PM.
Tags
None
Referenced Files
F19169874: D17453.diff
Mon, Dec 15, 8:28 PM
F19103365: D17453.id.diff
Fri, Dec 5, 9:52 AM
F19098889: D17453.diff
Thu, Dec 4, 6:33 PM
F18866700: D17453.diff
Nov 3 2025, 6:46 PM
F18842074: D17453.id41967.diff
Oct 28 2025, 1:11 PM
F18842073: D17453.id41965.diff
Oct 28 2025, 1:11 PM
F18842072: D17453.id41964.diff
Oct 28 2025, 1:11 PM
F18842071: D17453.id.diff
Oct 28 2025, 1:11 PM
Subscribers
None

Details

Summary

Ref T12335. See that task for discussion. Here are the behavioral changes:

  • Statuses can be flagged with locked, which means that tasks in that status are locked to further discussion and interaction.
  • A new "CAN_INTERACT" permission facilitates this. For most objects, "CAN_INTERACT" is just the same as "CAN_VIEW".
  • For tasks, "CAN_INTERACT" is everyone if the status is a normal status, and no one if the status is a locked status.
  • If a user doesn't have "Interact" permission:
    • They can not submit the comment form.
    • The comment form is replaced with text indicating "This thing is locked.".
    • The "Edit" workflow prompts them.

This is a mixture of advisory and hard policy checks but sholuld represent a reasonable starting point.

Test Plan

Created a new "Locked" status, locked a task. Couldn't comment, saw lock warning, saw lock prompt on edit. Unlocked a task.

Diff Detail

Repository
rP Phabricator
Branch
interact2
Lint
Lint Passed
Unit
Tests Passed
Build Status
Buildable 15868
Build 21000: Run Core Tests
Build 20999: arc lint + arc unit

Event Timeline

Locked task:

Screen Shot 2017-03-02 at 1.30.04 PM.png (982×1 px, 122 KB)

Override prompt (requires edit permission):

Screen Shot 2017-03-02 at 1.30.47 PM.png (982×1 px, 127 KB)

Can we get the name of the object somehow? "This task has been locked"

I think it's going to get a little gross, but I'll see what I can do.

  • Specialize all the strings for the object type.
  • Replace the "subscribe" specialization for the extension with an object type specialization.
This revision is now accepted and ready to land.Mar 3 2017, 12:40 AM
This revision was automatically updated to reflect the committed changes.