🔥🐞 outlook bugs and not_a_bugs
-
@accalia What if the user selected "bug report" while entering the ticket but was really submitting a new feature request? Is it a bug that they want a new feature?
-
@boomzilla A bug in the bug reporting system because it led you to file a bug when you wanted to file a feature request?
-
This is the jellypotatoest thread I have ever come across, btw. It bounced me around to one of Yami's posts like 10 times.
-
@FrostCat Would you call that a bug?
-
@boomzilla I don't think it's supposed to do that, so probably.
-
I once had a bug report come in stating that an invoice came up with the wrong total. The user in question manually calculated the line items and came up with a different total than what was in the invoice. This invoice had no voodoo black magic that would throw one off. It was simply an invoice consisting of something like the following:
Refrigerator $1,200
Stove $ 900
Microwave $ 150
Total: $2,250How would you file this bug? It's not due to some poor documentation, poor formatting, or a confusing font. The user used a standard calculator that was also not buggy. It was all due to the user jumping to conclusions and not double checking whether he had, in fact, encountered a bug. I mean, maybe the user needs a special dialing wand because his fingers were too fat? Is there a bug report resolution for that case?
-
@The_Quiet_One said in 🔥🐞 outlook bugs and not_a_bugs:
How would you file this bug? It's not due to some poor documentation, poor formatting, or a confusing font. The user used a standard calculator that was also not buggy.
... so what was the bug? He came up with a number other than $2250? Are you saying he typed into his calculator wrong, or...?
-
-
@Jaime said in 🔥🐞 outlook bugs and not_a_bugs:
There is an argument that it doesn't make sense to prevent it. For example, if you want to move an address from one list to the other, there may be a time when it is on both lists. Preventing an address from being added to the second list while they are still on the first list will annoy the user that wants to make sure they have it on the second before removing it from the first, perhaps because they are concerned that they won't know the user's email address if the successfully remove it, then have some sort of computer problem, or other interruption.
You are so uncreative. In less than two seconds, just after reading first few posts in this topic, I came up with a solution to the problem you presented - a dialog box saying "You already have this person on whitelist. What do you want to do? [Keep on whitelist] [Remove from whitelist and add to blacklist] [Only remove from whitelist]". With this, you can't have the address on both lists, yet still have a simple way to move addresses between them! Win-win!
-
@Jaime said in 🔥🐞 outlook bugs and not_a_bugs:
My philosophy is that you shouldn't prevent an action unless it is always inappropriate to perform that action. If it's simply "odd" to perform an action, that isn't good enough for me to justify maintaining another business rule.
There are cases where dereferencing null pointer is appropriate. There are cases where accessing an array with out-of-bounds element is appropriate. There are cases where
rm -rf /is appropriate. There are cases where removing files you have no access rights to is appropriate. There are cases where substituting ntdll.dll with your own library is appropriate. And so on and so on and so on. You can justify anything if you try hard enough, so if we were to follow your philosophy exactly as you stated, there should be no validation routines in any code ever made at all.
-
@blakeyrat said in 🔥🐞 outlook bugs and not_a_bugs:
@The_Quiet_One said in 🔥🐞 outlook bugs and not_a_bugs:
How would you file this bug? It's not due to some poor documentation, poor formatting, or a confusing font. The user used a standard calculator that was also not buggy.
... so what was the bug? He came up with a number other than $2250? Are you saying he typed into his calculator wrong, or...?
Yes, he typed into his calculator wrong. Meaning there was no bug. Not only did the software work as designed, there was no question that was how it's supposed to be designed. Plus, seeing that the user realized his error after it was pointed out, and agreed that it wasn't a bug, then... it wasn't a bug.
-
@boomzilla said in 🔥🐞 outlook bugs and not_a_bugs:
which one wins?
From what I know in MS world, doesn't negative always outweigh positive (i.e. Deny permissions always precede Grant permissions)?
Therefore Blocked takes precedence over Safe.And with that, I'm ducking out.
-
@Gąska said in 🔥🐞 outlook bugs and not_a_bugs:
There are cases where accessing an array with out-of-bounds element is appropriate.
Really? I find my imagination failing here. When would that be appropriate?
-
@GOG hmm... Setting the padding between struct members to some specific value? And depending how you look at it, variable-sized arrays at the end of structs might count as this too.
-
@Gąska said in 🔥🐞 outlook bugs and not_a_bugs:
You are so uncreative. In less than two seconds, just after reading first few posts in this topic, I came up with a solution to the problem you presented - a dialog box saying "You already have this person on whitelist. What do you want to do? [Keep on whitelist] [Remove from whitelist and add to blacklist] [Only remove from whitelist]". With this, you can't have the address on both lists, yet still have a simple way to move addresses between them! Win-win!
So you are saying that preventing an entry from being on both lists is valid because you thought of some other idea? I agree that what you presented is better than both blindly preventing and blindly restricting duplication, but it doesn't change the fact that the OP's idea is a bad one.
-
@Gąska IIRC out-of-bounds array access is UB. Probably to allow the compiler a wider pick of addressing modes.
-
@Jaime said in 🔥🐞 outlook bugs and not_a_bugs:
So you are saying that preventing an entry from being on both lists is valid because you thought of some other idea?
I'm just saying why your argument for having this "feature" is bullshit.
-
@PleegWat said in 🔥🐞 outlook bugs and not_a_bugs:
@Gąska IIRC out-of-bounds array access is UB.
But most often it'll work, because the compiler usually doesn't know the size of array, so it'll just assume that the array is larger than it really is.
-
@Gąska said in 🔥🐞 outlook bugs and not_a_bugs:
I'm just saying why your argument for having this "feature" is bullshit.
I'm not arguing"for" a feature, I'm arguing "against" one. Preventing x, when x has a semi-legitimate use case is wrong.
Your idea of issuing a warning is better, but that doesn't make prevention right.
-
@Jaime said in 🔥🐞 outlook bugs and not_a_bugs:
I'm not arguing"for" a feature, I'm arguing "against" one. Preventing x, when x has a semi-legitimate use case is wrong.
Formatting Windows system partition from within Windows booted from that partition, could be argued to have a semi-legitimate use case. Do you think it's bad that it's not allowed?
-
@Gąska Also almost all code will run on intel, and I don't think intel even has addressing modes that only work for small offsets? Well, maybe if it's a literal offset, but not an array index from a register.
-
@Gąska said in 🔥🐞 outlook bugs and not_a_bugs:
@PleegWat said in 🔥🐞 outlook bugs and not_a_bugs:
@Gąska IIRC out-of-bounds array access is UB.
But most often it'll work, because the compiler usually doesn't know the size of array, so it'll just assume that the array is larger than it really is.
The reason it is UB is because as soon as you go out of bounds, you are not actually accessing the array anymore. Once you start mucking about with random memory addresses, all bets are off.
Now, it is certainly possible to design a language where going OOB means the array gets expanded to accomodate the additional indexes (unless you run out of memory, in which case you're SOL), but in that case going OOB would be perfectly legitimate behaviour and people would be rightly upset if we did anything to prevent it.
On the other hand, it seems to me that in any language where an array is to be of a declared, fixed size, the only legitimate response to an OOB access attempt is "don't be an ass."
If we can catch it beforehand, that is.
-
Not really. After all, compilers are deterministic applications, and my program will run on a deterministic CPU. If I'm very careful about what I'm doing, know my compiler and optimizations it does, know my target architecture and its capabilities, and know my operating system and constraints it puts on my program, it will work.
Of course, I would never actually do that myself. But the point is not whether it's good or bad to do so, but whether it's at all possible and if it ever makes sense.
-
@Jaime said in 🔥🐞 outlook bugs and not_a_bugs:
Preventing x, when x has a semi-legitimate use case is wrong.
What was the semi-legitimate use case again? I don't recall any ratioale for being on both lists.
-
@boomzilla said in 🔥🐞 outlook bugs and not_a_bugs:
What was the semi-legitimate use case again?
The transitional state that exists after you've added the address to the second list, but haven't yet removed it from the first list.
-
@Jaime said in 🔥🐞 outlook bugs and not_a_bugs:
The transitional state that exists after you've added the address to the second list, but haven't yet removed it from the first list.
That's not a use case. It's an implementation detail. You're allowing the system to get into a contradictory state. Yes, hopefully it's transitory, but now you're relying on the user to not trip over this bug instead of coming up with a better design.
-
@boomzilla said in 🔥🐞 outlook bugs and not_a_bugs:
@Jaime said in 🔥🐞 outlook bugs and not_a_bugs:
Preventing x, when x has a semi-legitimate use case is wrong.
What was the semi-legitimate use case again? I don't recall any ratioale for being on both lists.
@blakeyrat offered two that I find convincing:
-
the whitelist and blacklist filter based on different criteria (safe to open, but you may not want it)
-
the whitelist is managed on a group level and the blacklist on an individual level (or vice versa)
-
-
Does nobody go back and check? In Outlook, "Safe Senders" will never have mail from them moved to the Junk E-Mail folder[1]. By contrast, "Blocked Senders" will always have their mail moved there[2]. Therefore it doesn't make sense for someone to be in both lists. (People in your contact list are assumed to be Safe Senders). If someone's on both, it probably makes sense for the safe list to take priority and not move the email, because otherwise you might not spot it, but it's possible the other way could be better.
Outlook doesn't consistency-check the lists to make sure someone's not on both, and I don't know of any other list management (like the theorized (or maybe real) "the mail adminstrator can make lists that apply to groups").
[1] at least, that's what the help says.
[2] ibid
-
@GOG said in 🔥🐞 outlook bugs and not_a_bugs:
@blakeyrat offered two that I find convincing:
the whitelist and blacklist filter based on different criteria (safe to open, but you may not want it)Sure, and that in a product where that was true, it wouldn't be a contradiction.
@GOG said in 🔥🐞 outlook bugs and not_a_bugs:
the whitelist is managed on a group level and the blacklist on an individual level (or vice versa)
I think he's likely conflating things here. What I read about was that anyone in your address list, which includes any enterprise address list, gets automatically added to the safe senders list. But this still causes a contradiction based on the documentation of these two things.
So I must reject your attempts at rescuing this bug.
-
@FrostCat said in 🔥🐞 outlook bugs and not_a_bugs:
Does nobody go back and check? In Outlook, "Safe Senders" will never have mail from them moved to the Junk E-Mail folder[1]. By contrast, "Blocked Senders" will always have their mail moved there[2].
It's been mentioned in this thread.
Regardless of what the documentation says, the question is: what does the software actually do? Does the whitelist have priority or the blacklist? I am reluctant to assume an "immovable object v. an irresistable force" scenario here.
A blacklist that overrides a whitelist is actually a very sensible scenario, allowing for coarse and fine-grained filtering. And what if the documentation doesn't exactly spell it out? Frankly, this is the last place I'd expect to hear that if I'm using something outside the cases specified in the docs, I'm "doing it wrong".
-
@boomzilla said in 🔥🐞 outlook bugs and not_a_bugs:
So I must reject your attempts at rescuing this bug.
Let's agree to disagree. Regarding documentation, see my reply to @FrostCat.
-
@GOG said in 🔥🐞 outlook bugs and not_a_bugs:
Let's agree to disagree. Regarding documentation, see my reply to @FrostCat.
I suspect that it does behave consistently, though not enough to put any money on it. In that case, there's a documentation bug. But there is no legitimate use case for being on both of the lists as we know them.
-
@boomzilla said in 🔥🐞 outlook bugs and not_a_bugs:
there is no legitimate use case for being on both of the lists as we know them.
You're Jeff Attwood and I claim my £5.
-
@GOG said in 🔥🐞 outlook bugs and not_a_bugs:
@boomzilla said in 🔥🐞 outlook bugs and not_a_bugs:
there is no legitimate use case for being on both of the lists as we know them.
You're Jeff Attwood and I claim my £5.
I dunno, seems like a guy who argues that contradictions are a good thing has a better claim to the mantle than I.
-
@GOG said in 🔥🐞 outlook bugs and not_a_bugs:
what does the software actually do? Does the whitelist have priority or the blacklist?
I could find out, but that would be work.
-
@boomzilla said in 🔥🐞 outlook bugs and not_a_bugs:
What I read about was that anyone in your address list, which includes any enterprise address list, gets automatically added to the safe senders list.
IIRC anyone in your contact list is on Safe Senders. But it's only there implicitly. If you open the UI, it doesn't have them all.
-
@boomzilla I merely point out that software users are the ones who ultimately decide which use cases are legitimate, given the actual functionality of the program. If you don't think it's "valid", just don't do it.
-
@FrostCat said in 🔥🐞 outlook bugs and not_a_bugs:
I could find out, but that would be work.
Don't bother, it's not like it matters. We are after all discussing the principle, not a particular implementation of it.
-
@GOG said in 🔥🐞 outlook bugs and not_a_bugs:
I merely point out that software users are the ones who ultimately decide which use cases are legitimate, given the actual functionality of the program. If you don't think it's "valid", just don't do it.
You are free to think that and they are free to be mistaken about contradictory things not being contradictory.
