(proposal) Move Journal editing into a discrete modal

[sfount]

Currently our posting journal allows you to edit transactions in place. In transaction view you can click edit in a transaction, it will be highlighted blue with a number of editing functions (save, add line, remove line etc.) presented at the top. All rows in a transaction are downloaded whatever the data set to ensure you are not editing without context.

The reason for this decision is to allow the user to watch the totals of their current query (journal data) change as they edit.

However there are many UX issues with the current implementation, if a user has filtered on any values, the filter will be removed scrolling the view unpredictably.

My proposal is that the edit button is removed from in line transaction and is instead placed as a function in the menu or the toolbar. The flow would be:

1. User selects one or more rows from a transaction
2. User selects 'Edit' from the menu
3. A modal is presented with all of the rows in that transaction in a UI grid, the experience for editing is the same as now. User can add, remove lines, save or cancel.
4. Once the user has saved they are returned to the exact same view they had before, with the underlying values updated

The same code for editing lines in a UI grid would be used however it would be a discrete action that happens aside from the main grid.

Pros

• No requirement on being in a certain view
• Far fewer corner cases with in line scrolling and downloading of data and custom editing / rendering (this constitutes thousands of lines in the journal code)
• discrete states, no ambiguous mode or rendering
• No concerns about current filters or queries

Cons

• This method would not be suited for editing many transactions at once. Editing would be limited to 1 transaction by 1.
• Significant development time transitioning system

Watching users use the current system with changes of filters and scrolling beyond their control it is clear that it would take a long time to master and also has some required fixes - potentially now is a good time to make a call on if we think the number of corner cases here is ever worth the convenience of in line editing.

Potentially this would also allow other modules like the account statement to request a transaction for editing. This might be a very convenient tool if you are using other modules to validate data.

[jniles]

I think that using a modal is a decent idea ... it would certainly make the editing process faster. Then the Journal would only need to be a view of the data, rather than a dynamic view.

Here is an (old) blog post by one of the UI-Grid maintainers demonstrating the same concept.

In my mind, the design questions are:

1. What columns are available to edit? Only the visible ones or every column? I can see pros and cons to either.
2. Can we just have a "click to edit" instead of a "select than click edit" button? It might make things faster.

It would be a hard transition though.