Workaround is to URL-encode the parenthesis (%29) or use the remarkup style

[Back to the Future](https://en.wikipedia.org/wiki/Starship_Troopers_(film%29)
[[ https://en.wikipedia.org/wiki/Starship_Troopers_(film) | Jurassic Park ]]

Results in:
[Back to the Future](https://en.wikipedia.org/wiki/Starship_Troopers_(film%29)
Jurassic Park

One use case for "locking" a task could be:

1. For a release of the software product all tasks which represent the software changes on the version being released require review
2. Reviewer looks over task form fields and if everything looks good, "signs" (locks) the task in a "reviewed" state
3. Tasks can be unsigned prior to release of the version, allowing updates to tasks as necessary but also requiring another review
4. Upon release of the version, tasks can no longer be unsigned

We've implemented a basic version of this, roughly along the lines of the recommendation above. Here's how it works:

Ok, then feel free to dismiss this one… I didn't expect those kind of complexities behind this :)

Yeah any typeahead dialog now that I think about it.

(I think I've used this workflow fewer than 5 times outside of testing, and although similar workflows like "Award Badge" and "Add Project Members" have the same issue, I think they're similarly rare.)

This is also nontrivial: when we display a dialog, we already attempt to focus the first input. But the first input here is a tokenizer, not a real input, and naively focusing it fails because it hasn't activated or rendered yet.

Specifically, I've never used this workflow. So I don't see any obvious benefit to spending upstream time on it, and the task will sit here until others maybe chime in and we can get a sense of it's impact. This seems like an obvious request, but maybe tools like Nuance (help desk) make the workflow you use today, obsolete, so then we'd also not worry about implementing this at all.

We'll take a patch if you like, but if you're filing a feature request, you still need to follow Contributing Feature Requests and Describing Root Problems.

D17452 marks this as resolved and makes these changes:

A basic version of this is now available in HEAD of master. Here's a walkthrough of what we've implemented and a discussion of some areas where we'd like feedback.

Closing this since there doesn't seem to be any thing left that's actionable for us.

In T12174#213854, @chad wrote:

It's not hard to add, just curious what the use case is. Most requests have been to "rename" the applications (Differential -> Code Review"), so pulling in built-in tooltips didn't make sense. Maybe we should add tooltip to the "Link" menu type for best flexibility.

Thanks for the answer! I didn't expected to be in a different location.

In T11989#203781, @epriestley wrote:

Press F to pay respects.

I like the idea of a feed/panel that shows recently active objects and not the individual events, but I don't know that I have a specific use case for it now. For how I use feed I think being able to filter out commits would be a nifty plus, as those tend to pollute the feed during arc land activity (and comments in tow). I don't think I feel too strongly about it right now though, as most of my work is driven via email activity and I primarily use Feed as a means of discoverability so I can poke my head in if something sounds interesting~

Thanks for the information @epriestley.

thanks for the hint

Yeah everywhere I look at doing this seems exceedingly hacky. Writing a profile image the first time PhabricatorUser->getDefaultPictureURI doesn't seem right, but I don't seen any other lazy way of doing this outside of user creation.

Though I guess we need the icon typeahead there.

Alternatively, use "Link" and make whatever you want.

That's the default behavior, and you can achieve it by deleting "Name":

It would be nice if we could have tooltips for Apps, etc. too

I can confirm that advisory locking is acceptable. Locking the whole task is preferable, but we can live with comments not being locked. Thanks!

sure, I'm fine with letting the dust settle after these changes and deciding then. The edge.search approach would be totally fine since I'm writing a custom client, also, the attachment approach would work since our set of related tasks will be small for the foreseeable future.

You can set history.immutable to true in your repository to prevent arc from performing mutation operations (amends, squash-merges).

Not a bug.

I don't think there's any way to check for that via Herald. There's the Land Revision button( T182), which I ❤, but it's still a prototype and has some surprising behavior built into it (If you're doing anything complex, it can sometime land stuff you didn't want it to).

You can now add tooltips adhoc to "Link" menu items.

In T10319#213871, @epriestley wrote:

• Generate the image in the Query, not when the user is created (helps with old users and not having to update a ton of different ways users can get created, and not generating these as side effects during unit tests).

arc land mutates the code (adds details, squashes), so it's not possible. I'd recommend restricting who can land code and have the accepted reviewers manually land with "Land Revision" from the web ui. In general we expect people to trust co-workers, or use Audit for post-commit coverage.

We plan to let you bookmark / shortcut the fullscreen version of the workboard.

Thanks for the answer! I need to check all the configuration and get back to you if still doesn't work.

hhhmmm, not too many keyboard shortcuts ...
I used the full-screen option all day, but I think it's more time consuming... was better before when you hide it. In any case 99% of the time you look at the workboard.

(Going to close since this isn't a bug report. My mistake on reading the reproduction steps, @avivey has better eyes than I)

@avivey Thank you for the explanation!

In T10319#158305, @cburroughs wrote:

Yeah I think having some bin/profileimage script for pre-generation would be good for admins like here so you can pre-run the migration separate from enabling.

Yeah, I just want to find a way product side to always ensure good profile images are used. I'm fine having some fallback, if 100% needed, but it makes me really uncomfortable having different experiences or lessened experiences if avoidable.

(And, if our behavior is "confusing fatal", that could prevent new installs from getting far enough to even see the setup warning saying "install gd".)

I think all the other requirements are usually builtin (we "require" them only because it's possible to remove them, and some distros occasionally do for kind-of-maybe-questionable reasons) but I think it's basically like requiring your car to have tires.

Why not require GD outright? Seems like a drop in the bucket with all other requirements and leads to confusion later like with projects or macros

This runs into T5873, which is a large task. The very short version is:

I think the NUX case is fairly tricky. I need to look at the code, but I'm thinking something like:

Cool, sounds good.

Q. Common or rare?
A. Common - we'd lock all tasks before a release.
Q. Lock comments? Do you need to lock comments too, or just other types of edits (like status, priority, title, description, etc)?
A. I'm ambivalent about this, if the lock is mandatory then being able to add comments seems reasonable since someone can point out that the task needs to be unlocked for some reason or other.
Q. In particular, could a solution where anyone could unlock the task be acceptable, as long as they had to explicitly unlock it? Or is it a hard regulatory requirement that unlocking requires some sort of administrator/oversight step?
A. Unclear, I'll ask, but it's probably fine since there's also a 'process' that states how people use the system. (And you'd be surprised how much drama there is inside private companies:-) That is, our conventions are formally documented and people expected (and expect) to follow them.
Q. Lock other objects?
A. Possibly, but I've been pushing back on it for things like code reviews by arguing that 'everything is logged and there's an audit trail' so what does a lock by us? Obviously locking git doesn't really make sense and new comments can't hide old ones so I don't see what the problem is. For tasks, I don't feel I can make that argument since people will naturally just look at the current state of the task unlike code reviews where the history is 'in your face' as it were.