Change Details

The most common problems users run into in the Phacility instance UI are: # Creating mailing lists instead of actual users. # Confusion around "Administrator" vs "Instance Manager". # Difficulty managing cards and autopay. **Creating Users**: We show a big colorful warning on the page with instructions about how to do this right, but the default path where you just blindly click buttons does the wrong thing. {F5684446} To some degree, this behavior is "intentionally bad" to minimize how much hacky special casing we have to put into the upstream, but I think we need more hacky special casing than we currently have. Instead of hiding "Create Normal User", we should leave it visible and just redirect you to the `admin.phacility.com` interface when you click it, showing instructions if you don't have permission. The actual technical changes are: - Provide some kind of (minimally hacky?) way to hook this workflow to redirect instead of acting. A //minimal// version of this is probably just to intercept it in `SiteConfig`, but that feels unreasonably gross. - Remove `PhabricatorPeopleCreateGuidanceContext` and the "Guidance Engine" hook since we'll no longer need the banner. - Remove the "Can Create (non-bot) Users" permission? If we do this, we need another method to disable other mechanisms for creating user accounts (via invite, LDAP, etc). **Instance Managers**: Users have reasonable confusion about "Administrators" vs "Instance Managers", and the distinction between "can create image macros" and "can instruct us to permanently destroy all your data". It's also not inherently obvious that you need a high level of access to add/invite users, because it affects billing, although I think this is probably the right rule. Some small steps we could take are: - On the instance "Members" page, call out instance managers. - Provide an easier way to promote/demote users from that page. - Rewrite the documentation to point at this pathway instead of the Billing pathway. One advantage of this approach is that we could then send users a link directly to the dialog if they still have trouble, i.e. "click this link" instead of "read this documentation". **Cards and Autopay**: This is somewhat tricky in general because this stuff lives in Phortune, and Phortune is necessarily very general (supports multiple accounts, etc). Some small changes are: - Split "Billing / History" into "Payment Methods" and "Payment History". The only hint that "Payment Methods" is in this item is that the icon is a credit card. - Provide a "New Card" action directly from the "Payment Methods" section. - Provide direct "Remove Card" actions from the instance "Billing" page. - Provide direct "Make Autopay" actions from the instance "Billing" page. - Maybe move "Disable Instance" back to "Overview" to simplify this interface. - Maybe provide a direct list of instance managers on the instance "Billing" page? --- Additionally, we could reasonably: - Remove the "Upload Files" action, which is obsoleted by "Support", since all uploads are just drag-and-drop into support issue descriptions/comments now. - Clarify some of the language that uses "administrative" or similar to mean "Instance Manager". I'd also like to consider making this UI look more like the full-width modern Phortune UI again. Although the user-facing pages are generally in reasonable shape, some of the administrative interfaces like "Import Accounts" are in pretty rough shape. --- See PHI740. It's not obvious: (a) that the member list for support pacts is the same as the instance manager list; or (b) that you have to click the "Support" link from the instance detail page to get them to synchronize. Better would be to synchronize on-page with an explanation of the rule. --- See many user interactions with MFA. Currently, users can configure TOTP on both central accounts and instance accounts. Approximately 99% of users who configure central MFA appear to do so by accident and then require us to strip it. At least until T9515 (and perhaps far beyond that) it would be helpful to disable this ability, or at least put like five roadblocks on it. There is currently no way to selectively disable MFA types, but this is a reasonable ability to add, particularly since we'd presumably like to disable SMS by default (see T920) even once we build it. --- Currently, there's no link to the printable version of an invoice until an order completes. You should be able to print it either before completion (as an invoice) or afterwards (as a receipt).

The most common problems users run into in the Phacility instance UI are: # Creating mailing lists instead of actual users. # Confusion around "Administrator" vs "Instance Manager". # Difficulty managing cards and autopay. **Creating Users**: We show a big colorful warning on the page with instructions about how to do this right, but the default path where you just blindly click buttons does the wrong thing. {F5684446} To some degree, this behavior is "intentionally bad" to minimize how much hacky special casing we have to put into the upstream, but I think we need more hacky special casing than we currently have. Instead of hiding "Create Normal User", we should leave it visible and just redirect you to the `admin.phacility.com` interface when you click it, showing instructions if you don't have permission. The actual technical changes are: - Provide some kind of (minimally hacky?) way to hook this workflow to redirect instead of acting. A //minimal// version of this is probably just to intercept it in `SiteConfig`, but that feels unreasonably gross. - Remove `PhabricatorPeopleCreateGuidanceContext` and the "Guidance Engine" hook since we'll no longer need the banner. - Remove the "Can Create (non-bot) Users" permission? If we do this, we need another method to disable other mechanisms for creating user accounts (via invite, LDAP, etc). **Instance Managers**: Users have reasonable confusion about "Administrators" vs "Instance Managers", and the distinction between "can create image macros" and "can instruct us to permanently destroy all your data". It's also not inherently obvious that you need a high level of access to add/invite users, because it affects billing, although I think this is probably the right rule. Some small steps we could take are: - On the instance "Members" page, call out instance managers. - Provide an easier way to promote/demote users from that page. - Rewrite the documentation to point at this pathway instead of the Billing pathway. One advantage of this approach is that we could then send users a link directly to the dialog if they still have trouble, i.e. "click this link" instead of "read this documentation". **Cards and Autopay**: This is somewhat tricky in general because this stuff lives in Phortune, and Phortune is necessarily very general (supports multiple accounts, etc). Some small changes are: - Split "Billing / History" into "Payment Methods" and "Payment History". The only hint that "Payment Methods" is in this item is that the icon is a credit card. - Provide a "New Card" action directly from the "Payment Methods" section. - Provide direct "Remove Card" actions from the instance "Billing" page. - Provide direct "Make Autopay" actions from the instance "Billing" page. - Maybe move "Disable Instance" back to "Overview" to simplify this interface. - Maybe provide a direct list of instance managers on the instance "Billing" page? --- Additionally, we could reasonably: - Remove the "Upload Files" action, which is obsoleted by "Support", since all uploads are just drag-and-drop into support issue descriptions/comments now. - Clarify some of the language that uses "administrative" or similar to mean "Instance Manager". I'd also like to consider making this UI look more like the full-width modern Phortune UI again. Although the user-facing pages are generally in reasonable shape, some of the administrative interfaces like "Import Accounts" are in pretty rough shape. --- See PHI740. It's not obvious: (a) that the member list for support pacts is the same as the instance manager list; or (b) that you have to click the "Support" link from the instance detail page to get them to synchronize. Better would be to synchronize on-page with an explanation of the rule. --- See many user interactions with MFA. Currently, users can configure TOTP on both central accounts and instance accounts. Approximately 99% of users who configure central MFA appear to do so by accident and then require us to strip it. At least until T9515 (and perhaps far beyond that) it would be helpful to disable this ability, or at least put like five roadblocks on it. There is currently no way to selectively disable MFA types, but this is a reasonable ability to add, particularly since we'd presumably like to disable SMS by default (see T920) even once we build it. --- Currently, there's no link to the printable version of an invoice until an order completes. You should be able to print it either before completion (as an invoice) or afterwards (as a receipt). --- The recent policy changes mean that applying an `INSTANCE_STATUS` transaction requires `CAN_EDIT` permission, explicitly. Staff do not have `CAN_EDIT`, so we currently can not suspend instances through the web UI. The non-hacky way to fix this is to modularize instance transactions, then add a policy change similar to the change to the "Disable User" transaction.

The most common problems users run into in the Phacility instance UI are: # Creating mailing lists instead of actual users. # Confusion around "Administrator" vs "Instance Manager". # Difficulty managing cards and autopay. **Creating Users**: We show a big colorful warning on the page with instructions about how to do this right, but the default path where you just blindly click buttons does the wrong thing. {F5684446} To some degree, this behavior is "intentionally bad" to minimize how much hacky special casing we have to put into the upstream, but I think we need more hacky special casing than we currently have. Instead of hiding "Create Normal User", we should leave it visible and just redirect you to the `admin.phacility.com` interface when you click it, showing instructions if you don't have permission. The actual technical changes are: - Provide some kind of (minimally hacky?) way to hook this workflow to redirect instead of acting. A //minimal// version of this is probably just to intercept it in `SiteConfig`, but that feels unreasonably gross. - Remove `PhabricatorPeopleCreateGuidanceContext` and the "Guidance Engine" hook since we'll no longer need the banner. - Remove the "Can Create (non-bot) Users" permission? If we do this, we need another method to disable other mechanisms for creating user accounts (via invite, LDAP, etc). **Instance Managers**: Users have reasonable confusion about "Administrators" vs "Instance Managers", and the distinction between "can create image macros" and "can instruct us to permanently destroy all your data". It's also not inherently obvious that you need a high level of access to add/invite users, because it affects billing, although I think this is probably the right rule. Some small steps we could take are: - On the instance "Members" page, call out instance managers. - Provide an easier way to promote/demote users from that page. - Rewrite the documentation to point at this pathway instead of the Billing pathway. One advantage of this approach is that we could then send users a link directly to the dialog if they still have trouble, i.e. "click this link" instead of "read this documentation". **Cards and Autopay**: This is somewhat tricky in general because this stuff lives in Phortune, and Phortune is necessarily very general (supports multiple accounts, etc). Some small changes are: - Split "Billing / History" into "Payment Methods" and "Payment History". The only hint that "Payment Methods" is in this item is that the icon is a credit card. - Provide a "New Card" action directly from the "Payment Methods" section. - Provide direct "Remove Card" actions from the instance "Billing" page. - Provide direct "Make Autopay" actions from the instance "Billing" page. - Maybe move "Disable Instance" back to "Overview" to simplify this interface. - Maybe provide a direct list of instance managers on the instance "Billing" page? --- Additionally, we could reasonably: - Remove the "Upload Files" action, which is obsoleted by "Support", since all uploads are just drag-and-drop into support issue descriptions/comments now. - Clarify some of the language that uses "administrative" or similar to mean "Instance Manager". I'd also like to consider making this UI look more like the full-width modern Phortune UI again. Although the user-facing pages are generally in reasonable shape, some of the administrative interfaces like "Import Accounts" are in pretty rough shape. --- See PHI740. It's not obvious: (a) that the member list for support pacts is the same as the instance manager list; or (b) that you have to click the "Support" link from the instance detail page to get them to synchronize. Better would be to synchronize on-page with an explanation of the rule. --- See many user interactions with MFA. Currently, users can configure TOTP on both central accounts and instance accounts. Approximately 99% of users who configure central MFA appear to do so by accident and then require us to strip it. At least until T9515 (and perhaps far beyond that) it would be helpful to disable this ability, or at least put like five roadblocks on it. There is currently no way to selectively disable MFA types, but this is a reasonable ability to add, particularly since we'd presumably like to disable SMS by default (see T920) even once we build it. --- Currently, there's no link to the printable version of an invoice until an order completes. You should be able to print it either before completion (as an invoice) or afterwards (as a receipt). --- The recent policy changes mean that applying an `INSTANCE_STATUS` transaction requires `CAN_EDIT` permission, explicitly. Staff do not have `CAN_EDIT`, so we currently can not suspend instances through the web UI. The non-hacky way to fix this is to modularize instance transactions, then add a policy change similar to the change to the "Disable User" transaction.