calc element recalcs all rows using inline edit

p38

Active Member
setting "Only Calc on Save" on calc element (time element) does not work using inline edits, in other words, ALL rows are updated, instead of only the selected element.

Also I noticed that when saving the value, a blank is shown in the grid, but the value is saved.

Finally, the grid is not refreshed after saving, so row still remains visible, even though it fails the pre-filter, so it should disappear.

In summary it seems as tho the pre-filter is not being called AFTER the edit.


When I edit using the form, this works correctly.

Paul
 
Yup, I'm still looking at this. Can you just confirm that I'm reading your summary of the problem correctly, as I'm having issue replicating it, specifically what you mean by "ALL rows are updated". Can you give me an exact set of steps to take to replicate the issue.

On the second issue, I think for the moment, "it is what it is". Having the row removed when you save an inline edit if the new element value now means the row would have been pre-filtered is going to be distinctly non-trivial. I spoke to Rob about it, and our feeling is that for now, it's going to stay there until the list itself is next refreshed, and passes through our main getData() processing. It's something we may fix in the future, but it's a LOT of coding for a corner case situation.

-- hugh
 
I have set the element to "Only calc on Save". When I inline edit, and save the value, then ALL the rows elements are recalculated. This should not be, as only the element I have saved should be recalculated. you can replicate by using navicat (I also use and is brilliant) to change some rows calc values. Now inline edit an element,a nd you will see that all rows elements have been recalculated. It looks to me as if using inline edit, the elements do not adhere to the setting.

The second point also needs to be addressed, ie: when using an inline edit, and you save, then the cell value on the list is Blank, ie: disappears, and you need to refresh the list for it to show. The value is stored in the db, so it is a display thing.

Lastly, I would disagree about the "cormer case" situation, as this workings could affect the flow of a management process... for example.....

I prefilter a list of all outstanding tasks "table___completed = false". The user is shown this list, and must complete all tasks, by selecting a checkbox, ie: setting "table___completed = true". From the users perspective, this list will never be completed, unless he refreshes the list each time he completes a row?

To get around this, is there a way I can refresh the list AFTER an edit has been made?
 
Ah, OK, I see what you mean now. I misunderstood what you were saying, I thought you meant it was updating the database itself for all rows for the calc.

But as you say, it's re-calc'ing all rows on the fly after the edit.

Looking at that now.

Re the pre-filter thing. I don't necessarily disagree about the way it should work, what I'm saying is that we think it's going to be a lot of work to try and make it behave how you are expecting it to. And what I mean by "corner case" is that it doesn't affect very many people. And we have to prioritize work based on how many people it affects. Not many people use inline edit, and very few of those who do, would run in to this issue. Probably less than 1% of users might ever run in to this. So it's hard for us to justify the day of coding and testing it would probably take to achieve this, when we have more serious issues affecting 90% (or 100%) of our users that we need to get resolved.

-- hugh
 
Ah, it is updating in the table. And I see why.

OK, I think this goes back to a misunderstanding Rob has about what "calc on save only" means.

I'll catch him on Skype and discuss this one with him.

-- hugh
 
OK, I'm 99% sure I'm right on this one, so I went ahead and made the changes without tlaking to Rob, in this commit:

https://github.com/Fabrik/fabrik/commit/00a8e5945ea678341840c41b8f20a673e34e5a3d

... so we should now follow the 'calc on save only' setting when updating the list after an inline edit save.

rob - I've left the original code intact, commented out, and left a comment. I'll clean that up once you've had a chance to grok the change.

-- hugh
 
OK, on the 'cell doesn't update, is just empty' issue ... I can only replicate this if another element (i.e. not the one directly being edited) is failing validation.

For instance, my test list has a password element in it. So I uncovered a little bug whereby that password element will fail validation during inline edit, when I'm editing another element, because there is no "check" part of the element present in the inline edit data ... so the built in validation method for passwords was failing.

This causes the save of the inline edit to fail silently. No error msgs are returned or shown in the list, and the element being edited just goes blank.

I fixed that particular case, so the password element just validates if there is no 'check' data ... but we need to sort out why those cases are failing silently, with no feedback.

Rob? It's something to do with form model handleError(), which only returns error msgs in ajax mode for the elements in the plugin. But because the form still failed validation, it's banging out of process().

-- hugh
 
We are in need of some funding.
More details.

Thank you.

Members online

Back
Top