DocumentCaptureTask object method · N/task
addInboundDependency()
DocumentCaptureTask.addInboundDependency(options)
Adds a scheduled script task to the document capture task as a dependent task.
- Implementation
- Not started
- Design
- Open for proposals suggest how it should read
A
suitescript api
1objDocumentCaptureTask.addInboundDependency({2 scriptId: /* string, required */,3 taskType: /* string, required */,4 deploymentId: /* string, optional */,5 params: /* Object, optional */6});
| Parameter | Type | Required | Description |
|---|---|---|---|
| options.scriptId | string | required | The script ID of the scheduled script record for the dependent task. |
| options.taskType | string | required | The type of dependent task. This property uses the task.TaskType.SCHEDULED_SCRIPT value in the task.TaskType enum. |
| options.deploymentId | string | optional | The script ID of the script deployment record for the dependent task. To use this property, the scheduled script for the dependent task must be deployed. If you do not specify a value for this property, an available deployment is selected automatically. |
| options.params | Object | optional | The parameters for the scheduled script. To use this property, you must first create script parameters that are required for the dependent task. For example, if your dependent task requires a reference to the JSON result file, you must create a script parameter that maps the JSON result file ID to the file name, as in the following example: { 'custscript_docCapture_res' : 'resultFile.json' } For more information about script parameters, see Creating Script Parameters (Custom Fields) . |
B
mynt syntax
No Mynt syntax yet.
Nothing in the language compiles to DocumentCaptureTask.addInboundDependency(options) today. How should it read?
C
community proposals
Competing syntax for addInboundDependency, from GitHub Discussions. Select two or more to compare them side by side.
Loading proposals from GitHub…
D
suggest an alternative
Write the Mynt you wish you could write.
A good proposal shows the syntax, the SuiteScript it should become, and argues for it: why it is clearer, how it fits the rest of the language, what it makes harder.
- Clarity. Does it say what happens, without ceremony?
- Consistency. Does it read like
load,saveandRef[field]? - Expressiveness. Does it cover the cases people actually write?
- Honesty. Does it hide a NetSuite cost, such as governance, that a reader should see?