Wish List

What inspired this wish list request?  We are currently performing various tasks using our own JMP Add-in. However, it has become increasingly difficult to respond to JMP’s annual version upgrades. Depending on the user environment, the upgraded features are often not actively used in practice, yet the version change itself can create compatibility issues that disrupt our workflows. For example, when a user updates to the latest version while the Add-in is optimized for an older version, unexpected errors or functional limitations may occur. This creates a situation where maintaining operational stability becomes challenging.   What is the improvement you would like to see?  We would like JMP to support downloading or installing at least two previous versions of the software, not only the latest one. This would allow users who rely on custom Add-ins or stable workflows to operate in an environment that best fits their needs. Providing access to multiple past versions—similar to other software platforms that allow users to choose their preferred stable version—would greatly reduce the burden of adjusting Add-ins and scripts every year.   Why is this idea important?  This improvement would minimize operational disruptions, reduce version-specific maintenance work, and allow teams to ensure stability when using custom Add-ins. It would also give users the flexibility to choose the version that best supports their actual use cases, rather than being forced into every annual upgrade. Overall, it significantly enhances ease of use and provides practical value for organizations with complex or long-running JMP workflows.   ...その他を表示

☐ cool new feature ☑ could help all Jmp users! ☑ removes something that feels like a „bug“ ☐ nice to have ☐ nobody needs it   What inspired this wish list request?  In Jmp18, a warning message appears for EVERY user - EVERY day - EVERY time Jmp is started  ... unfortunately: already months before Jmp expires. Unlike a splash window, the pop-up window remains in place until the user closes it manually.   This is how it looks like:   What is the improvement you would like to see?  Please - remove the warning message [either: completely, or: after 3 seconds] - just show the warning message 1 - 2 x before it gets disabled [automatically] or: - add an option to disable the warning message (like for the startup splash window).   Why is this idea important?  less confusion for JMP users no annoyed license site managers   other wishes from    TS-00143027   ...その他を表示

What inspired this wish list request? Using a number of JSL scripts, I slowly am automating more of them so they can run without me. New authentication in JMP 18+ makes this more difficult.     What is the improvement you would like to see? A way to authenticate/use/something JMP in a manner it can be called from a schedule and not be impacted (or be predicatably impacted?) by authentication failures.     Why is this idea important? More and more I have created JSL scripts that are pretty stand alone in what they are able to automate. As a result, I find myself scheduling these scripts to run using windows scheduler. However, I encounter failures for "no traceable reason" that generally have been related to JMPs desire to re-authenticate. That window halts operation until a user intervenes, which isn't very possible since the user isn't actually the one 'clicking buttons' I use JMP on a mixture of my laptop as well as several networked desktops. Overall the authentication isn't an issue, and, in fact, has been a much better user experience for when you use multiple computers. That being said, automated script running throws a wrench in the system since it's unclear when authentication will need to take place. This is also the case for use cases where cloud systems may be desirable (eg AWS EC2) since you can't automate that system if a user needs to authenticate. I'm not sure if the windows scheduler / cloud system would have a similar solution, but I think it would be great if JMP could figure out a way to allow these kind of background uses. Or a better start might be a timeout with some logging that a batch file or something could key into for better failure logging - "Process failed due to need to reauthenticate"     ...その他を表示

What inspired this wish list request?  My programs are unable to use the license model used by JMP Pro 18.  We are unable to provide user identifiable information, such as e-mail addresses, required to make accounts of our users.  It is a security risk we are not able to abide.  In addition the requirement of each user moving over their own license individual is untenable in a controlled offline environment.   What is the improvement you would like to see?  An offline license deployment option that allows for the local environment to manage the users and is deployed by system administrators.  Ideally a named-user floating license.  This has been done with other software on a license management server, where user names (associated with AD accounts) are listed in configuration files, defining who has access to the software.  This also alleviates the association of users with specific machines, which does come up in environments with users sharing PCs or using multiple machines.   Why is this idea important?  If this option is not available before the end of life for the JMP Pro 17 license, we will need to drop our usage of JMP and find another tool.  This is a deal breaker that will require us to move on from your tool.   Will gladly discuss this directly with PMs on both a technical and managerial level.   ...その他を表示

What inspired this wish list request?  from JMP v18 it is required to provide authorized code for each user for registering to the site. In Applied materials we have more than 50 servers which do not have access to internet. due to which we can't authorize multiple users logging into that machine.     What is the improvement you would like to see?      Why is this idea important? This Idea is important because we need to reduce the multiple authorizaton codes for single machine and get it done quickly.    ...その他を表示

It would be great if in future you could enable SSO and SCIM provisioning via IDP (e.g. Entra). Linking licensing and authentication to a security group would be efficient and time saving. At present, users logging in with username and password poses a minor concern when offboarding employees, as we would have to check JMP each time to ensure the leaver doesn't have a license. ...その他を表示

My coworker's JMP Pro license expired. Our IT department got thoroughly confused by an old license file that looked new. The JMP Pro features went away, my coworker freaked. IT eventually called me in after using up all their other options. And the coworker's menu Renew License option was greyed out.   Please put renew license() into the Help>Scripting Index. I knew the option existed, but could not remember the syntax. And my search of the Scripting Index for "license" came up completely empty. I turned to google, which took too long.   ...その他を表示