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
Compared to the recent integration method, tools that were integrated earlier have somewhat more convoluted read-only flag logic for input files. At the least, the UX can be adjusted to better reflect peculiarities of old-style integration: 1) either by making the said flag uneditable on configuration page when it does not affect the CBRAIN behaivor and/or 2) adding some fine print warning note.
Context:
Tools integrated using legacy methods (either hard-coded in Ruby or via old boot-time Boutiques integrator) often have a task class attribute :read_only_input. In the same time the tool config model also has a Boolean attribute inputs_readonly, rendered with label Does not modify its input files on a tool config page.
Current Behavior :
When :read_only_input_files is set to true, the CBRAIN tool configuration page field Does not modify its input files (represented by inputs_readonly) does not affect CBRAIN behavior. This behaviour is counter-intuitive, a CBRAIN admin might expect a config page field to have some effect.
Above does not affect much the newest scientific tools, because the new style integrator only sets the initial value of config's read-only attribute, and not the class attributed.
Proposed Workaround:
To mitigate this issue, an easy workaround could be to make the field Does not modify its input files read only on whenever a task class attribute if set to true. I think is fine to modify only config page and keep the config model as is.
Other consideration:
With an effort, it should be possible to correct the cbrain:read-only-input/read_only_input_files property is interpreted with legacy integration method, yet is could get clumsy.
Potential Separate Ticket:
Yet another flag, cbrain:alters-input-files is used only by old-style Boutiques integrator, yet has no effect on the new style integrator. Not sure that discrepancy deserve any effort, maybe it is enough to document the flag as deprecated by the new integrator.
The text was updated successfully, but these errors were encountered:
Uh oh!
There was an error while loading. Please reload this page.
Compared to the recent integration method, tools that were integrated earlier have somewhat more convoluted read-only flag logic for input files. At the least, the UX can be adjusted to better reflect peculiarities of old-style integration: 1) either by making the said flag uneditable on configuration page when it does not affect the CBRAIN behaivor and/or 2) adding some fine print warning note.
Context:
Tools integrated using legacy methods (either hard-coded in Ruby or via old boot-time Boutiques integrator) often have a task class attribute
:read_only_input. In the same time the tool config model also has a Boolean attributeinputs_readonly, rendered with labelDoes not modify its input fileson a tool config page.Current Behavior :
When
:read_only_input_filesis set totrue, the CBRAIN tool configuration page fieldDoes not modify its input files(represented byinputs_readonly) does not affect CBRAIN behavior. This behaviour is counter-intuitive, a CBRAIN admin might expect a config page field to have some effect.Above does not affect much the newest scientific tools, because the new style integrator only sets the initial value of config's read-only attribute, and not the class attributed.
Proposed Workaround:
To mitigate this issue, an easy workaround could be to make the field
Does not modify its input filesread only on whenever a task class attribute if set to true. I think is fine to modify only config page and keep the config model as is.Other consideration:
With an effort, it should be possible to correct the
cbrain:read-only-input/read_only_input_filesproperty is interpreted with legacy integration method, yet is could get clumsy.Potential Separate Ticket:
Yet another flag,
cbrain:alters-input-filesis used only by old-style Boutiques integrator, yet has no effect on the new style integrator. Not sure that discrepancy deserve any effort, maybe it is enough to document the flag as deprecated by the new integrator.The text was updated successfully, but these errors were encountered: