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.

Thanks for the detailed reply.

Add catfacts tooltip to each application?

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.

In T12174#213852, @chad wrote:

That's expected. When you customize the name, the built-in data (name, tooltip) goes away.

That's expected. When you customize the name, the built-in data (name, tooltip) goes away.

I just noticed that that tooltips behave unexpectedly for application entries in the menu: When the application has no "Name", the default name is displayed as well as a tooltip on mouse-over. When I set a custom "Name", only that name is displayed and the tooltip is no longer displayed.

In my experience, it is very unusual for organizations to have multiple distinct internal groups with different identity providers. Normally, organizations which value SSO and identity management consolidate identities under a single provider, because that avoids problems like this, greatly simplifies identity management, and doesn't require other pieces of software to support multiple providers.

@epriestley : because it's easier to manage everything from a single instance of phabricator. Phabricator has native support for multiple authentication providers, so I don't see a problem with this.

Why are you sharing an instance between two separate groups with separate identity providers?

@epriestley : we need multiple authentication providers because this is a shared phabricator instance, and thus different groups of users need different IDP.

I have a few questions about this, and some ideas for how we could solve it:

It's the ? key on the keyboard. In only works when the focus isn't in any
text-box (If you're using a Mac, that might not be an option for you).

Earlier, I predicted:

Too bad.
Where is this "?" located? you mean the "?" key, or?
If it's "?" from the keyboard, then it's writing in the Search box.

In T4181#204679, @netroby wrote:

The real working example

[…]
ExecStart=/usr/bin/sudo -u vcs-user  /opt/phabricator/bin/phd start
ExecStop=/usr/bin/sudo -u vcs-user /opt/phabricator/bin/phd stop
[…]

That's the expected behavior - see https://secure.phabricator.com/book/phabricator/article/differential_faq/

Alternatively, you can use a test instance at Phacility to verify your reproduction steps against a current version.