Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Notes can only have certain fields and have a specific format. Some of these fields are the same as other objects and some are specific to the Note object.
This is a unique value that identifies the Note. The id
of a Note is generated automatically. It is a random 10 character long string that can contain any of the following values:
Notes contain a number
field that is associated to the first Invitation that is used to create the Note. The number
value is added automatically and it is usually used to give a number id to submissions.
The Creation Date or cdate
is a unix timestamp in milliseconds that can be set either in the past or in the future. It usually represents when the Note was created.
The True Creation Date or tcdate
indicates the date in unix timestamp in milliseconds when the Note is created. Unlike the cdate
, its value cannot be set or modified by the user and it is not displayed in the UI.
The Modification Date or mdate
shows when the Note was last modified. The mdate
value is a unix timestamp in milliseconds that can be set either in the past or in the future.
The True Modification Date or tmdate
indicates the date in unix timestamp in milliseconds when the Note is modified. Unlike the mdate
, its value cannot be set or modified by the user and it is not displayed in the UI.
The Online Date or odate
is used to show when the Note first becomes public. The odate
value is a unix timestamp in milliseconds that can be set either in the past or in the future.
The Publication Date or pdate
is used to show when the Note that represents a submission is marked as Accepted. The pdate
value is a unix timestamp in milliseconds that can be set either in the past or in the future.
The Deletion Date or ddate
is used to soft delete an Note. This means that Notes with a ddate
value can be restored but will appear as deleted. The ddate
value is a unix timestamp in milliseconds that can be set either in the past or in the future.
The invitations
field contains all the Invitations that were used to create the Note through the process of inference.
The domain
is a string that groups all the entities of a venue. Its value is set automatically and cannot be modified.
The signatures
field indicates who created the Note. Even though the field is an array of strings, only one item can be present in the signatures
field. Users can sign with different ids depending on their permissions.
The readers
field is an array with Group ids that indicates who can retrieve the Note or see the Note in the UI.
The nonreaders
field is an array with Group ids that indicates who cannot retrieve the Note or see the Note in the UI. This field is useful in case we want to use a group id in the readers
field that contains a member that we want to exclude from the readers
. In this case, we can specify the Group id of that user in the nonreaders
field.
The writers
field is an array with Group ids that indicates who can modify the Note.
The forum
field contains a Note id. When the Note id
field is equal to the forum
field, it indicates that the Note is a submission. Otherwise, it means that the Note is a comment to the submission. In other words, the forum
value indicates the forum the Note belongs to.
The replyto
contains a Note id. This field indicates what Note it is replying to. In other words, Notes that contain this field are comments in a forum.
The content
field is a JSON that can contain any field that is specified in the Invitation. The fields in content
can only contain alphanumeric characters, underscores, and hyphens and they can have a max length of 80 characters. The UI will display by default the value of the field after replacing the underscore characters with spaces and uppercasing the first letter of every word in the field. However, the UI can be instructed to render a different text for each field by defining a string inside param/fieldName
in the Invitation.
The fields inside content must contain a value field and optionally a readers field. For example:
Everyone can query this Note and see that the value of title
is "Title". However, only members of "OpenReview.net/2023/Conference" will be able to see the value of venueid
.
The same principle applies to any content
field of any object at any level.
Edges are used to represent matching data, like affinity scores, conflicts, custom quotas, etc. The Edge entity contains two main properties: head
and tail
and optionally a label
and weight
. Head
and tail
properties point to other entities in the system like a note, a group or a profile.
Notes can only have certain fields and have a specific format. Some of these fields are the same as other objects and some are specific to the Note object.
This is a unique value that identifies the Edge. The id
of an Edge is generated automatically. It is a random 14 character long string that can contain any of the following values:
The Creation Date or cdate
is a unix timestamp in milliseconds that can be set either in the past or in the future. It usually represents when the Edge was created.
The True Creation Date or tcdate
indicates the date in unix timestamp in milliseconds when the Edge is created. Unlike the cdate
, its value cannot be set or modified by the user and it is not displayed in the UI.
The Modification Date or mdate
shows when the Edge was last modified. The mdate
value is a unix timestamp in milliseconds that can be set either in the past or in the future.
The True Modification Date or tmdate
indicates the date in unix timestamp in milliseconds when the Edge is modified. Unlike the mdate
, its value cannot be set or modified by the user and it is not displayed in the UI.
The Deletion Date or ddate
is used to soft delete an Edge. This means that Edges with a ddate
value can be restored but will appear as deleted. The ddate
value is a unix timestamp in milliseconds that can be set either in the past or in the future.
The signatures
field indicates who created the Edge. Even though the field is an array of strings, only one item can be present in the signatures
field. Users can sign with different ids depending on their permissions.
The readers
field is an array with Group ids that indicates who can retrieve the Edge or see the Edge in the UI.
The nonreaders
field is an array with Group ids that indicates who cannot retrieve the Edge or see the Edge in the UI. This field is useful in case we want to use a group id in the readers
field that contains a member that we want to exclude from the readers
. In this case, we can specify the Group id of that user in the nonreaders
field.
The writers
field is an array with Group ids that indicates who can modify the Edge.
The head
field can contain a Note id or a Group id and connects it to the Note id or Group id defined in the tail
field. This field is always mandatory and cannot be empty.
The tail
field can contain a Note id or a Group id and connects it to the Note id or Group id defined in the head
field. This field is always mandatory and cannot be empty.
The label
field contains a string that gives extra information to the Edge. This information can be used to classify Edges and differentiate them from other Edges that have the same Invitation, tail and head values.
The weight
field contains a number that defines the weight between two entities defined in head
and tail
.
The invitation
field contains the Invitation id that was used as template to create the Edge.
The tauthor
field contains the identity of the user that created the Edge. This property is only present when the user is writer of the Edge.
Invitations can only have certain fields and have a specific format. Some of these fields are the same as other objects and some are specific to the Invitation object.
This is a unique value that identifies the Invitation. Its value, which will always contain the string /-/
determines the parent group it belongs to as well as the value that is displayed when creating buttons in the UI. For example, the Invitation id OpenReview.net/Venue_Organizers/-/Submission
belongs to the group OpenReview.net/Venue_Organizers
and the button displayed in the UI will have the Submission
value.
Invitations can be used to create many objects. If you want to restrict the amount of objects created you can set a maxReplies
integer value. If this value is not present, then any amount of objects can be created using the Invitation.
Invitations are sometimes used for tasks. Until the integer value minReplies
is met by creating object replying to the Invitation, the task will still be marked as pending. The minReplies
parameter is only used by the UI.
The Creation Date or cdate
is used to activate an Invitation. The value of a cdate
is a unix timestamp in milliseconds that can be set either in the past or in the future. If the cdate
is set in the future, the Invitation cannot be used until the date set is reached.
The True Creation Date or tcdate
indicates the date in unix timestamp in milliseconds when the Invitation is created. Unlike the cdate
, its value cannot be set or modified by the user and it is not displayed in the UI.
The Modification Date or mdate
shows when the Invitation was last modified. The value of a mdate
is a unix timestamp in milliseconds that can be set either in the past or in the future.
The True Modification Date or tmdate
indicates the date in unix timestamp in milliseconds when the Invitation is modified. Unlike the mdate
, its value cannot be set or modified by the user and it is not displayed in the UI.
The Expiration Date or expdate
is used to set an expiration date for an Invitation. Once the expiration date is reached, users will not be able to use the Invitation to create new objects, unless the user is a writer of the Invitation. The value of a expdate
is a unix timestamp in milliseconds that can be set either in the past or in the future.
The Due Date or duedate
is used to set an expiration date for an Invitation in the UI. Its value can be different from the expdate
and it is never used to validate if the Invitation can still be used. This property is useful to give users during a deadline room when there are network issues due to heavy traffic. Therefore, the duedate
is usually set with a value less than the expdate
. The value of a duedate
is a unix timestamp in milliseconds that can be set either in the past or in the future.
The Deletion Date or ddate
is used to soft delete an Invitation. This means that Invitations with a ddate
value can be restored but will appear as deleted. The value of a ddate
is a unix timestamp in milliseconds that can be set either in the past or in the future.
The invitations
field contains all the Invitations that were used to create the Invitation through the process of inference.
The domain
is a string that groups all the entities of a venue. Its value is set automatically and cannot be modified.
The signatures
field indicates who created the Invitation. Even though the field is an array of strings, only one item can be present in the signatures
field. Users can sign with different ids depending on their permissions.
The readers
field is an array with Group ids that indicates who can retrieve the Invitation or see the Invitation in the UI.
The nonreaders
field is an array with Group ids that indicates who cannot retrieve the Invitation or see the Invitation in the UI. This field is useful in case we want to use a group id in the readers
field that contains a member that we want to exclude from the readers
. In this case, we can specify the Group id of that user in the nonreaders
field.
The writers
field is an array with Group ids that indicates who can modify the Invitation.
The invitees
field is an array with Group ids that indicates who can use the Invitation to create an object. A user can be a reader of an Invitation but not an invitee.
The noninvitees
field is an array with Group ids that indicates who cannot use the Invitation. This field is useful in case we want to use a group id in the invitees
field that contains a member that we want to exclude from the invitees
. In this case, we can specify the Group id of that user in the noninvitees
field.
The preprocess
field contains a string with custom javascript or python code that can be used to add extra validation before an object is created.
The process
field contains a string with custom javascript or python code that runs after an object is created. This process runs asynchronously and can be used to send emails, for example. Process functions can be executed right after an object is created or with a delay after the object is created.
The dateprocesses
field is an array containing different dates and delays. It can be used to run a specific task after an object is created, on a particular date, or as a cronjob.
The web
field contains javascript code that runs when the Invitation is loaded in the UI. If the field web
is not present, a default UI is shown for the Invitation.
TODO
The edit
field is a JSON that contains the rules and structure for any edit
that is created using this Invitation. Edits can be for Groups, Notes, and Invitations.
The edge
field is a JSON that contains the rules and structure for any edge
that is created using this Invitation.
The tag
field is a JSON that contains the rules and structure for any tag
that is created using this Invitation.
The content
field is a JSON that can contain any field with any name defined by the user. Please refer to the Speficiers subsection for more information on how to define the field values.
The content
field has arbitrary fields that can be named as anything with some restrictions. The fields can only contain alphanumeric characters, underscores, and hyphens and they can have a max length of 80 characters. The UI will display by default the value of the field after replacing the underscore characters with spaces and uppercasing the first letter of every word in the field. However, you can instruct the UI to render a different text for each field by defining a string inside param/fieldName
. The field fieldName
can be a string with a max length of 1000 characters and no restriction in terms of what characters can be used.
The fields inside content must contain a value field and optionally a readers field. For example:
Everyone can query this Note and see that the value of title
is "Title". However, only members of "OpenReview.net/2023/Conference" will be able to see the value of venueid
.
The same principle applies to any content
field of any object at any level.
The fields of an Invitation vary depending on the object that will be created with it. There are 6 different types of invitations:
Meta Invitations are admin Invitations which are created when the venue is deployed and are available to venue organizers. There is only 1 available per venue and should be used with care and sparingly. Meta Invitations can modify any object in the system that is associated to the venue. Therefore, before using the Meta Invitation, make sure there is no other Invitation that can be used instead. Using an Invitation other than the Meta Invitation is preferred to avoid errors when modifying an object.
There is only 1 available per venue and should be used with care and sparingly.
Meta Invitations can modify any object in the system that is associated to the venue.
Meta Invitations have the structure shown below. They can be identified because of the property edit: true
inside the invitation
field.
Edge Invitations are used to create Edges and contain the edge
field that defines the template for the Edges. This means that when creating an Edge object with the Invitation below, the rules and structure defined inside the edge
field will need to be followed.
Do NOT copy the values from this example in your venue. This example is a simplified version of an Edge Invitation and it is only used to understand its structure.
Tag Invitations are used to create Tags and contain the tag
field that defines the template for the Tags. This means that when creating a Tag object with the Invitation below, the rules defined and structure inside the tag
field will need to be followed.
Do NOT copy the values from this example in your venue. This example is a simplified version of a Tag Invitation and it is only used to understand its structure.
Group Edit Invitations are used to create Group Edits and contain the edit
field that defines the template for the Group Edits. This means that when creating a Group Edit object with the Invitation below, the rules and structure defined inside the edit
field will need to be followed.
Do NOT copy the values from this example in your venue. This example is a simplified version of a Group Edit Invitation and it is only used to understand its structure.
Note Edit Invitations are used to create Note Edits and contain the edit
field that defines the template for the Note Edits. This means that when creating a Note Edit object with the Invitation below, the rules and structure defined inside the edit
field will need to be followed.
Do NOT copy the values from this example in your venue. This example is a simplified version of a Note Edit Invitation and it is only used to understand its structure.
Invitation Edit Invitations are used to create Invitation Edits and contain the edit
field that defines the template for the Invitation Edits. This means that when creating an Invitation Edit object with the Invitation below, the rules and structure defined inside the edit
field will need to be followed.
Invitations that are used to create Invitation Edits are the most complex ones. Theoretically, they can have any depth, but you will probably hit restrictions if you try to create a very big Invitation.
Do NOT copy the values from this example in your venue. This example is a simplified version of an Invitation Edit Invitation and it is only used to understand its structure.
Edits are used to create Invitations, Groups and Notes. Therefore, there are three kinds of Edits: Invitation Edits, Group Edits and Note Edits. Once an Edit is created, it goes through the process of inference to create the corresponding entity. Consequently, Edits contain the history of changes of the entity that they create. Adding, removing or modifying an existing Edit will change the resulting entity.
Edits can only have certain fields and have a specific format. Some of these fields are the same as other objects and some are specific to the Edit object.
This is a unique value that identifies the Edit. The id
of an Edit is generated automatically. It is a random 10 character long string that can contain any of the following values:
The Creation Date or cdate
is a unix timestamp in milliseconds that can be set either in the past or in the future. It usually represents when the Edit was created.
The True Creation Date or tcdate
indicates the date in unix timestamp in milliseconds when the Edit is created. Unlike the cdate
, its value cannot be set or modified by the user and it is not displayed in the UI.
The Modification Date or mdate
shows when the Edit was last modified. The mdate
value is a unix timestamp in milliseconds that can be set either in the past or in the future.
The True Modification Date or tmdate
indicates the date in unix timestamp in milliseconds when the Edit is modified. Unlike the mdate
, its value cannot be set or modified by the user and it is not displayed in the UI.
The Deletion Date or ddate
is used to soft delete an Edit. This means that Edits with a ddate
value can be restored but will appear as deleted. The ddate
value is a unix timestamp in milliseconds that can be set either in the past or in the future.
The invitation
field contains the Invitation id used to create or modify the Edit.
The domain
is a string that groups all the entities of a venue. Its value is set automatically and cannot be modified.
The signatures
field indicates who created the Edit. Even though the field is an array of strings, only one item can be present in the signatures
field. Users can sign with different ids depending on their permissions.
The readers
field is an array with Group ids that indicates who can retrieve the Edit or see the Edit in the UI.
The nonreaders
field is an array with Group ids that indicates who cannot retrieve the Edit or see the Edit in the UI. This field is useful in case we want to use a group id in the readers
field that contains a member that we want to exclude from the readers
. In this case, we can specify the Group id of that user in the nonreaders
field.
The writers
field is an array with Group ids that indicates who can modify the Edit.
The content
field has arbitrary fields that can be named as anything with some restrictions. The fields can only contain alphanumeric characters, underscores, and hyphens and they can have a max length of 80 characters.
The fields inside content must contain a value field and optionally a readers field. For example:
In the example above, readers of the Edit will see that the value of title
is "Title". However, only members of "OpenReview.net/2023/Conference" will be able to see the value of venueid
.
The tauthor
field contains the identity of the user that created the Edge. This property is only present when the user is writer of the Edge.
The invitations
field contains the Invitation id used to create or modify the Edit. Even though the name of the field is in plural, the field contains a string. This is to avoid name collision with the invitation
field.
The invitation
field contains the Invitation id used to create or modify the Edit.
The invitation
field contains the Invitation id used to create or modify the Edit.
There are two types of specifiers: Validation Specifiers and Representation Specifiers.
Both specifiers are defined inside the param field. The Representation Specifiers define how the requested data will be rendered in the UI.
Validation Specifiers define valid values that can be assigned to the fields of the objects (Edits, Edges, Tags) that will be created using the Invitation. Most Validation Specifiers outside content do not require a type
field since its type can be inferred from the field name. For instance, the readers field will always be of type group[]
. However, other Validation Specifiers need to be defined for the readers field, such as regex.
Only the mandatory fields head and tail in an Edge must specify the field type even though they are not inside a content field.
Validation Specifiers inside the content
field will always require a type
. This is because content
can have any field name and its valid values need to be specified so that the UI can render them and the backend validate them.
In most cases, you can only have one Validation Specifier. The only exceptions are value range specifiers, such as minimum
, maximum
, minLength
and maxLength
.
There is no restriction on the amount of Representation Specifiers.
The param
should have one of the following specifiers needed to validate the expected value.
Whenever param
is present, the user is expected to input a value for that field. Otherwise, the value is considered to be a constant and the user cannot change it.
const
: restricts the value of the field to whatever it's written in const. When const
is present, the user does not need to pass the value, since it will be assigned by the Invitation. In the example below, the title value has to be exactly "This is a title".
It is preferred to use the following shorthand whenever possible, which is the same as the example above:
Fields that are specified as constants in the Invitation do NOT need to be passed when creating an object (Note Edit, Invitation Edit, Group Edit, Tag, or Edge).
enum
: valid values must be listed in the enum array. The values in enum
must be of the same type and should match the type specified in the field type. When the type of enum
is string its values can be regexes too. In the example below "This is a title" and "This issss b regex" are valid values for title.
regex
: valid values need to match the specified regex. The type of the field should be string. In the example below, "This asdf title" is a valid value.
range
: valid values are within the range [a, b] which means a <= value <= b. The type of the field must be float or integer. In the example below, the values 0, 3, and 10 are valid.
withInvitation
: valid values are IDs of entities that have as invitation the value specified in withInvitation
.
Suppose we have the following note (this is a simplified version of the note):
Given the example below, the value "or2022" would be valid.
withVenueid
: valid values are IDs of entities that have as venueid
the value specified in withVenueid
.
Suppose we have the following note (this is a simplified version of the note):
Given the example below, the value "or2023" would be valid.
withForum
: valid values are IDs of entities that have as forum the value specified in withForum
.
Suppose we have the following note (this is a simplified version of the note):
Given the example below, the value "com2024" would be valid.
inGroup
: valid values are group IDs that are members of the group ID specified in inGroup
.
Suppose we have the following group (this is a simplified version of the group):
Given the example below, the value "~Some_Reviewer1" would be valid.
minLength
: valid values are strings that have at least the length specified in minLength
. In the example below, the values "title" and "long title" are valid.
maxLength
: valid values are strings that have at most the length specified in maxLength
. In the example below, the values "title" and "abc" are valid.
maxSize
: specifies the maximum size that a file can have in megabytes. It must be used with type file. In the example below
extensions
: specifies the valid types with the extension of the file. The extensions cannot have dots, which means that files that have the extension tar.gz are not supported.
minimum
: valid values are numbers (floats or integers) that have at least the value specified in minimum
. In the example below, 1 and 6000 are valid values.
maximum
: valid values are numbers (floats or integers) that have at most the value specified in maximum
. In the example below, 20.5 and 16.7 are valid values.
type
: define the type value that field is going to have.
The field type
is mandatory in all the fields whose type cannot be determined by the name of the field. Note how in the example below the field invitation/edit/signatures defines param/regex without a type keyword. This is because we know the type of the field signatures
. We know is of type groups[]
, so there is no need to define it. On the other hand, the field invitation/edit/note/content/title/value
has to define the type since the fields inside content can be anything.
Allowed types:
string
integer
boolean
date
file
profile
group
note
The field types profile, group, and note ask for an ID, not the entire object.
Square brackets can be appended to each type to expect an array of values, for example:
Not all types can become arrays. The exceptions are date
and file
.
type
can be an optional property in some cases where it is known which type is expected, for example: readers
, writers
and signatures
of a note.
optional
: boolean value that indicates if the value is optional or mandatory.
deletable
: boolean value that indicates if the value can be deleted.
The fields optional and deletable can be used at the same time or omitted. Their behavior is defined below:
Representation specifiers are not used for validation, they are only used to correctly display the data in the UI. They are not mandatory and in case they are not present the UI will have default values for each field.
order
: define the order in which the field is going to be rendered in the form.
description
: short text to explain the expected value.
input
: type of widget to use when requesting data.
text
select
checkbox
textarea
radio
default
: value that is going to be shown when the widget is initialized.
markdown
: boolean value that enables the use of markdown.
scroll
: boolean value that specifies whether a textarea input will be scrollable.
The replacement
field is a boolean value that indicates whether the history of changes of the entity that is being edited should restart from the Edit that is being created or modified. In other words, if the value of replacement
is true, then, the previous Edits for that particular entity are ignored during .
The invitation
field contains the object that will be used during to create or modify the Invitation that will be saved to the database.
The group
field contains the Group object that will be used during to create or modify the Group that will be saved to the database.
The note
field contains the object that will be used during to create or modify the Note that will be saved to the database.
Optional | Deletable | Behavior |
---|
True | True | Field is optional and can be deleted |
True | False | Field can be added but not deleted |
False | True | Undefined |
False | False | Field is mandatory and cannot be deleted |
True | undefined | Field can be added but not deleted |
undefined | True | Field is optional and can be deleted |
undefined | undefined | Field is mandatory and cannot be deleted |
Notes are the main containers of data in OpenReview. Notes are used for submissions and comments such as reviews, meta reviews, decisions and public comments. They require an Invitation to be created and modified.
The process of inference combines Edits to create an entity before saving it to the database. In other words, entities such as Invitations, Groups or Notes cannot be created directly, they need to be created through Edits and the process of inference.
Edits are sorted in a fixed chronological order using the tcdate
field during inference. Since the tcdate
value can never be modified, Edits can never change their position in the history of changes. However, the history of changes can be modified by destructively changing an Edit. This is only possible if the user has writer permissions on the Edit.
The process of inference can add, remove and replace fields as long as the Invitation used to create the Edit allows it. To illustrate this, we will focus on inference used to create Notes, however, the same rules apply to Invitations and Groups.
For the following examples, assume that the following Invitation is used:
Suppose the following Note Edit is created:
Since this is the first an only Edit the resulting Note will only contain the fields and values inside the note
field of the Edit.
You may have noticed the fields id
, invitations
and domain
that were not included in the Edit but still appear after the inference runs. These fields are set automatically and cannot be manually modified. The invitations
field shows all the different Invitations that have contributed to the modification of the Note. The field domain
shows the venue that the Note belongs to and it is present in every single object created.
Let's say that we now want to add the field abstract to the Note. We can create a new Note Edit:
Notice that we now pass the field note.id
to the Edit. This indicates what Note we want to modify. The resulting Note will then contain the abstract
field:
Values can be overwritten by passing the same field with a new value. For example, if we want to update the abstract field that we just added, we can create the following Note Edit
The resulting Note will look like this:
In order to remove a field from a Note, we can pass the object { delete: true }
as value to the field.
The resulting Note will look like this:
The resulting Note will look exactly the same as the first Note that was created from the first Edit. The difference is that we can see the history of changes by querying the Edits associated to the Note.
Edits can be modified directly and alter the history of changes. This can achieved by passing the id
of the Edit that we want to modify like so:
The field replacement
can be used when we want to restart the history of changes. In other words, Edits created before the one that contains replacement: true
will be ignored during inference. The ignored Edits will still exist but will not be considered for the resulting values of the entity. Consider the following Edit:
The resulting Note looks like this:
As you can see, the Edit containing the replacement: true
is considered to be the first Edit during inference. If a subsequent Edit contains replacement: true
then that Edit will considered to be the first Edit and the previous Edits will be ignored.
Users can enter data into the system using an invitation. An invitation is roughly a template that indicates required and valid values that will be saved to the database. The invitation contains a list of fields that need to be completed by the user.
The subsections contain information on the types of Invitations, their structure, the fields it can have, and how to define them with different specifiers.
The dollar sign notation is used to copy values from one field whose path is specified inside the dollar sign notation to the one where the dollar sign notation was specified. The path defined in the field is a relative path and can only refer to fields that are passed when the object is posted or to fields that are generated by the backend before it gets saved to the database.
The dollar sign notation is a string has the following format:
Probably the most common and simple example is the one for signatures and Note number. Consider the following simplified Note Edit Invitation:
Then a valid Note Edit replying to this Invitation will look like this:
The final Edit that will be saved to the database after all values have been resolved will look like this:
There are 3 fields that contain the dollar sign notation and 4 values that need to be resolved. Let us start with the one inside edit/readers/1
. The value ${2/signatures}
means that it will go up twice and then select the value of edit/signatures
. Note that the value here is [ "~Test_User1" ]
. The array will replace the value where ${2/signatures}
would be located in the Note Edit and then flattened. In a similar way, the value inside edit/note/writers/1
will be resolved and flattened. The only difference is that the relative path is different, but they resolve to the same value.
The other example refers to the field number
. This field is not defined when the Note Edit is posted, because it is created by the backend. However, the field can be referred to when creating the Note Edit. The number
field is the only exception to the rule where all the field values that can be referred to with the dollar sign notation need to be present when the Note Edit is posted. As you can see, when the Note number value is resolved it replaces the value of the dollar sign with the number of the Note.
The dollar sign notation cannot refer to values that are at the root of the Invitation. This is because when an object is created, it only has access to its own fields, not to the fields of the Invitation that allows its creation.
According to the Note Edit Invitation there are only 2 fields that the user needs to fill up: signatures
and the value
of the title
because those are the only 2 fields with the param
keyword. The rest of the field values are populated by what is defined in the Invitation as constants. Refer to the subsection for more information.