-
-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Need a graceful error message for logging in #4501
Comments
YES PLEASE |
When we had more informative error messages we also had a steady stream of "hackers" trying to exploit them. Arctos gets considerably more traffic than it did then. I can do WHATEVER with the generic error, but I'm not sure we have the resources to deal with the inevitable effects of being much more specific. I'm emotionally attached to the lowres smoking computer gif, but mock up something else and I'll replace it - and then go cry in the corner.... |
Well, we get this particular error message a lot ...
I know and I will supply hankies! (plus I'm not asking you to scrub our little smoking friend entirely....) Just in this context it's gotta go. Ok, mockups to come for a generic error |
You could have a little computer gif with a key hole to represent you need to get access maybe? |
Draft generic error message in google doc for direct editing and comments (html at bottom of doc) Please suggest other solutions to things that may be triggering that a generic error.... |
I agree with the idea of having different error screens; I'd prefer to have something that clues me in to what I'm doing wrong, especially with regards to bulkloading. |
That's a blurry line-- the public and the operators are often equally
confused with the current smoking error message. The main feedback I've
gotten about that error message are from curators and users.
If the distinction is between error messages of two different states--
logged in or not logged in, then I'm in total agreement.
The draft I linked is premised on a user not logged in at least for tip
1-2, we can save #3 for the logged in operators. Any error message can have
the raw error dump but as an addendum and not the first and only thing
someone sees. for example, the raw dump comes after the friendlier message
and in smaller font.
…On Wed, Apr 6, 2022 at 10:31 AM dustymc ***@***.***> wrote:
This needs more discussion.
The "pretty" error isn't sufficient for users to solve problems (see #4515
<#4515>, #4518
<#4518>). Suggest, at least as a
starting point:
1. Public users keep getting what they get now
2. "Us" - Operators with role coldfusion_user - get the raw error dump.
Thoughts?
—
Reply to this email directly, view it on GitHub
<#4501 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AATH7UM7BCW6RIEP3FHN76TVDXC6TANCNFSM5SF3Z7DA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
The issue seems to be that we can have only ONE error message? Why is that? When I am doing something dumb in Agent Prebulkloader (adding a new status, but not checking anything to change) I get this exact same message. I sometimes figure out what has gone awry and sometimes I don't. The proposed change was for
but now it's what we get for everything. I suspect the user community is used to more tailored messages when they do something wrong in a webform. If we can figure out how to customize some of our error messages, Dusty won't have to answer everyone's repeated questions about them. |
That's a slightly different issue than the one I meant to have and clues
are available in the raw error dump to specific operation issues. But if we
distinguish between generic message for people not logged in then that's a
start to working on message specific to troubleshooting operator issues.
Bulkloading is almost its own thing-- maybe we should have a table of
common errors and how to fix... (new issue request!)
…On Wed, Apr 6, 2022 at 10:37 AM Jessica Weller ***@***.***> wrote:
I agree with the idea of having different error screens; I'd prefer to
have something that clues me in to what I'm doing wrong, especially with
regards to bulkloading.
—
Reply to this email directly, view it on GitHub
<#4501 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AATH7UJBY6MB2C5V7BGZOBTVDXDUJANCNFSM5SF3Z7DA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Yes, they're logged in as an Operator or not. "Trying to get there" is "not."
Agreed, but #4509 is rapidly turning into the rabbit hole of rabbit holes - I can dump for us now(ish), doing more needs some other stuff straightened out first and that is looking like that's going to take a while. I'm voting for "just dump, make it pretty when possible" but happy to be overridden.
Our security team (or lack thereof...) demands uninformative errors for "not-us." "Us" is welcome to see the gritty details, I just live a limited capacity to make it less-gritty at the moment. |
Test is (slowly) coming back together with much more robust error handling, including a centralized mechanism to sort and customize exceptions. Initially public users will get a bit more information in specific circumstances (specimenresults timing out), operators will get a dump (first a "summary table" then a raw exception) below a hopefully-nice (but likely not very informative) message. It should be straightforward to adjust and tune under this mechanism, but if anyone wants to go break test, logged in and/or out, I can adjust things before this goes to production. The low-res melting computer is nowhere to be found, I still want my hankie. |
If you click on a link from your email without being logged into Arctos you get an annoying error message (see below). This is a serious impediment to taking notifications seriously and is misleading (i.e., Arctos is not 'broken')
Instead, please change this type of error to a useful one, for example:
"The page you are trying to access requires logging into your Arctos account. Please log in below"
then provide the login fields (skip the burning workstation, how about the Arctos bear instead!)
I have been already receiving complaints...
Here's one example:
![Screen Shot 2022-03-31 at 8 17 22 AM](https://user-images.githubusercontent.com/2523089/161098575-3ad72a91-af84-4bec-a04c-8a1644828c3a.png)
The text was updated successfully, but these errors were encountered: