We have a requirement wherein we have a table component which has a drop down field. This field has values (ex. a,b,c,d,e). The requirement is whenever a person selects any of the values in the drop down that value should not be available for him to use again in the table componenent.
So in this case if the first time 'a' is slected then for the second row and subsequent rows 'a' should not be available for selection in the table component.
You can achieve this by writing a Validation which always looks for field value based out of storage within field which is part of Table Component.
You can store information of the user selecting table component either on the request form or on table component itself, then you can use the SYS.USER_ID to map it with the records existing in the table component on either storage table.
Well there are about 12 other fields in the table component and the drop down that I m talking about has got about 35 different values. The criteria here is not restricting the number of rows in the table component but having one - one mapping between the rows and the values selected in the field.
May be we can achive this using Two different validations: Validation A as list validation which will store all the values in KNTA_LOOKUPS table. Validation A should have a Default value say "Not Needed" or something.
Then we can use a second(B) Auto comptle field validation for the fields. Second validation(B) should query three different tables. knta_lookups for all available values AND kcrt_table_entries & knta_parameter_set_fields for the values that are alreay saved for Table Component field. Make sure to ignore the Defult value with query like kcrt_table_entries.parameter4 != 'Not Needed'. Then you can query for the values that are present in knta_lookups but not in kcrt_table_entries for that Parameter.
I think that should probably work for you. Check it out and let us know.
That s what I thought that we may not do this on the fly but your suggestion on the error message is a great idea and then probably having an execution step which will not allow the request to move ahead untill the changes are made would be a kind of work around.