BUG: MS Teams Webhook notification has incorrect obfuscation

[znicholasbrown]

First check

• [X] I added a descriptive title to this issue.
• [X] I used the GitHub search to find a similar issue and didn't find it.
• [X] I refreshed the page and this issue still occurred.
• [X] I checked if this issue was specific to the browser I was using by testing with a different browser.

Bug summary

The webhook input uses type="password" to obfuscate the value, despite it being visible just below

Reproduction

Create a new MS Teams webhook notification

Error

Browers

• [X] Chrome
• [X] Firefox
• [X] Safari
• [X] Edge

Prefect version

2.4.3

Additional context

N/A

[pleek91]

@znicholasbrown I don't think this is a ui issue. The schema from the api is what's causing this to be treated like a password.

{
  "type": "string",
  "title": "Webhook URL",
  "format": "password",
  "example": "https://your-org.webhook.office.com/webhookb2/XXX/IncomingWebhook/YYY/ZZZ",
  "writeOnly": true,
  "description": "The Teams incoming webhook URL used to send notifications."
}

[zanieb]

Webhook URLs are secret though right? Isn't the issue here that it's being displayed below?

[marichka-offen]

@znicholasbrown @pleek91 the screenshot for the issue is made on create notification page, that's why we can see the hook I assume, so we can validate one last time it is correct. On the general notifications dashboard, it's starred. I just want to confirm we want it hidden on create notification page as well

[marichka-offen]

Also, when we go back to edit, it is starred as well. So the only time you see it, is when creating notification

[znicholasbrown]

I think the issue here is that the field probably doesn't need to be obfuscated as a user types since that makes it difficult to identify and correct mistakes; I think it's ok if the final value is obfuscated when being displayed but not the input one. As @pleek91 mentioned though, I don't think this is a UI issue per se, unless we want to make a blanket rule that password input types are visible when interacting with the input field and obfuscated otherwise. Either way I think this is low priority