Lightboxing spoils spoilering
-
All of these are spoilered images, and appeared spoilered in preview. The px number is the width of the image.
Current site settings:
1600px:
[spoiler][/spoiler]800px:
[spoiler][/spoiler]400px:
[spoiler][/spoiler]200px:
[spoiler][/spoiler]
-
That's a regression isn't it? They had that working at some point. 🚮
-
I think it was an attempt to fix the 'spoilering spoils lightboxes' in that a spoilered thumbnail didn't produce a lightbox when clicked when it should have. A bug I'm sure I raised this recently but cannot find. This is the closest I can find from back in '13:
https://meta.discourse.org/t/how-do-you-spoiler-an-image-or-onebox/55
-
-
@PJH said:
A bug I'm sure I raised this recently but cannot find.
I wonder whyI think that particular one's more of a case of "this bug doesn't exist any more - lets delete it so we have less clutter."
-
Isn't that what closing is for?
-
Sure, but then there's evidence it existed.
-
I think that particular one's more of a case of "this bug doesn't exist any more - lets delete it so we have less clutter."
and that, ladies and gentlepersons, is why DISCOURSE IS NOT A BUG TRACKER
you should NEVER be able to delete a bug report from your bug tracker.
close WONTFIX, yes
close ASDESIGNED, yes.
assign it to the backlog of death where all bugs go to wait in eternal limbo, yes.
Delete a bug from public visibility? NO
</rant>
-
Delete a bug from
publicvisibility? NOYou can hide it from public eyes but if you hide it for your dev's you are collectively lying to yourself
-
If your bug tracker is public then your bug reports must be public.
you can have an internal team tracker that is not public in addition to the public tracker, and you can have a method for responsibly disclosing security issues, but once the bug is public it MUST remain so, otherwise your bug tracker cannot be trusted.
-
Delete a bug from public visibility? NO
I'd imagine there's not a bug tracker in existence where someone with high enough access can't delete bugs.
-
If your bug tracker is public then your bug reports must be public.
Security related issues?
-
@accalia said:
Delete a bug from public visibility? NO
I'd imagine there's not a bug tracker in existence where someone with high enough access can't delete bugs.
within the bug tracker software? there had better not.
i'll give you it's always possible from the database level, but as a user of the bug tracker software of any permission level.... no, that should not be an option.
-
Security related issues?
see alternate channels for responsibly disclosing the issue.
once the security issue is resolved and released then you enter it into the public bug tracker (redacted to flavour)
-
within the bug tracker software? there had better not.
oh great so bug #1 will always be 'Test Bug' ?
-
oh great so bug #1 will always be 'Test Bug' ?
Is that a bad thing?
if you dislike that, then have a different numbering scheme. maybe something like GIT's SHA hashes for commits. you could use that for bugs.
-
within the bug tracker software? there had better not.
Quality Center, for example, allows it. Access is controlled by permissions.
-
Quality Center, for example, allows it.
/me makes a note to strike that off her list of "approved" bug trackers.
-
-
@accalia said:
SHA hashes
But how are we going to hold a party when bug 666 gets squashed?
that's a deal breaking concern for you when choosing a bug tracker?!
-
that's a deal breaking concern for you when choosing a bug tracker?!
Yes!
But it might explain why I'm no longer consulted on such decisions.
-
Yes!
But it might explain why I'm no longer consulted on such decisions.
That.... seems likely
-
-
I'd imagine there's not a bug tracker in existence where someone with high enough access can't delete bugs.
GitHub Issues - not even the owner of the repository can delete issues or pull requests once they are created, even though they can edit the content of all comments. GitHub probably can only remove issues that violate the law. (Although you can just edit comments to remove stuff, changes in the issue/PR title are tracked and publicly visible and thus would have to be removed by GitHub).
-
@loopback0 said:
Quality Center, for example, allows it.
/me makes a note to strike that off her list of "approved" bug trackers.
I'm sure HP will be gutted.
It's trivially switched off.
I don't see the issue with it - do people generally not trust their own developers?
If you don't trust your developers to fix bugs rather than delete them, you have other issues.
-
Previously reported? Can't tell if it's the same bug, because spoilering and images and Firefox don't always get along even on good days...
https://what.thedailywtf.com/t/cant-spoiler-lightboxed-images/51290/1
-
I don't see the issue with it - do people generally not trust their own developers?If you don't trust your developers to fix bugs rather than delete them, you have other issues.
My team? hells yes i trust them.
it's other teams that i have less trust on.
We've seen with Discourse that the power to delete bugs can be abused, and what can be abused will eventually be abused.
I trust my team, but i also have to trust the teams of every project my project relies on. and when they use a forum as a bug tracker, or don't even have a bug tracker at all.... well it becomes really hard to trust them.
-
it's other teams that i have less trust on.
the power to delete bugs can be abused,
So you don't give those teams access to delete bugs. Problem solved.
Just in case it seems like I'm sticking up for Quality Center (the cost of which is enough to strike it off most people's list of options) - I'm not, I just think being able to delete bugs is a silly reason to discount bug tracking software.
-
So you don't give those teams access to delete bugs. Problem solved.
OI! JEFF! YOU CAN'T DELETE BUGS! IT'S WRONG!
.... oh. he banned me.....
-
Quality Center, for example, allows it. Access is controlled by permissions.
JIRA is the same way. Global admins can delete anything, and they can revoke or grant the ability to delete tickets to anyone in the permissions system. It does give a warning saying "Are you sure? If the bug is fixed, close it instead!"
-
The problem is, many programmers don't give a shit about warnings.
-
Yes, make the bug tracker a blockchain, like in bitcoin, where every bug has the hash of the previous one so there is no possibility of deleting one.
-
Why lecture us? We all know that already.
-
Oh noes a bug in Discourse.
Better report it so it gets fixed quickly!
No, wait, we can't do that. And it wouldn't get fixed either way.
Better fork Discourse I guess?
-
Why lecture us? We all know that already.
If we were all of one mind not only would the world be a very boring place but there would be no discussion on the topic.
also, do you* need a reason to rant about things? I think not.
* For the record, that's the inclusive not imperitive form of 'you'. That is i am referring to a group of people that includes every member of this forum with that use of the word
you
.
-
-
@accalia said:
Unless you're going through the rest or com interface but that might be just how shoddily they set it up. On another note I found the com interface more pleasing to use than that awful fucking gui.within the bug tracker software? there had better not.
Quality Center, for example, allows it. Access is controlled by permissions.
also, do you* need a reason to rant about things? I think not.
Call the doctor!I do.
-
-
On another note I found the com interface more pleasing to use than that awful fucking gui.
..... wow..... that takes some impressively bad UX to do that....
-
Meh. The QC user interface isn't particularly offensive.
I'm more offended by the fact we're stuck on the previous version which loves ActiveX and only runs on Windows.
-
-
FWIW, a godadmin more often than not has db access, because that kind of stuff is accessible in the admin panel. So the point is somewhat :moo: once you get to a certain level of admin
-
I'd say security bugs reported the wrong way should still be hidden until they're fixed.
Edit: Also, what do you do if a spambot gets access to your public bug tracker?
-
I'd say security bugs reported the wrong way should still be hidden until they're fixed.
Edit: Also, what do you do if a spambot gets access to your public bug tracker?
This too
It makes sense to allow a certain level of admin the ability to delete bug reports.
If that ability gets abused, however..........
-
I like the idea of GitHub/Bitbucket/[insert hosted VCS+issue tracker site name here] because it means the people who are in charge of the site and getting rid of abusive stuff are not the same people who are in charge of individual repositories.
You can report abuse on something, but that's not going to get legitimate reports deleted, and you'll probably end up banned for abusing the abuse system.
-
Previously reported? Can't tell if it's the same bug, because spoilering and images and Firefox don't always get along even on good days...
You are correct, that is the same bug.
-
OI! JEFF! YOU CAN'T DELETE BUGS! IT'S WRONG!
.... oh. he banned me.....
Yeah, his craziness about getting rid of stale content totally falls down when it comes to keeping track of bugs. Dog food sounds good but you have to remember that dogs also eat their own vomit.
-
Dogfooding the world's most popular administrative trolling platform as an issue tracker.
-
We've seen with Discourse that the power to delete bugs can be abused, and what can be abused will eventually be abused.
That's not a Discourse issue, that's a project management issue.
-
Why not both?