module function · N/search
createFilter()
search.createFilter(options)
Creates a new search filter as a search.Filter object.
- Implementation
- Not started
- Design
- Open for proposals suggest how it should read
A
suitescript api
1search.createFilter({2 name: /* string, required */,3 join: /* string, optional */,4 operator: /* string, required */,5 values: /* string | Date | number | boolean | string[] | Date[] | number[], optional */,6 formula: /* string, optional */,7 summary: /* string, optional */8});| Parameter | Type | Required | Description |
|---|---|---|---|
| options.name | string | required | Name or internal ID of the search field. |
| options.join | string | optional | Join ID for the search filter. |
| options.operator | string | required | Operator used for the search filter. Use the search.Operator enum. |
| options.values | string | Date | number | boolean | string[] | Date[] | number[] | optional | Values to be used as filter parameters. |
| options.formula | string | optional | Formula used by the search filter. |
| options.summary | string | optional | Summary type for the search filter. See search.Summary . |
B
mynt syntax
No Mynt syntax yet.
Nothing in the language compiles to search.createFilter(options) today. How should it read?
C
community proposals
Competing syntax for createFilter, 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?