[Feature] Function to show notification/toast and prompting dialogs in scripts

jooleeanh commented 6 years ago

App Details:

Postman for Mac
Version 5.5.0 (5.5.0)
OS X 10.12.6

Notification/Toast

Situation: I have some code that updates an environment variable (a user token) during the test script in some of my requests, and this happens without the postman user knowing (unless they already know or look at the test script).

It would be useful to have a function that shows a notification/toast in the app's UI, such as the one when there's an error in the script: The parameters would be: function showToast([String] message, [Number] duration, [Enum] color) {}

Prompt dialog

Situation: I have some environments that represent a production environment, and some requests (PUT/POST/DELETE) can be dangerous to execute on them. Since the selected environment is not always obvious (if we're going back and forth between postman and other applications), it's possible to send calls that we wish we didn't.

It would be nice to have a function that prompts the user (in this situation, used in the pre-request script) with a message, OK and Cancel choice. This would need a resulting callback along with another function to properly cancel a request.

The function could look like: function prompt([String] message) {}

numaanashraf commented 6 years ago

Thanks for the suggestion @jooleeanh.

sanderhouttekier commented 6 years ago

I see even more use for the prompt not only as a 'ok' 'cancel' situation but also a prompt for a specific 'value'.

use-case: in a REST api you usually work with an entity more than 1 call at a time. We often create an entity (f.e. User). while running it's tests, we 'set' it's ID in an environment variable. when you later request a single user you can request it by it's created ID. However if you open the collection to manually testrun the result of a single user, you have not set the environment variable. Thus in a pre-request script you could test if the environment has that variable and otherwise prompt for it.

bt-dd commented 6 years ago

@saelfaer - we ran into this exact same issue. The solution came up with was to throw an error object, which Postman will print the message for. -

if (!pm.environment.get("some_variable")) { throw new Error("Some Variable Not Set"); }

jooleeanh commented 3 years ago

Any update on this ? Felt the need again on another project.

maxsommer commented 3 years ago

I would really appreciate this kind of functionality, especially if it gave us the option to actually prompt for a value, since this would make building Postman API collections really interactive.

Throwing errors is just a rather non-elegant workaround to the user experience this could enable.

I'd suggest to implement a more flexible interface for this functionality:

// Just the OK button style prompt
// @param message text to display to the user 
function prompt(message: string): void

// Prompt asking user for an input
// @param message text to display to the user
// @param options.inputType which input type to display to user, restrict to most simple options for starters
// @param options.inputLabel string to display directly above the input field
function prompt<T =  string|number|boolean>(message: string, options: { inputType: 'text'|'number'|'boolean', inputLabel: string }): T

Use case for me: Request needs multiple path variables from Postman globals. Pre-request I want to check pm.globals for all necessary path variables so that they are not empty string or undefined and request input from the user for this global if it does not contain a value yet. This way other developers working with the Postman collections could have an easy way to make fully functional calls to my APIs on the first try, without searching all places the variables could pop up (path, query params, headers, body).

cristian-pirnog commented 3 years ago

Another use case: we're sending the same HTTP request to different stages (dev, acceptance, production). The URL and other properties for the different stages are configured via environment variables. I would like to add a prompt to the pre-request script that warns before sending the request to production, in order to make sure that one doesn't do this by mistake.

PsyOhm23 commented 1 year ago

Is there a chance to see this feature released in 2023 ? Hope you will soon :) Thx

giridharvc7 commented 1 year ago

Is this purely notifying the user of something like a warning or info? Console right now is the best place to log this, but I'm guessing its lack of indication/affordance once an important msg is logged is the reason why you are looking for a toast.

Also, Toast is a bit tricky, as it might lead to a very bad user experience if over used.

PsyOhm23 commented 1 year ago

Thx for you answer

I have booleans in my global environments to switch to some configurations or not (mock mode, intranet mode...)

I would like to be notified if one of these configurations are activated to warn me that I'm not in the base configuration.

mwaarna-tgm commented 9 months ago

+1 for this feature request. would be nice to be able to trigger popups before or after a script execution.

Throwing an error for incorrect environment is great, but not for informational details.

kovdmm commented 9 months ago

+1 for this feature request!

vedkribhu commented 9 months ago

@kovdmm it will help us solutionize better if you can mention your usecase as well?

@mwaarna-tgm can you elaborate on "Throwing an error for incorrect environment is great, but not for informational details". What details did you wanted to highlight in your usecase?

mwaarna-tgm commented 9 months ago

@mwaarna-tgm can you elaborate on "Throwing an error for incorrect environment is great, but not for informational details". What details did you wanted to highlight in your usecase?

Essentially would love a notification for warnings / success calls. Currently we use console.log, but not everyone has it open to keep watch on it. Something along this Vue JS notifcation that we could call from the tests: http://vue-notification.yev.io/

combility commented 9 months ago

Similar to kovdmm

Three environments
Common requests re-used across different environments via the Environment drop box in upper right hand corner.
Dev / Test Env, request away, POST, PATCH, no problem.
But if they chose Prod, there's potential to do damage depending on the Request.
Secure teams and access levels and all that, yes, but accidents can happen.

In user story format:

As a System Product owner, I don't want my Developers updating my Production data due to fat fingers or not understanding the nature of the request, so the RBAC my System relies on for security is not compromised, resulting in destructed data.

Mindful Toast on Production select or pre-request script could cause undue friction.

Alternate approaches could include:

a. Relate Postman IDE/DOM background colour to an Environment value. Admins enter their desired Environments and chosen Background colours, fully custom. Then on change Environment, background colour change, in your face; fore-armed is fore-warned approach. Other thick clients have this type of configuration; you log in, you see Red: think "Hey, don't put production data here, you're in the Test environment" etc etc.

b. Lock Writable methods to Roles (or some equiv Postman security construct) So POST, PUT, PATCH and DELETE execution request could perhaps be limited to a select group (or anyone by default) Then by Environment perhaps even. (POST OK in Development for Role X, but not POST in Production) So sure they could see the request (so discoverability not compromised), not be limited to adding new writable requests (so collaboration is cool), but at the point of executing them in a given Environment; that gets determined by their Role.