Is Input() Out for Add Row Actions?

[RedVox]

I'm pretty sure this worked for me in the past, but at the moment, I cannot seem to be able to make a "Data: add a new row to another table using values from this row" action that will use Input() to prompt the user for some column values.   The calculations are accepted, but the rows get added with the default values without any user prompt.  What's up with that?

[RedVox]

Okay, I poked around and noticed that input is now generally available - but in a very different implementation than the two-year beta version was.  And while it's not really clearly stated one way or another, it seems that input does not work with add row actions.  

[TeeSee1]

The 'useful' scenarios of INPUT() are quite limited unfortunately. Dynamic user inputs are allowed only when rows of the current table are updated.

[RedVox]

Seems like a very strange limitation for this feature. The work needed to circumvent this limitation and stay within the app when adding child rows to a selection of master rows is nasty.  

[Landan_QREW]

What is the benefit of an INPUT in adding a new row vs. LINKTOFORM()? I think it would be the same number of clicks.

[RedVox]

I want the user to be able to select multiple members then add similar child records for each of the members selected.  So for example, 20 different members all worked on a project and should have child WORK records added to their history.  Each work record will have identical fields for everything but the related_member_id.  If you can explain how linking to a form would help with this, please do.  

[Landan_QREW]

You may consider adding some columns in the parent table to apply to each child record. For example, you could add a column for hours worked and if you are generating 5 child records, you could apply the input for that column to each of the child records.

[RedVox]

Yes, I was considering that.  I don't really like needing to add a bunch of new columns to do this, but it's an option.  I was starting to wonder whether I could save a json blob in a single column and parse it out later, but I guess there's not that much to be gained and json parsing doesn't seem to be a thing, so perhaps I will begrudgingly add the eight or so columns to my main table to handle this.  Yuck.  

[Landan_QREW]

You could alternatively have a static user variable table that would essentially function the same, but would not bulk up your parent table with unnecessary columns. You could set the variables with an INPUT action and an action on a set of rows.

I mentioned this in another thread here.