Can someone on Core test this? (Bug in GUI)

[winnielinnie]

Before I create a bug report, I want to confirm others notice the same bug in the GUI.

(This "test" is 100% safe. No data will be involved. It will not impact your server at all.)


STEPS:
Create three (or more) Rsync Modules under Services -> Rsync

Configure them however you like. As long as they're all different and point to different folders

Make sure to name them differently, so that it's easy to differentiate them

Now on the Rsync Modules page (Services -> Rsync), try to "edit" the different modules. (Click the "Edit" button under each module.)



HERE'S THE BUG:
Randomly it will bring up the wrong module. So if you click edit for "Module C" it will pop up the view for "Module A".

This bug is quite random. Sometimes it brings up the correct module, and sometimes it brings up the wrong one.



I came across this by accident, since I ending up configuring a different module by mistake when I didn't know the GUI presented the wrong one. (It's like the TrueNAS GUI is gaslighting you.)


EDIT: Here is a video demonstrating the behavior, as confirmed and reproduced by @calculon0

 

[calculon0]

I can confirm this happens to me as well. I just tested this on CORE 13.0-U3.1.

Sometimes when I edit the 2nd and 3rd Module, it will show the 1st Module. Editing the 1st Module never resulted in the bug.

 

[winnielinnie]

Bingo.

What you just described is the exact same thing I experience.

This is obviously a bug in TrueNAS Core's web UI. (It's not a "minor" bug either, since it can cause the user to accidentally change something on their server without realizing it.)

I'll file a bug report for it.

 

[winnielinnie]

Bug report filed:

[NAS-120250] - iXsystems TrueNAS Jira

ixsystems.atlassian.net

Please vote for this, since it's confirmed and reproducible.

 

[calculon0]

Voted for it, and added some additional context.

It is showing the correct URL for me (<hostename>/ui/services/rsync/rsync-module/edit/2) so it will save the changes to Module 2, but that requires me to change all the fields back to Module 2's original data. Otherwise it will incorrectly save Module 1's data to Module 2.

 

[winnielinnie]

Otherwise it will incorrectly save Module 1's data to Module 2.

That's even worse than I first suspected. So it appears this bug is worse than simply "presenting the wrong window". (Which would have been bad enough anyways.)

That might explain why I noticed some parameters were wrong and I thought to myself "I'm pretty sure I never did that..."

 

[winnielinnie]

I cannot recommend users of TrueNAS find bugs and report them.

See for yourself:

[NAS-120250] - iXsystems TrueNAS Jira

ixsystems.atlassian.net

This is why I'm hesitant to file bug reports.

Great. The button in the GUI doesn't behave as it should, which affects all TrueNAS Core deployments, and is not unique to my system, and has been confirmed by others.

So now it's publicly known there's an issue with the GUI, and it won't be fixed. Great stuff, iXsystems! Once TrueNAS Core becomes long in the tooth and stagnates, I'm not moving over to SCALE. Even though SCALE's GUI has real polish, developments, and improvements, it's a paradigm-shift from a Core-based NAS. (Jails vs K3s, memory management, etc.)

Me: "Clicking this button brings up the wrong view."
Other User: "Same here when I click the button."
iXystems: "Won't fix. Need debug dump. Just because."


If I found an incorrectly worded tooltip or mislabeled button in the GUI, would that need a debug dump as well?

 

[JoshDW19]

Hrm, I see your point there @winnielinnie. Let me have a chat with a couple of people and I'll get back to you.

 

[danb35]

Yeah, iX are way to quick to close bugs with incorrect resolutions. My favorite examples: "SCALE gives a false alert that says the root user's password is disabled." "Works as intended, closed." New ticket: "So you intend the product to lie to the user?" "Works as intended, closed."

 

[souporman]

Sounds like a pretty typical "Corporate" thing to do. Engineers don't want to talk to users and got fed up with L1 support not gathering enough info, so they just made a blanket policy. "If you send me a bug ticket with no dump we will just close them from now on". I hope Michelle Johnson doesn't take the brunt of this public shaming, since they probably didn't make this policy, but I also hope iX realizes they can't do things like this yet. You have to be much bigger to ignore your customers in this way.

 

[winnielinnie]

Watch the video yourself (in full screen). This is on TrueNAS Core 13.0-U3.1. This is the same behavior as confirmed by another user, @calculon0.

Notice it's random? Notice that sometimes when I click "Edit" for kittens-and-cats it will present a screen for me to supposedly edit puppies-and-dogs.

Even the fields are filled for the other module. (Watch the video multiple times to see what I mean. Notice the folder location and other options. Notice it is random. Sometimes it presents the correct view, and sometimes it does not.)

Watch this in full screen.


This is not acceptable for "business use" quality. If the proper QA doesn't catch something upstream (understandable), then please don't shoot down users who catch bugs and quirks in the web UI. Otherwise, guess what? We just won't report bugs anymore, even when we find them for you.

 

[winnielinnie]

I hope Michelle Johnson doesn't take the brunt of this public shaming, since they probably didn't make this policy, but I also hope iX realizes they can't do things like this yet. You have to be much bigger to ignore your customers in this way.

It's not my intention to name any particular person or point a finger to any individual. That's why I kept referring to "the developers", "the engineers", and iXsystems' policy of handling bug reports.

I want to make clear my frustration with the experience of finding and reporting bugs. I've attached debug dumps in the past, since it was relevant and wouldn't send the developers on a wild goose chase. But I won't do a song-and-dance on easily reproducible (and confirmed) issues of the web GUI or buttons in the interface. Especially since debugs can sometimes contain sensitive information and logs that I might not want to share if it has nothing to do with an obvious GUI bug.

What's ironic is I could instead have filed this as a "feature request" and bypassed the obligatory "need more info" ritual.

Feature Request: Make the "Edit" button under the Rsync Modules page not randomly present the wrong module.

Sounds like a pretty typical "Corporate" thing to do. Engineers don't want to talk to users and got fed up with L1 support not gathering enough info, so they just made a blanket policy. "If you send me a bug ticket with no dump we will just close them from now on".

While I can understand this on the surface, there needs to be flexibility when the bug reporter is persistent and uses good faith and follows up.

It's not like my server crashed during the middle of a replication and I just do a "fly by" bug report without following up. (Obviously in that case a debug dump is essential, and it's unique to my system.)

 

[JoshDW19]

Hi there @winnielinnie. I just wanted to follow up and let you know I talked to our triage team about this. I looked through the triage workflow and there is messaging that says at the very beginning of opening a ticket (and in a follow-up email) that we do need a debug on any bug reports. At times, things can look like one type of issue but then also impact another subsystem like the middleware. Having a debug on hand for each issue is a quick way to prevent Engineers from having to make assumptions that an issue impacts only one thing and ensures we're delivering the highest quality standards possible. We've had many times in the past where we've received reports that are incomplete and required Engineers to invest way too much time without a clear enough understanding.

I hope you can understand our challenge here. We're very happy to assist but we will need that debug to look into your issue. If you are able to respond to that bug report with the information I'll follow up with them to make sure we get this fixed up.