Skip to main content

Idea pipeline (top 25)

Filter by idea status

Filter by product

2004 Ideas

Option to allow selected row to move out of sight after refreshOpen

In a new barcode scanning screen we’re constantly adding items to a list by scanning many barcodes in a barcode view. This barcode view receives updates at every scanned item which results in an insert statement to a table via an instead of update trigger on the view. The effect is that every action with the barcode scanner results in a new item in the list. New items are added from the top of the list.The problem is that as soon as the selected row reaches the bottom of the grid it stops going further down at consecutive scans. New items are still added but they aren’t visible without scrolling up. Because we want to minimize mouse actions during the scanning process to maintain workflow this effectively keeps new items invisible.This issue was already described in https://community.thinkwisesoftware.com/questions-conversations-78/barcode-input-2822 where an animated gif illustrating the issue can be found as well.The solution I would like to propose is an option in subjects to allow for a selected row to appear outside the view of the grid after a refresh. With that option enabled the selected row would effectively keep moving down in our case and new items would keep appearing at the top of the grid.Please note that I tried a process flow to move the row selection to the top after every refresh. This is not an option here as it moves the cursor away from the form in the barcode scanning tab. Scan actions need to be possible without workflow interruption and with minimal user action in the end-product.

Ability to stash branch changesOpen

New idea in consultation with Dave, written by Mark Jongeling:I would like to be able to stash any changes I made to a branch similar to how Git does it: Git - git-stash Documentation (git-scm.com)One way of achiving this is an additional option in the Revert branch task with which I can indicate that I want to revert my branch to a point in time, and that the current state of the branch is stored, or Stashed; for example as a new branch. This new branch is in essence a copy of my branch with all the changes, then after that branch is created, reverting my original branch to the indicated point in time. That will leave me with two branches; the original one which is reverted and the stashed one which has all of the changes I originally made.At a later time, I can then merge the stashed branch into my original branch, effectively applying my changes again.  Old idea:Long story short, I'd like to be able to set the origin model version during the creation of a merge sesion.Casus:Let's say I have a branch A. I've made some development during the period X->Y. Let's say I want to park my changes by creating a branch B and reverting branch A to timestamp X.Then, when I eventually want to merge branch B into A, the merge session wrongly assumes that all my changes are deleted in branch A, because branch A is relatively in the past to branch B. So we want to have both model A and B to have a same base origin model version for the merge. That way, the merge sees the delta actions for branch B as additions from B->A instead of A->B.