Appian Community and Appian Academy are being upgraded. As a part of the upgrade, Appian Community is currently in read-only mode, and user registration is disabled until August 3. We apologize for any inconvenience this may cause, but a more secure, stable, and performant Community experience is coming soon!
The new Appian Community launches August 3, followed by Appian Academy on August 7. During the migration, Appian Community Edition, Appian Academy, Documentation, Certifications, Instructor-led Customer Training, Partner Sales Training & Accreditation, and Forum (for Appian Partners and Customers only) will remain available.
More frustrations (adding to the pile) in switching over to RecordType style data, and/or supporting other people who use it as is my particular case...
I happened to notice the other day, if you save "fv!selectedRows" into any sort of variable, from a!gridField() when using RecordType data, it does NOT (seemingly(?)) work as expected.
The important use case: I want a grid to select rows, edit the selected data, then save that back to the DB. Obviously if my entire row isn't captured into the save target, this causes extra hurdles I must watch out for before writing back to the DB, lest I accidentally overwrite some columns with blank values.Note: this might be an easy hurdle for me or other mid/senior designers to overcome - but i'm trying to coach a newer designer through selecting rows on a grid to update specific fields then write that back, and roadblocks like this can be complete derailments in these scenarios.
So, hive mind, what's the consensus here? Is this intended functionality, where the details just aren't documented? Is it a bug? Are most folks still avoiding this functionality, and therefore nobody noticed this yet either way?
Discussion posts and replies are publicly visible
Hm ... I mean I saw some documentation saying that record data support partials updates. So, you should be fine with changing the data as shown in the grid. If the grid is more a reference, then the old way of doing this should work.
Interesting behaviour ... need to spent some time on it.
Unknown said:then the old way of doing this should work.
one old way of doing it (not necessarily the way i'd implement it, but still a *working* way) would be to pass fv!selectedRows into a local variable or rule input (mirroring the entire contents of that row), update the neccessary fields on-form, then push the updated row to the DB via WTDS / WTDS node. Under that assumption, plus the details i'm referencing in this post, that particular old way no longer works here, without further workarounds.
I typically just collect the selected IDs and then re-query data as needed. Not sure what the new best practice will be ...
Unknown said:I typically just collect the selected IDs and then re-query data as needed.
Same here. But of course in that approach you don't use fv!selectedRows at all (which i also usually don't bother with), but this sorta negates/sidesteps the very promise and alleged usefulness of fv!selectedRows.
On that note I'm struggling to figure out why someone would ever even want to use the new recordType data constructs to capture then push data updates, because there are still seemingly so many cumbersome hurdles still in the way.
Agreed. Records is almost there but needs a few more versions.