@Jiri this was intended to be rw, sio that the user can edit the journal (that's the content of the textarea), remove passwords and other sensitive data. I agree that's not the most user friendly UX though, so leaving this open to discuss this with our designer.

I think we need to make a choice here: Either make it read-only or we add a little note about why you can edit. (Or make it read-only and also add a note. 😉)

However, I think editing is surprising for a few reasons: It's unexpected... and doesn't really have a purpose as of yet, as you cannot copy/paste into a bug report, as that would require  internet access (which implies network access, which would need to be configured and connected to, which may require a username and password or security keys of sorts, depending on the connection), a bugzilla username and password (which might only be in an encrypted password safe), and possibly 2FA as well. This is in addition to multitasking as well, allowing a normal browser window being open to the side of Bugzilla.

In other words, I don't think it's actually even useful until we have remote connections.

And even then, would editing the logs in a small textarea in Anaconda any easier than in a textarea in Bugzilla? So I'd suggest it's a "feature" that isn't actually really useful.

Taking this all into consideration, I suggest that we do _not_ have the logs be editable. And that we add a little notice about how the logs may contain personable information. Something like a small help text with an (i) icon, below the scrollable logs area, with text like: "System logs may include personal information. Be careful when sharing these logs."

@garrett we actually upload the journal logs (which are contained in the textarea) as attachment to Bugzilla, which is not editable (not even previewable) at the point of creating the bugzilla ticket. So any editing, needs to be done prior the 'Report Issue' button is clicked.

OK, we definitely need to make it editable as it goes directly to Bugzilla, where it isn't editable.

This means we:

A. Need to make it obvious that it is editable.
B. Also need to say why it is editable.

I'll work on a mockup for this.


But first, a few questions:

1. What happens when there isn't a network connection (which will be the case most of the time)?

2. Does this require an account somehow / somewhere? Or is it sent to Bugzilla anonymously?

One can't do anynymous bug reporting to bugzilla. Users would need to establish a network connection through gnome panel and then login with their account for submitting the bug report.

So this means it's not even possible to report an issue unless:

1. someone knows that they have to turn on network (which isn't even possible on non-live ISOs in the future)
2. click report
3. click "yeah, leave this page" (to a modal that makes no sense)
4. then click on a launch button (for a mimetype that isn't properly registered, else it should auto-launch)
5. have a bugzilla account (which means they might need to create one if they don't have one, which means they need to be able to access their email to confirm and so on too)
6. then log in to bugzilla (once they have an account, assuming they even have access to their username and password and 2FA (if they need 2FA))?

I've said it before and I'll say it again: We need to save this log file to a writable portion of the USB stick whenever a crash happens or when report issue is explicitly selected from the menu, so that people have access to the logs and can report when they don't have access to the network or bugzilla for whatever reason, or if they prefer to report from their own laptop/desktop instead of the machine they're installing from.

This needs to be part of the flow, and they need to be told about it, which means it's relevant from the UI (here, specifically) as well.

The journal doesn't have passwords in clear text. The system is temporary and does not have user data. If someone has physical access to the hardware, they can already do worse things than read the logs. If the files are saved as "root" you can just become "root" on another machine anyway (there's no safety in marking something as "root" on a USB stick). As the logs wouldn't be saved except when you tell it to report a problem or when there's an actual crash, then it's really even more limited. But saving the logs would enable people to report a log from another machine, such as one where they have access to their bugzilla accounts or a means to create a bugzilla account (which requires an email flow to verify, like every account). We could even have a "sidecar" file (a file with additional data in the same place as the file with the actual data) called README.html or README-bugreport.html or something like that with instructions and a link to report the bug with bugzilla, to make it easier to report after the fact.

And, of course, the flow for reporting online still really needs to be improved in several ways... and some of these are tricky, of course (such as anonymous reporting, which really needs to happen somehow, and will require people outside our team to help us with).

Just in case it's not obvious, this is talking about the overall flow and also the design of the dialog too. As-is it's extremely questionable how useful this is, as most people will not be able to jump through all of the above hoops to report a bug. The fact that some do somehow is fantastic, but we need to make bug reporting better overall.

Adding more words or turning the existing words red or adding an icon will not fix the problem with the dialog and, overall, the bug reporting flow. We need to fix the flow, not wordsmith. No words can fix this problem.

For reference, this is what the modal currently says:

"Report issue"
"The following log will be sent to the issue tracking system where you may provide additional details."

[log here]

"Reporting an issue will send information over the network. Please review and edit the attached log to remove any sensitive information."

The modal already says this will be sent over the network and it already says to review and edit the log.

The extremely minimal approach to not fix the actual bugs with the flow, but to make this stand out more (as this bug title asks) is to make it look more like a warning with colors and an icon. But this doesn't fix the actual problems, it only giftwraps the broken process with color and an icon.

Part of the problem is that PatternFly 5 does not have a good focus indicator for text areas. This is improved in PatternFly 6.

PF5: https://v5-archive.patternfly.org/components/forms/text-area

PF6: https://www.patternfly.org/components/forms/text-area/

When we eventually upgrade to PatternFly 6, this will help.

Meanwhile, I will be immediately attaching a mockup that finetunes the to make it a bit more obvious that the text can and should be edited by:

1. removing half of the text, so it's less to read (and therefore easier to understand)
2. moving the warning to the top
3. giving it an inline alert style
4. bolding the key words

Even after this, we should address all the issues I brought up above for both online error reporting (when there is network) as well as implement offline reporting (saving to USB stick).

But, as for this specific bug, I think we can consider it fixed once the mockup changes are implemented and we open up the online and offline flows as follow-up issues to work on later.

Resolved with:

commit 6e8929152c261b6f85e2472df3628d5f279bcd9e
Author: Adam Kankovsky <adamkankovsky>
Date:   Tue Apr 22 15:27:02 2025 +0200

    components: error: redesign error reporting