I'm just going to close this out, since I'm not sure we really need it -- D14963, D14962, and other work adjacent to T2450 found some general performance improvements in rendering. It's possible we might pursue this (and/or a highlighting cache) in the future, but I think we're fast enough now that the huge amount of upfront work the daemons would have to do to populate these caches probably doesn't make a ton of sense.

This is more than a year old now and we haven't seen other requests for it. Diffusion copy/pastes and links cleanly and I think this is sufficient in all reasonable cases I'm aware of.

Sorry, I still don't understand your root problem.

I'm going to merge this into T9622, but -- oh, @chad already got it.

Flags currently has this unwieldy dropdown, which will only get worse over time as more applications and object types are added. It would be better to use a typeahead, like the one in global search:

I removed this because the implementation was pretty hacky (saved the rule as a text string, wasn't translatable).

@chad, not sure if you have design thoughts here, but I think this is broadly reasonable.

I think it's too hard for us to guess user intent here. There's nothing a user can do which strongly signals that their flag is obsolete, since flags mean a lot of different things (in your use case, it sounds like there's no single action you take which clears the flag, just "the next action after you added the flag"). Other users (myself included) use flags for different reasons, including as long-term bookmarks. Guessing intent is also difficult because you can flag many kinds of objects, not just tasks, and we'd strongly prefer features which can be implemented globally.

Overall, the problems I currently see with watch/subscribe are:

For the sake of completeness, the root issue you described elsewhere (unsubscribes cascading into more unsubscribes) is fixed (at least, indirectly) at HEAD, after 536d3a2, which stops self-subscribes and self-unsubscribes from publishing feed stories, mail, and notifications.

I don't currently plan to remove the option

Oh, by "remove the option" I meant "remove the option to subscribe to a project if you are not a member of the project" -- that is, "Subscribe" is disabled if you aren't a project member. I don't currently plan to remove the option, although I am leaning towards making members not be subscribed by default.

This isn't the same as T6183 or T6113, and isn't expected.

T4027 is another case of commits titled [JIRA-123] Blah blah blah.

This is very old, possibly fixed by now, doesn't include reproduction steps, and other users haven't reported issues. If you have specific issues with externals and reproduction steps, feel free to file new tasks.

This is extremely old and I think no longer relevant. The crumbs now show the current branch, and I think Diffusion got better about consistently showing and retaining branches.

T5744 mentions another narrower and more reasonable use case (get specific badness which matches some pattern fixed), which is similar to the Mochi/i18n stuff.

T5046 has a specific case of this causing particularly questionable behavior when doing HTTP clones -- since the object is totally hidden, you don't get prompted for credentials.

This is expected with Spaces, which completely hide objects (primarily as a performance consideration). I'm going to merge this into T9771 which discusses this issue more broadly.

T8296 is a similar case for "Add Mirror".

This behavior is not expected. Please file a bug report with reproduction instructions.

In T10004#151960, @joshuaspence wrote:

OK, I managed to reproduce it on this install, see T10083. Specifically see T10083#151963 in which I attempted to close the task as resolved.

sdfgdsfgSdfadsgfsdfgsef

Three out of four's not bad.

Fourth time's a charm

Third time lucky?

Attempting to close the task again.

OK, I managed to reproduce it on this install, see T10083. Specifically see T10083#151963 in which I attempted to close the task as resolved.

Attempting to close this task.

This is another comment.

This is a comment.

Actually, I am seeing still seeing this issue on our install on tasks which aren't affected by any Herald rule (that I know of).

Thanks for the report! Let us know if you run into anything else.

In T10004#151717, @joshuaspence wrote:

Yeah, I can't reproduce it anymore either. I definitely saw it earlier today on a different install (which is up-to-date within a couple of hours) but I don't know what was special then.

See the documentation: sh -c `some subcommand`