You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
there's a new field "options" that needs added and it's contents plugged into the params property of ReflectometryReductionOneAuto
The interface needs to be expanded to support this. The options column should come after the groups column.
The overrides should be expressed as key-value pairs. The key value paris should reflect the options in ReflectometryReductionOneAuto. It would be best to dynamically populate the allowed keys list based on the available ReflectometryReductionOneAuto property names, for example:
StartOverlap=0.1, EndOverlap=0.2
. '''Ensure we have unit tests to thoroughly verify this new behaviour''' We don't want to fully run the algorithm for each scenario, this would take too long, but we do need unit tests to ensure that Options are always set on the algorithm post init() and prior to execute(). The last thing we want is users complaining about some obscure scenario, where they can't overload options, I suggest introducing a new class for this, which would make the behaviour testable, and could be used within the presenter.
The text was updated successfully, but these errors were encountered:
Original Reporter: Keith Brown
This ticket is blocked by :
This ticket is blocks :
TRAC9368,TRAC10301there's a new field "options" that needs added and it's contents plugged into the params property of ReflectometryReductionOneAuto
The interface needs to be expanded to support this. The options column should come after the groups column.
The overrides should be expressed as key-value pairs. The key value paris should reflect the options in ReflectometryReductionOneAuto. It would be best to dynamically populate the allowed keys list based on the available ReflectometryReductionOneAuto property names, for example:
. '''Ensure we have unit tests to thoroughly verify this new behaviour''' We don't want to fully run the algorithm for each scenario, this would take too long, but we do need unit tests to ensure that Options are always set on the algorithm post init() and prior to execute(). The last thing we want is users complaining about some obscure scenario, where they can't overload options, I suggest introducing a new class for this, which would make the behaviour testable, and could be used within the presenter.
The text was updated successfully, but these errors were encountered: