Bug 710100

This may be addressing the same issue:
Bug 711580 - privacy may be compromised by some environment variables in the report

*** Bug 711580 has been marked as a duplicate of this bug. ***

*** Bug 713553 has been marked as a duplicate of this bug. ***

*** Bug 655580 has been marked as a duplicate of this bug. ***

Fixed in git:

commit 8e369296f77d5a9d3e4dd146a77bdcc9ec1e8186
Author: Denys Vlasenko <dvlasenk>
Date:   Sat Jul 16 11:16:02 2011 +0200

    wizard: save edited lines if they are EDITABLE

abrt-2.0.7-2.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/abrt-2.0.7-2.fc16

Package abrt-2.0.7-2.fc16, libreport-2.0.8-3.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing abrt-2.0.7-2.fc16 libreport-2.0.8-3.fc16'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2011-16990/libreport-2.0.8-3.fc16,abrt-2.0.7-2.fc16
then log in and leave karma (feedback).

unfortunately, this doesn't seem to be fixed

[kvolny@kvolny ~]$ rpm -q abrt-gui
abrt-gui-2.0.7-2.fc16.x86_64

at the Problem description screen, if I try to edit for example the "cmdline", it seems that the value gets changed, but if I go next and then back, the original value gets restored; also at the Review the data scrreen the cmdline tab shows the original value instead of the one I've entered

This is fixed by libreport-2.0.8, are you sure you have it installed? I can change the cmdline and it's saved just fine.

(In reply to comment #9)
> This is fixed by libreport-2.0.8, are you sure you have it installed? I can
> change the cmdline and it's saved just fine.

[root@kvolny ~]# grep libreport /var/log/yum.log
...
Dec 12 17:51:46 Installed: libreport-filesystem-2.0.8-3.fc16.x86_64
Dec 12 17:51:47 Updated: libreport-python-2.0.8-3.fc16.x86_64
Dec 12 17:51:48 Updated: libreport-2.0.8-3.fc16.x86_64
Dec 12 17:51:57 Updated: libreport-plugin-bugzilla-2.0.8-3.fc16.x86_64
Dec 12 17:51:57 Updated: libreport-plugin-logger-2.0.8-3.fc16.x86_64
Dec 12 17:51:58 Updated: libreport-plugin-kerneloops-2.0.8-3.fc16.x86_64
Dec 12 17:52:00 Updated: libreport-gtk-2.0.8-3.fc16.x86_64
Dec 12 17:52:02 Installed: libreport-plugin-bodhi-2.0.8-3.fc16.x86_64
Dec 12 17:52:03 Updated: libreport-newt-2.0.8-3.fc16.x86_64
Dec 12 17:52:03 Updated: libreport-plugin-reportuploader-2.0.8-3.fc16.x86_64

abrt-2.0.7-2.fc16, libreport-2.0.8-3.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

reopening as per comment #8

(In reply to comment #8)
> unfortunately, this doesn't seem to be fixed
> 
> [kvolny@kvolny ~]$ rpm -q abrt-gui
> abrt-gui-2.0.7-2.fc16.x86_64
> 
> at the Problem description screen, if I try to edit for example the "cmdline",
> it seems that the value gets changed, but if I go next and then back, the
> original value gets restored; also at the Review the data scrreen the cmdline
> tab shows the original value instead of the one I've entered

Can't reproduce. "cmdline" element can be edited. Some other fields, such as "executable", can't be - they show the behavior you described.

In fact, there is a commented-out code which makes non-editable fields doing that:


commit 8e369296f77d5a9d3e4dd146a77bdcc9ec1e8186
Author: Denys Vlasenko <dvlasenk>
Date:   Sat Jul 16 11:16:02 2011 +0200

    wizard: save edited lines if they are EDITABLE

    Signed-off-by: Denys Vlasenko <dvlasenk>

diff --git a/src/gui-wizard-gtk/wizard.c b/src/gui-wizard-gtk/wizard.c
index bc50fd6..4cbac9a 100644
--- a/src/gui-wizard-gtk/wizard.c
+++ b/src/gui-wizard-gtk/wizard.c
@@ -505,7 +505,12 @@ static void tv_details_cursor_changed(
     struct problem_item *item = get_current_problem_item_or_NULL(tree_view, &item_name);
     g_free(item_name);

-    gboolean editable = (item && (item->flags & CD_FLAG_TXT) && !strchr(item->content, '\n'));
+    gboolean editable = (item
+                /* With this, copying of non-editable fields are more difficult */
+                //&& (item->flags & CD_FLAG_ISEDITABLE)
+                && (item->flags & CD_FLAG_TXT)
+                && !strchr(item->content, '\n')
+    );


It was disabled because the ability to copy the (non-editable) strings to clipboard is also lost.

What should we do?

(In reply to comment #13)
> Can't reproduce. "cmdline" element can be edited.

come to my cube :-)

> Some other fields, such as "executable", can't be - they show the behavior you
> described.
...
> It was disabled because the ability to copy the (non-editable) strings to
> clipboard is also lost.
> 
> What should we do?

fix the framework to allow copying also non-editable fields?

watch the fields and change the displayed value back immediately, popping up some warning?

differentiate fields that shouldn't be edited by some distinct graphics style, adding a (visible) note that editing such field will have no effect?

I believe that the initial problem is fixed the fields which are supposed to be editable are editable and the value is saved (e.g. cmdline) and users are presented with the window where they can see and edit all of the editable values. The second problem - that it's hard to distinguish between the editable and non-editable rows on the last page is for another bugzilla.