Page MenuHomePhorge

Remove mention of Phabricator in the Auth setup check
ClosedPublic

Authored by waldyrious on Aug 29 2023, 21:18.
Tags
None
Referenced Files
Unknown Object (File)
Wed, May 1, 17:01
Unknown Object (File)
Wed, May 1, 17:01
Unknown Object (File)
Wed, May 1, 17:01
Unknown Object (File)
Wed, May 1, 17:01
Unknown Object (File)
Wed, May 1, 17:01
Unknown Object (File)
Wed, May 1, 08:52
Unknown Object (File)
Thu, Apr 11, 06:51
Unknown Object (File)
Wed, Apr 10, 17:51

Details

Summary

The authentication setup check, available at <PHORGE_URL>/config/issue/auth.config-unlocked/,
contained a reference to Phabricator in the prompt of the command line hint to resolve the issue.
Similar checks only showed the prompt symbol, not the directory, so this one was changed to match.

Ref T15006

Test Plan
  • Run ./bin/auth unlock
  • Visit <PHORGE_URL>/config/issue/auth.config-unlocked/
  • Notice that, with this patch, "phabricator" no longer appears in the prompt prefix for the suggested fix command at the end of the page.

Diff Detail

Repository
rP Phorge
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

ooh, check out D25349 for basically this exact use-case...

Thanks for this patch. Yeah if I understand correctly, this should work:

hsprintf(
  '<tt>%s $</tt> ./bin/auth lock',
  PlatformSymbols::getPlatformServerPath())

And maybe in the future we can have a CSS selector to be applied just to the "phorge/" pathname, in order to avoid mouse selection, and select just the command. But now let's fix just this brand issue.

maybe in the future we can have a CSS selector to be applied just to the "phorge/" pathname, in order to avoid mouse selection, and select just the command.

Yeah, I would like to see that. One way to implement it is to produce the prompt character and directory prefix via CSS, as a pseudo-element (::before { content: 'foobar'; }), but it's also possible to wrap the prompt in an addressable element and apply user-select: none; to it. I personally prefer the former approach (it seems more semantically appropriate) but the latter is also valid.

src/applications/config/check/PhabricatorAuthSetupCheck.php
75

So, maybe just this, in order to have the minimal fix for the brand issue:

->addCommand(
  hsprintf(
    '<tt>%s $</tt> ./bin/auth lock',
    PlatformSymbols::getPlatformServerPath()));

Then we can do something else to have the server path non-selectable

src/applications/config/check/PhabricatorDatabaseSetupCheck.php
37–39 ↗(On Diff #1346)

Maybe we can restore this intentional indentation

Historically they liked all arguments in the same indentation :D

https://we.phorge.it/book/contrib/article/php_coding_standards/

src/applications/config/check/PhabricatorAuthSetupCheck.php
75

Then we can do something else to have the server path non-selectable

With this phrase I mean, later, with another patch, we can surely try to improve the <tt> tag to be non-selectable. But maybe not now. It's still useful to see where this command should be executed (so, from Arcanist, or from Phorge, etc.) so the prefix is probably still useful.

src/applications/config/check/PhabricatorAuthSetupCheck.php
75

So, maybe just this, in order to have the minimal fix for the brand issue:

I would normally agree, but this was (AFAICT) the only case of a path being shown before the prompt symbol in these check messages. So I think this change (removing "phabricator" altogether rather than just replacing it with getPlatformServerPath()) is justified because it aligns this code with all the other ones.

That's not to say I don't see the value of having the path here — but like the non-selectability bit, I think adding the path should be done in a separate patch and affecting all similar messages consistently.

src/applications/config/check/PhabricatorDatabaseSetupCheck.php
37–39 ↗(On Diff #1346)

Oh, ok, I can revert these changes. I can tell there are multiple instances of either indentation style so it's probably best to do these kinds of changes in bulk and via an automated process, rather than manually.

Revert indentation changes

So, we are here if I understand correctly:

  1. having the <tt>phorge/ $</tt> ./bin/auth lock (thanks to getPlatformServerPath())
    • waldyrious: 🔴 don't like since the "phorge" is alien confusing text that is selected automatically with a double-click by most browser webs
    • valerio: ✅ Pro: 100% backward compatible. Cons: I agree with waldyrious but I think we can create a CSS class for non-auto-selectable things later in the future. So 1. is good.
    • avivey: ✅ like
  2. having <tt>$</tt> ./bin/auth lock
    • waldyrious: ✅
    • valerio 🔴 I don't like since the prefix was added to have arcanist/phorge indication. So, if we use just $ it's better to remove it.

So the compromise:

  1. having just ./bin/auth lock without any silly prefix
    • valerio ✅ also this could be expanded in the future
    • waldyrious: ✅ (probably?)
    • avivey: probably 🤷

So we can maybe just propose a version n. 3 and then, later, do a follow-up change introducing:

->addCommandPrefix(getPlatformServerPath())

So that this will take care of the <tt> thing and making that non-selectable etc. Later.

the prefix was added to have arcanist/phorge indication. So, if we use just $ it's better to remove it.

Considering that all the other such messages have a plain $, I'm not sure this prefix addition did fulfill that goal. It currently introduces inconsistency with regards to the other similar messages, which have no path at all (and of course, it is an outdated reference); the inconsistency and the outdated reference is what this patch aims to address. That said, I'd be definitely in favor of a future patch adding the prefix to all messages, using getPlatformServerPath(). I'd be happy to prepare that one myself, even, right after this one.

So we can maybe just propose a version n. 3 and then, later, do a follow-up change

I get where you're coming from, and I do agree that it's the desirable ultimate state, but until the CSS-based prompt marker is implemented, I believe the hardcoded one offers a better experience since it's a common pattern used in many places to indicate a command to be run in a terminal. So I agree with removing the $, but I'd rather do that in the patch that introduces the CSS-based $, so that there's no regression in the information conveyed to the readers of these messages. And again, I'm happy to propose that patch myself, after this one is merged.

Ah! Thanks! I was not aware that it was a common practice:

$ grep -R '<tt>\$' .
./applications/uiexample/examples/PhabricatorSetupIssueUIExample.php:      ->addCommand(hsprintf('<tt>$</tt> %s', '$ ls -1 > /dev/null'))
./applications/config/check/PhabricatorDatabaseSetupCheck.php:            '<tt>$</tt> ./bin/config set mysql.host %s',
./applications/config/check/PhabricatorDatabaseSetupCheck.php:            '<tt>$</tt> ./bin/config set mysql.port %s',
./applications/config/check/PhabricatorDatabaseSetupCheck.php:        ->addCommand(hsprintf('<tt>$</tt> ./bin/storage upgrade'));
./applications/config/check/PhabricatorDatabaseSetupCheck.php:          hsprintf('<tt>$</tt> ./bin/storage upgrade'));
./applications/config/check/PhabricatorBaseURISetupCheck.php:          '<tt>$</tt> %s',
./applications/config/view/PhabricatorSetupIssueView.php:          '<tt>$</tt> ./bin/config set %s <em>value</em>',

Indeed this is the super-minimal lovely change to fix that. Thanks

This revision is now accepted and ready to land.Nov 9 2023, 06:15