Page MenuHomePhabricator

Don't lock subscription in PhameBlog
ClosedPublic

Authored by chad on Sep 23 2016, 12:52 PM.
Tags
None
Referenced Files
F13088795: D16589.diff
Thu, Apr 25, 1:33 AM
Unknown Object (File)
Wed, Apr 17, 2:49 PM
Unknown Object (File)
Mon, Apr 15, 1:37 PM
Unknown Object (File)
Fri, Apr 12, 9:08 PM
Unknown Object (File)
Fri, Apr 12, 9:08 PM
Unknown Object (File)
Fri, Apr 12, 9:03 PM
Unknown Object (File)
Fri, Apr 12, 8:18 PM
Unknown Object (File)
Mon, Apr 8, 6:49 AM
Subscribers

Details

Summary

Ref T11687. Subscription to Blogs comes with many additional features, don't lock people in.

Test Plan

Saw I was no longer subscribed.

Diff Detail

Repository
rP Phabricator
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

chad retitled this revision from to Don't lock subscription in PhameBlog.
chad updated this object.
chad edited the test plan for this revision. (Show Details)
chad added a reviewer: epriestley.
epriestley edited edge metadata.

We might still want to default-subscribe you when you create one (like we do with Maniphest) but I'm not sure how useful/important/expected that is.

This revision is now accepted and ready to land.Sep 23 2016, 12:53 PM

Yeah I dug around but couldn't find a method that does that? Is it in editengine?

There's no easy way to do it right now. We should probably make it easier, but the Maniphest approach is in the Editor:

// Automatically subscribe the author when they create a task.
if ($this->getIsNewObject()) {
  if ($actor_phid) {
    $results[] = id(new ManiphestTransaction())
      ->setTransactionType(PhabricatorTransactions::TYPE_SUBSCRIBERS)
      ->setNewValue(
        array(
          '+' => array($actor_phid => $actor_phid),
        ));
  }
}

This kind of isn't great because you don't see the [epriestley (Evan Priestley)] token in the input when you create a task, you just get silently auto-subscribed after you hit "Save". I think a better behavior would be to prefill the input so you can immediately take yourself out, but if we do that it conflicts with EditEngine forms that have a default value.

T10222 discusses some ideas sort of in this vein (have these fields merge application defaults with user defaults, maybe) but I'm not sure that's the right fix.

Here, since the only way to add the behavior is a tiny bit sketchy and I'm not sure how valuable it is, I'd probably just not bother. But I haven't though too carefully about use cases or expectations here.

This revision was automatically updated to reflect the committed changes.