OSC / ondemand

Supercomputing. Seamlessly. Open, Interactive HPC Via the Web
https://openondemand.org/
MIT License
267 stars 100 forks source link

restrict what batch connect form items (and apps) are prefillable #2974

Open johrstrom opened 11 months ago

johrstrom commented 11 months ago

During #2958 the initial feature had it where you sites could specify what form fields are prefillable and indeed if the app itself is prefillable.

This ticket is to discuss such a feature and potentially implement it.

robinkar commented 11 months ago

Thought I would clarify a bit what our use cases for having forms optionally prefillable are. Two specific case where we would like to be able to disable the template would be for the Slurm reservation field and for a Jupyter for Courses app that we have. In all forms we have a dropdown with reservations that the user is able to use, and since the duration of reservations is usually short, the value that the user would select may change often. So if the reservation is saved as a part of the template, any time it expires, the user would have to save the template again, or select the correct reservation each time, compared to just reusing the reservation from the last launch (from app form cache). The Jupyter for Courses app is an app where we are trying to make it as simple as possible for the user to participate in courses, so we try to have as simple form as possible. Right now, the user would select the project (Slurm account) and the course "module", so adding additional fields ("Save as template" checkbox) that provide no benefit for the app is something we would like to avoid. In the future just having the course module as the only dropdown in the form is something we would like to have. Of course, this feature is not critical for us, and we are completely fine with not having the feature, but it is something that would be nice to have.

johrstrom commented 11 months ago

That's fine. We can implement this. It's opt-in it really doesn't affect anyone unless they choose it.

Really - I removed it from the other PR just to lessen the scope of that PR. Plus it was implemented weird (not as a issue with the implementer it just seems like we'd want some sort of map function for the session context or similar. I tried to rewrite it a bit and just thought let's defer the entire thing).

In any case - feel free to submit a PR for the same. Just some times in pull requests I want to have a small scope and defer other changes.

johrstrom commented 10 months ago

Thinking about this some more - we should probably just extend cacheable for this. It already applies to the whole form and individual items and is likely the same logical restriction - you don't want it saved/reused.

So instead of inventing a new config, we can just extend cacheable to this use case as well.