Hi Eva,

We do this on virtually every table. You are correct that want to look at the insertURL, updateURL, and tableURL properties. These let you specify an alternate page instead of the default one. Your point about duplicated code/work is a valid one. This may not be exactly the answer you want, but here's how we do it on our sites/modules. Note, these are LabKey extensions, not part of the core features.

- Most of the time we swap out the default LabKey pages for custom Ext4-based ones. This is mostly for cosmetic reasons. To use these all you'd need to do is swap out the URLs. For example, something roughly like "/query/manageRecord.view?schemaName=mySchema&queryName=myTable&keyField=rowId&key=${rowId}" would do it.

- However, would might want more customization. The pages above are based on Ext4 widgets that can create a details page or a form based on columns of a table. In other words you're not writing out the code for the form. Check out manageRecord.html for an example. If you want to slightly customized detail/update form, you could start with one of these classes on your custom HTML page, then extend it to split columns, hide fields, etc. This does require a custom HTML page, but the actual code you write per page should be very small. I could write more if you wanted to go this route.

3) If all you care of is showing/hiding columns, you might be able to do something simpler. This is probably the most common reason we would want to override a page. I *think* you can create a view named ~~INSERT~~, ~~UPDATE~~, or ~~DETAILS~~. When LabKey renders the default insert/update/details views, it should preferentially take the list of columns from the corresponding view when rendering that page. We only create these from file-based modules, but I think any view with this name (even if created through the UI) should override the auto-generated list of columns shown in the standard pages.