Hide Forgot
after case creation, ABRT is displaying the API representation of a resource; while fine from an API perspective, we don't really want to send users there since it's just an XML document. Instead, we should send them to the portal's view of that case. This should be a very simple change and is how the report library handles the issue: when case # <case-id> is displayed (eg, after creation) to the user, it should use the host: access.redhat.com (not api.access.redhat.com) and resource: /support/cases/<case-id> (not /rs/cases/<case-id>) ideally, this will work when pointing to our QA environment (access.webqa, not api.access.webqa) or other test environments, so just dropping the api from the hostname and doing the resource translation as a general rule is better than hardcoding. Right now we're detecting sub-optimal case requests and working around it with a server-side re-direct, but I'd like to get it fixed.
alternately, the UI could just display the case number, not the full path, and we can leave the re-directs in place. Eg, render html like: <h1>Case Created</h2> <p>Thank you for creating a case with Red Hat support. View case <a href="https://api.../123/">case 123</a>.</p> or something like that...
(In reply to comment #0) > after case creation, ABRT is displaying the API representation of a resource; > while fine from an API perspective, we don't really want to send users there > since it's just an XML document. Instead, we should send them to the portal's > view of that case. I believe we were discussing this already, but it was some time ago, I don't remember details. To refresh my memory, I crashed sleep process and reported it from test RHEL installation. abrt says: Case created: https://api.access.redhat.com/rs/cases/00411139 abrt extracts this URL from Location: header. > This should be a very simple change and is how the report library handles the > issue: when case # <case-id> is displayed (eg, after creation) to the user, it > should use the host: > > access.redhat.com (not api.access.redhat.com) > > and resource: > > /support/cases/<case-id> (not /rs/cases/<case-id>) There are two options how to achieve this: client-side code can perform manipulations on URL to convert it to https://access.redhat.com/support/cases/00411139 form; or server can send it, making client-side more generic. Server can either send converted URL in Location: header (problematic, as the URL is also used as a base for attachment transaction), or it can send additional header with human-interface URL (naturally, in this case client code needs to be taught to look for that header - easy thing). > Right now we're detecting sub-optimal case requests and working around it with > a server-side re-direct, but I'd like to get it fixed. I confirm that your current server-side redirect works for now. Andrew, which of these possible fixes do you like most? (1) client-side URL conversion? (2) server-side change to send converted URL in an additional header? I can implement either solution.
I think my original request was a bad idea: then you're stuck maintaining a client side translation forever. (So no to #1) Instead of #2, can you just display a message to the user which doesn't include the URL directly (like an html href?). We can change the server to send back a suggested html message if that's helpful... Andrew
Are you proposing simply changing this message: Case created: https://api.access.redhat.com/rs/cases/00411139 into something like this? Case created: please follow _this link_ to see it (where "this link" points to https://api.access.redhat.com/rs/cases/00411139)
sounds good to make, thanks Denys.
Implementing it in GUI is possible, but this makes the message "gui-centric". For example, there can be no hyperlinks when we work in text mode (abrt-cli tool). In this case reporting result message *has to be* just a string, not HTML.
makes sense, for CLI let's keep just returning the content of the Location: header.