Home      FAQ      Forum      Idea Exchange      Ask a Question      My Stuff      Help   
Inline Record Edit
Take a look at Invoicing application:

Item records are simple: a product (a name and a price are lookups), a quantity and a discount. Navigating to separate page to enter just three values and going back might be annoying for users.

Our proposition is to add an extra option to table views to enable "inline" edit. Then, clicking on Edit button changes grid values to in-place editors, replacing row actions with just "Save" and "Cancel".

View's "New" button will add blank row to the end of the table, otherwise the process is identical to "Edit".

Of course to enable record creation you need to ensure the view displays all columns marked as required that have no default values (no surprise as this requirement applies for regular forms as well).
User Experience

Kirill Bondar  Staff 
Date Created
11/22/2011 7:42:26 AM
Date Updated
3/14/2017 9:49:03 PM
Related articles
Promoted By
beoDave EllisDaniel Vazquez Ger
Dale OliverFabio CardilloDesmond Beatty
Ton JenseEdu HUjeremy nelson
Grant SimmonsShem SargentAlexander Sepe
Philipp Matuschkagerardo garciaThat Computer Guy
Gii SystemsRick CogleyMartin Odendaal
basenineBen FatchenScott Miller
Kirill Bondar  Staff 
Kirill Bondar  Staff  11/22/2011 5:45:41 PM
Unlike Grid Edit here we expect no functionality limitations comparing to forms - rendering single row as editable is practically rendering the form using another layout.
Rick Cogley 11/23/2011 2:19:27 AM
The slower pace of editing, in this style, as opposed to the grid edit style, would actually be welcome, I think. I imagine users would want to be able to jump to the full editing form, in some cases, and so some button or way of getting there would be needed...
gerardo garcia 11/23/2011 1:56:16 PM
Together with BUTTONS and INLINE EDIT I would solve most of my needs, without grid edit. The NEW button would still be required to work as before (open whole form in new edit windows), and have another NEW button inline adding a blank row. Thanks.
Ton Jense 3/12/2012 5:19:21 AM
Would it be possible to set Inline Editting of rows in the grid as the default in stead of using the form, for example in the definition of the RELATIONSHIP?
Desmond Beatty 3/13/2012 4:09:33 PM
I look forward to seeing this soonest. Remember this was up at a score of 350+ before being split into new ideas.
Kirill Bondar  Staff  4/17/2012 10:32:27 AM
We are steadily progressing toward completion. Saving, cancelling, basic column format validation and validation rules are all working. Visit our Facebook page for a screenshot from development server.

Shem Sargent 4/17/2012 10:36:31 AM
Looks great! I would like to implement this in my current application in development.
basenine 4/17/2012 6:31:18 PM
That Computer Guy 4/24/2012 7:37:38 AM
wooohooo !
Kirill Bondar  Staff  4/24/2012 7:44:07 AM
So, here it is, now in Labs.
Martin Odendaal 4/24/2012 7:58:26 AM
Works Well! Thank You!
Kirill Bondar  Staff  4/24/2012 8:18:49 AM
If you enable it in labs you'll be presented with extra option in Allowed Actions property of Table views: Allow Inline. Checking it will invoke inline editing for New and Edit buttons.

The feature is working in vast majority of cases. Dynamic recalculations and validation rules are supported.

Though there are couple of limitations.

* Simultaneous editing conflicts are reported but there is no other way to resolve them but cancel edit.

* The view should contain all columns necessary to add new record - that is all required columns with no defaults and columns critical for passing validation rules.

* To speed up the process all recalculations are scoped to the row the user edits. Because of that:

** New rows are always added to the end of the table and remain there after save.
** Edited rows remain in their original place even if they should be placed somewhere else because of their values and grouping and sorting in effect.
** Initially, empty table does not display multi-row custom buttons. When you "inline-add" new record to an empty table the buttons do not appear. Perhaps we can solve this but rendering multi-row buttons in disabled state even for empty tables.
** At the moment we do check whether edited record passes access rights and if not, we are removing it from the view. However we do not check if it passes view's filter. This may change in the future.
Shem Sargent 4/24/2012 9:11:51 AM
I like it very much too. Thank you very much for implementing this.
Rick Cogley 4/24/2012 9:13:28 AM
Ah wow, this works great, Kirill. Thanks!
Martin Odendaal 4/24/2012 9:23:57 AM
Is there a future plan to deal with File Attachments?
Ben Fatchen 4/24/2012 9:26:17 AM
Awesome! You have nailed it again! Thanks Teamdesk!!
Kirill Bondar  Staff  4/24/2012 9:35:44 AM

With AJAX calls we are performing we do not have access to file system - therefore we can not read and upload selected file from disk.

Upcoming HTML5 File API would allow to do that. Even if it is in draft stage at the moment Firefox and Chrome added support for it, but in our case most of customers use IE. Support for File API is expected in IE10. Once they release more or less stable version we'll think of implementation.
Dave Ellis 4/24/2012 2:13:58 PM
Great Feature. I did find on (I think) issue. In the Form used for 'full editing', I have a column marked as read-only. However, when I 'inline edit' this column is editable. I would not expect it to be. If a column is read-only for full editing, I would want it read-only for inline editing as well.

Kirill Bondar  Staff  4/24/2012 5:43:51 PM
@Dave: Inline editing has nothing to do with form layout - you can remove column from the form but still have it in the table view for example. Though you can use form behaviors to specify visibility/editability of the elements for both forms and inline-editable views.

I guess confusion comes from multiple concepts we are currently supporting. Your apps use old form layout where you can specify whether form element is readonly or required - this was initial concept. Then we have introduced form behaviors to allow dynamically change the state of the form elements based on conditions. Finally in New form layout form concept was overhauled: we dropped support for form assignments, multiple forms and specification of read only/required flags for form elements. All of these can be done via form behaviors.

Dale Oliver 4/25/2012 4:05:19 AM
Excellent feature! However would be great if one could edit reference columns, or select data when creating a new record from a reference column (data stored in another table).

Scott Miller 4/25/2012 4:08:26 AM
I have only briefly investigated this option and it looks good but if I need to edit a line item because the form contains a large number of editable columns I have to View and then Edit. This is a two step process whereas before it was one? I might have missed something but if not this is somewhat of a pain.
Kirill Bondar  Staff  4/25/2012 6:00:29 AM
@Scott: Inline mode allows to edit every column listed in the view (if they are not readonly). You can either create a view to list every column you have in the form, or use inline edit for quick changes and View+Edit to have access to record in full. I guess having two edit buttons (one for inline and one for "normal" edit via the form) will simply confuse the users.

Anyway, Inline Edit is a per-view setting - it's up to you to decide where you want to enable inline editing.
Kirill Bondar  Staff  4/25/2012 6:52:19 AM
@Dale: Usually views display a lookup column for the presentation of selected record. Obviously, lookups are not editable. So far you need to explicitly include reference column in the view to allow record selection in edit mode. But this will lead to displaying often meaningless reference code in a view mode.

Basically we have enough information to substitute reference column with selected record's information obtained via lookup. We are even doing it right now in a New form layout. Doing the same for views, however, may lead to compatibility problems, so we are evaluating safe path.
Scott Miller 4/27/2012 1:55:56 AM
Hi Kirill it will be good to see this implemented as key editable columns are quite often lookups.
Kirill Bondar  Staff  4/27/2012 5:16:28 AM
@Scott: In most cases the key column is an auto-number with no prefixes in it. For such a majority of cases we can safely replace the value of the key in reference column with corresponding lookup on display. Yet, some applications use formatted code for keys and perhaps the code has some meaning to the users - in this case we can not blindly replace values.

To our opinion, we should incorporate key->reference->value-to-display logic behind the reference column as we did this for new form layout. Yet, as new form layout was created as a separate fork to opt-in, there we had a little care about compatibility and tried to address all these problems at once. With views, changes are not so radical to deserve yet another fork. So we could either enable new logic for inline-editable views (simple) or convert views to include reference column while keeping them visually identical to old presentation (more complex)
basenine 5/1/2012 3:29:12 AM
With Records related to a Table - eg as above: Items related to an Invoice - the Invoice wont refresh when an Item is altered. I created a "Refresh" button to do this but it would be a nice inbuilt feature. The trouble with creating my own button is that there is nothing to let me know that it needs to be updated. If there was a calculation that TD could do to only show the "Refresh" button when needed, that'd be good.

Kirill Bondar  Staff  5/3/2012 5:17:01 PM
@Brett: To refresh typical master-detail page, e.g. to render the page in full, we have to query master record and number of record sets, one for each detail view on screen. That is what happened when after you press Save button in a standard Edit process. In contrast, main advantage of inline editing facility is it's narrow scope, namely one row. We query the data for the single row once you press Edit, and again, re-query the same row after you press Save or Cancel. That's all. And it is fast.

As I mentioned above, at the moment this scope is too narrow - it does not include recalculation of totals/subtotals and other dependent values such as summary columns in a master part of the form on screen. And we hope to address this problems in subsequent releases.

basenine 5/3/2012 6:11:40 PM
Hi Kirill,

Thanks for the explanation - makes sense.
I'll keep my mock "Refresh" button as it flags the user to do so if necessary.

Kirill Bondar  Staff  5/17/2012 1:18:27 PM
Today we've issued an update to address lookup/reference edit problem.

The relationship has a name property. Setting this property creates a "proxy" lookup, usually named as table + "Name".

With today's update, when the "proxy" lookup is in the view and reference column is not, we are creating record picker for the lookup in inline edit mode.
Kirill Bondar  Staff  5/29/2012 6:59:51 AM
Graduated from labs
Jennifer Shore 5/2/2013 3:26:27 PM
How do I set some of the columns to prevent editing in in-line edit mode but still allow them when creating a new record with that same info?
basenine 5/2/2013 6:07:38 PM
Probably the easiest way would be to create a Formula Text Column that you hide in the Form but display in the InLine Edit view. The formula will simply be the column that you can edit i.e.

[Editable Column] goes in the the Formula section of the Formula Column. This way, if you ever need to change the data in the editable column, it will reflect in the inline edit view.

@Slava - here's an example of where the Alternative Label is useful too ;). You'd clearly want to show the Column as being the same in the view but you can't. The work around at the moment is to call the columns [Column1] and formula column is [Column1.]

basenine 5/2/2013 10:35:22 PM
There are other alternatives with checkboxes or timestamps in conjunction with dynamic forms too.
Bin Xia Zhang 3/14/2017 9:49:03 PM
Any news regarding file attachments on Inline Edit?
Back to Search Results