Closed luxaritas closed 1 year ago
On further reflection, if the main use case is bulk submission of a large set of sequences, should the defaults be user intervention required? Like details = prompt
and notifyOnError: true
. I guess the argument would be that by default, we want to surface issues to the user, and put the onus on the script author to appropriately call the API in a bulk submission situation.
Yes, exactly - it's trivial for the author to use the correct parameters, but incorrectly-used defaults could lead to unintuitive behavior. In the case of details
, they most likely would need to specify it anyways (this default just makes it work more reasonably if they don't), and I could forsee it being entirely possible that in the bulk submission case it may be desirable for either notifyOnError
or validate
to be enabled with the other disabled (but enabling both is "safe", and I'm not going to pretend to know which permutation would be desirable anyways)
Summary
This provides script authors (eg, for the mutation/submission booster) a convenient and reliable way to submit solutions (without manually constructing a POST request, which is awkward and could result in incorrect validation or missing information (eg, the undoblock with the custom target not being included)
Implementation Notes
false
. This allows for script authors to handle these situations differently ("this errored" vs "the user was prompted and opted to bail" are semantically different)validate
. If false, the validation steps that are user-bypassable (eg, "this constraint hasnt been satisfied") will be skipped. The other is "notifyOnError". If false, the promise will be immediately resolved with false instead of prompting if validate is true and validation fails, and also avoids surfacing informational dialogs that would normally occur if an error is returned from the backend (eg, for an in-use barcode). I have defaulted both of these to true, as that makes it less likely to result in undesired behavior if the options are not fully understood by the author (and is less likely to create confusion for the end-user).Testing
Tested a variety of combinations of successful and unsuccessful submissions from the UI and via the Eternascript function (with various combinations of parameters)
Related Issues
Related discussion in https://forum.eternagame.org/t/is-there-a-working-bulk-submission-script/4552/