| Summary: | next unique key number not generated by form when saving new data-populated record | ||
|---|---|---|---|
| Product: | [Applications] KEXI | Reporter: | Ian Balchin <inksi> |
| Component: | Forms | Assignee: | Jarosław Staniek <staniek> |
| Status: | CLOSED FIXED | ||
| Severity: | normal | CC: | adam, inksi, staniek |
| Priority: | NOR | ||
| Version: | 2.9.0 | ||
| Target Milestone: | 2.9.3 | ||
| Platform: | Mint (Ubuntu based) | ||
| OS: | Linux | ||
| Latest Commit: | http://commits.kde.org/calligra/71d7aaa3412e07a8ef4083167410d60833c854d6 | Version Fixed In: | 2.9.3 |
| Sentry Crash Report: | |||
|
Description
Ian Balchin
2015-03-16 11:10:09 UTC
In the penultimate line above: "Saving a freshly created empty unedited record will not generate the new key. various editing gymnastics are needed to enable this" add - neither will saving a freshly created record for which some fields have been completed" Working on this all day everyday at present my preferred method of handling this is to open a new record, type data into one field, Ctl+A, Ctl+X, Cancel Record Changes, Save Record, Ctl+V. This is the easiest workaround. Confirmed, thanks Ian! It looks like a regression. Wouldn't a possible workaround be like this: 1. Click the "Go to last record" button ">|" 2. Click the "Go to next record" button ">" 3. Enter the new record's data. 4. Click the Save button or if you want to enter another record afterwards, click the "Go to next record" button ">". Both approaches save the record, while the latter acts as a Save+"Go to a new empty record" combined action. BTW, using the Next button to when multiple records have to be added is perhaps a good habit _regardless_ of existence of the reported bug. Another note, the issue is common for table and form views. 75% done Jaroslaw
That works too. A good workaround.
Ian
On 2015-03-29 22:09, Jarosław Staniek wrote:
> https://bugs.kde.org/show_bug.cgi?id=345210
>
> Jarosław Staniek <staniek@kde.org> changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> Status|UNCONFIRMED |ASSIGNED
> CC| |staniek@kde.org
> Ever confirmed|0 |1
>
> --- Comment #2 from Jarosław Staniek <staniek@kde.org> ---
> Confirmed, thanks Ian! It looks like a regression.
>
> Wouldn't a possible workaround be like this:
> 1. Click the "Go to last record" button ">|"
> 2. Click the "Go to next record" button ">"
> 3. Enter the new record's data.
> 4. Click the Save button or if you want to enter another record
> afterwards,
> click the "Go to next record" button ">". Both approaches save the
> record,
> while the latter acts as a Save+"Go to a new empty record" combined
> action.
>
> BTW, using the Next button to when multiple records have to be added is
> perhaps
> a good habit _regardless_ of existence of the reported bug.
@Ian ready to test, can be obtained via the Download Diff button at https://git.reviewboard.kde.org/r/123226/ Git commit 0bc8d1f91cc81cc9767def9006a25955aee157a7 by Jaroslaw Staniek. Committed on 02/04/2015 at 19:27. Pushed by staniek into branch 'kexi-345210-staniek'. Fix logic for adding new records for Kexi tables and forms - recently we allow editing to start in a row different than the current row, for this we need to remember which row is being edited, not just if the current row is edited - the above is used by a feature that first starts editing a row (e.g. the last) and only after that moves the cursor (animations are possible this way) - fixed buffered changes in edited record, otherwise saving did not work properly - added sanity checks for cases when editing of a row is requested but editing of other row was not accepted/cancelled FIXED-IN:2.9.3 M +15 -10 kexi/plugins/forms/kexiformscrollview.cpp M +1 -1 kexi/plugins/forms/kexiformscrollview.h M +33 -21 kexi/widget/dataviewcommon/kexidataawareobjectiface.cpp M +7 -7 kexi/widget/dataviewcommon/kexidataawareobjectiface.h M +2 -2 kexi/widget/dataviewcommon/kexidataawareview.cpp M +24 -18 kexi/widget/tableview/KexiTableScrollArea.cpp M +1 -1 kexi/widget/tableview/KexiTableScrollAreaHeaderModel.cpp http://commits.kde.org/calligra/0bc8d1f91cc81cc9767def9006a25955aee157a7 Git commit 71d7aaa3412e07a8ef4083167410d60833c854d6 by Jaroslaw Staniek. Committed on 19/04/2015 at 22:16. Pushed by staniek into branch 'calligra/2.9'. Fix logic for adding new records for Kexi tables and forms - recently we allow editing to start in a row different than the current row, for this we need to remember which row is being edited, not just if the current row is edited - the above is used by a feature that first starts editing a row (e.g. the last) and only after that moves the cursor (animations are possible this way) - fixed buffered changes in edited record, otherwise saving did not work properly - added sanity checks for cases when editing of a row is requested but editing of other row was not accepted/cancelled FIXED-IN:2.9.3 M +15 -10 kexi/plugins/forms/kexiformscrollview.cpp M +1 -1 kexi/plugins/forms/kexiformscrollview.h M +33 -21 kexi/widget/dataviewcommon/kexidataawareobjectiface.cpp M +7 -7 kexi/widget/dataviewcommon/kexidataawareobjectiface.h M +2 -2 kexi/widget/dataviewcommon/kexidataawareview.cpp M +24 -18 kexi/widget/tableview/KexiTableScrollArea.cpp M +1 -1 kexi/widget/tableview/KexiTableScrollAreaHeaderModel.cpp http://commits.kde.org/calligra/71d7aaa3412e07a8ef4083167410d60833c854d6 |