[PHPBB3-9526] User Preference to hide online status does not work for bots Created: 08/Apr/10  Updated: 22/Jan/17  Resolved: 13/May/10

Status: Closed
Project: phpBB3
Component/s: User Control Panel (UCP)
Affects Version/s: 3.0.6
Fix Version/s: 3.0.8-RC1

Type: Bug Priority: Minor
Reporter: schnorrer42 Assignee: Andreas Fischer
Resolution: Fixed Votes: 0
Labels: None

Attachments: PNG File yourdomain.com • Index page_1270768383620.png    
Fix URL: http://github.com/bantu/phpbb3/compare/ticket/9526

 Description   

Hi,

Trying to hide a single bot from displaying in Who's Online. I tried modifying the user preference for that bot to hide online status, but the change makes no difference. The bot appears normally to mods and to guests as well.



 Comments   
Comment by Andreas Fischer [ 08/Apr/10 ]

Make sure the bot has the permission to hide from the who is online list.

Comment by schnorrer42 [ 08/Apr/10 ]

I did change the group's permission to allow to hide status, and then I also changed the individual bot's permission to hide online status. Sorry I hadn't mentioned that.

Did you try and were you successful?

Comment by narqelion [X] (Inactive) [ 09/Apr/10 ]

Unable to reproduce. After allowing Bots group to hide online status via the permission setting and setting specific bot(s) to "hide online status" under user preferences the bot is correctly hidden from view for normal users. Admins/mods with the permission to view hidden users can still see the bot, its name italicized to indicate a hidden user.

Comment by Andreas Fischer [ 09/Apr/10 ]

Dito, works for me too.

Comment by schnorrer42 [ 09/Apr/10 ]

About 8 hours after the changes were made, I actually saw the bot on the forum as "normal", then disappear for a minute, then reappear as hidden.

Apparently the permission changes and the user preference change does not take effect until the user's session has ended and a new session begun. Which is an issue with a bot that refuses to go away .

Does not applying to the current session constitute a bug?

Thanks for all your hard work and especially your attention to this very minor issue.

Comment by Andreas Fischer [ 09/Apr/10 ]

I'll reopen this. But I am pretty sure there is a reason why it only works when a new session is generated.

Comment by narqelion [X] (Inactive) [ 09/Apr/10 ]

Schnorrer42 wrote:

Does not applying to the current session constitute a bug?

No it does not. The reason is because the ability of a user to hide (cloak) their online status is checked at session creation/login. There are several other user settings/permission changes that also require a new session to take effect so this is completely logical behavior.

Comment by Joas Schilling [X] (Inactive) [ 10/Apr/10 ]

btw, this also is the case for normal users, not for bots only.

Comment by schnorrer42 [ 10/Apr/10 ]

Perhaps the default behavior should be to update the session?

Like I said b4, thanks for even pondering this completely innocuous issue.

Comment by narqelion [X] (Inactive) [ 10/Apr/10 ]

Perhaps the default behavior should be to update the session?

No it should not.

Comment by schnorrer42 [ 10/Apr/10 ]

Then a message needs to be sent that says the preference changes won't take effect until the next new session.

Your response is a little terse; why would it not be a good thing to update hide/unhide preference on the fly? Even if there are some other changes that absolutely require a new session, why would this one?

Thanks!

Comment by narqelion [X] (Inactive) [ 10/Apr/10 ]

Then a message needs to be sent that says the preference changes won't take effect until the next new session.

It does, I assume you have a basic familiarity with your UCP? If not, then perhaps you should spend some time getting acquainted with the application interface:

Hide my online status:
Changing this setting won’t become effective until your next visit to the board.

You overrode the Bot's user preference via the ACP, however that setting is the same exact setting that is in the UCP UI for every single user, including yourself therefore you should already know that the setting does not take effect until the next session.

Your response is a little terse; why would it not be a good thing to update hide/unhide preference on the fly?

You have it a bit backwards...why would it be a good thing? As the instigator of a change request the burden is on you to provide sufficient cause/data to support changing the current implementation. I am simply disagreeing with you that the behavior should be changed.

Comment by schnorrer42 [ 10/Apr/10 ]

I've been nothing but respectful, pleasant and appreciative, but it appears you want to take potshots and argue, which is not fun. I fully value your opinion; there is no need to belittle me or be argumentative to pass along info or to make your opinion known.

I feel the reason it would be better is self-evident. If a user wishes to hide their status or to become visible, I feel it is much more likely than not that they want it to happen right away, not be forced to logout and login. In my situation, the only way I could change the appearance of the bot would have been to truncate the sessions table or temporarily ban the bot or manually alter the DB thru SQL. Unless I missed a "log out this user" option which is always possible.

If you don't agree that is fine; feel free to close this ticket. It's a very minor issue that is not worth the impact on our respective karmas.

Thanks!
S42

Comment by narqelion [X] (Inactive) [ 10/Apr/10 ]

My karma is just fine, thanks for worrying though.

Nobody, least of all me is taking any potshots at you, however arguing(aka debating) the point at hand is exactly what occurs when someone is proposing a change to functional behavior. If you are not up for that debate then perhaps suggesting changes is not something you should engage in. The reality is I simply pointed out the facts to you when you requested that explanatory language be added that already exists.

I feel the reason it would be better is self-evident.

Again, I explained to you what was expected from you as the instigator of a change request, you need to provide sufficient reason why the existing behavior is undesirable and the proposed behavior is somehow better. "Self-evident" doesn't help you with that. That assumes no proof or explanation is required to support the proposition. When you are trying to convince someone to change something you cannot assume they have the same perspective as you or that anything is "self-evident" to them, you need to make a case by fully detailing why the current behavior is wrong and that the positives of the proposed change outweigh any negative consequences of making the change.

Emotion (such as getting defensive, embarrassed or angry) has no place in this process, it should involve nothing other than reasonable arguments based on facts and logic.

Comment by Andreas Fischer [ 10/Apr/10 ]

The UCP seems to work a bit different. If you set it to 'hide' it will change your session to hidden immediately. Changing it the other way around does however only take effect after a new session is generated. This is because of the fact that you can also create a hidden session when logging in.

Comment by schnorrer42 [ 10/Apr/10 ]

I forgot to add that the ACP and the UCP have inconsistent verbiage for the exact same option; they should be consistent, not dependent upon the admin remembering the verbiage on an option I've never used, not having been interested in hiding MY online status before.

Very nice reply; several paragraphs of argument unrelated to the actual issue after I suggested you to stop being confrontational.

QED

Comment by Andreas Fischer [ 10/Apr/10 ]

I agree with Schnorrer42, there is definitely an issue.

Comment by narqelion [X] (Inactive) [ 10/Apr/10 ]

The UCP seems to work a bit different. If you set it to 'hide' it will change your session to hidden immediately. Changing it the other way around does however only take effect after a new session is generated.

Then it is broken again(or still) as that behavior used to exist prior to 3.0.4/3.0.5 Neither value for that setting is supposed to take effect until a new session is generated, regardless of whether it was toggled in the UCP or the ACP. You cannot have the "On" value take effect immediately without having the "Off" do so as well. They have to behave consistently so it's either both or neither.

I forgot to add that the ACP and the UCP have inconsistent verbiage for the exact same option; they should be consistent,

They do not have inconsistent verbiage, the explanation text exists only in the UCP IU for the setting, no duplicate language exists in the ACP UI for the same setting.

they should be consistent, not dependent upon the admin remembering the verbiage on an option I've never used, not having been interested in hiding MY online status before.

There is no inconsistency in the language, there is no duplication and for very good reason. When a setting exists in multiple UI paths there is no need to clutter valuable UI real estate up with redundant explanations.

Comment by narqelion [X] (Inactive) [ 11/Apr/10 ]

bantu wrote: The UCP seems to work a bit different.

Actually bantu, it appears the UCP & ACP both behave the same (so both are broken) on the latest release. Changing a non-bot user's online status to hidden takes effect immediately when done from either the UCP or the ACP. Changing it back to visible does not work from either UI, the session is only updated going from visible -> hidden.

Bots are not the same as regular users and as far as sessions go the following design seems to explain why the OP experienced the behavior they did:

// We give bots always the same session if it is not yet expired.

Comment by schnorrer42 [ 11/Apr/10 ]

Why must you take a contrary, confrontational position when faced with the obvious?

From ACP:
=========================================================
Allow users to send you private messages:
Note that administrators and moderators will always be able to send you messages.

Hide my online status:
[blank]

My date format:
The syntax used is identical to the PHP date() function.
=========================================================

From UCP:
=========================================================
Allow users to send you private messages:
Note that administrators and moderators will always be able to send you messages.

Hide my online status:
Changing this setting won’t become effective until your next visit to the board.

My date format:
The syntax used is identical to the PHP date() function.
=========================================================

That is not consistent.

By your argument, all instructions and verbiage should be removed from the ACP forcing admins to navigate to the UCP to ensure they are meeting the requirements of the option. That is preposterous and only goes to show that you'll continue your obstreperousness with anything once you've staked your position, no matter how absurd and in the face of overwhelming evidence to the contrary.

Or perhaps the potshot you directed towards me ("I assume you have a basic familiarity with your UCP? If not, then perhaps you should spend some time getting acquainted with the application interface") should have been directed to yourself?

Comment by narqelion [X] (Inactive) [ 11/Apr/10 ]

Why must you take a contrary, confrontational position when faced with the obvious?

I am going to say this one last time, and if you still cannot refrain from overreacting and letting your emotions override reason, I will simply ignore any further comments you direct at me. There is no reason to attack me personally because I do not agree with you.

That is not consistent.

Yes it is. The fact that no redundant language exists in the ACP for the online status field is not inconsistent. Inconsistent would be if language existed that contradicted the UCP language, such as "Changing this setting will become effective immediately." <- That is inconsistent. The existing UI actually demonstrates good design by following two specific UI design principles:

1. Remove redundant text

2. Do not explain the obvious (aka over-communicating)

By your argument, all instructions and verbiage should be removed from the ACP ...

All redundant, superfluous supplemental language, yes definitely. The ACP UI is by far the worst aspect of the whole application when it comes to UI & usability design. You could take a machete to it and that still would not get rid of everything that needs to get stripped out of there.

You seem to be advocating for supplemental text added for every UI control application wide, regardless of whether it already exists for the same control in another place. I would rather you read the documentation rather than clutter up my valuable screen real estate.

There is really only one scenario that would justify adding supplemental text to the same control in multiple windows, and that would be if different language had been used for the control(field) description, i.e.:

In the UCP it displayed as Hide my online status: and in the ACP it displayed as Hide user's online status: which of course it does not as that would be another example of bad UI design. The fact that the exact same language string was used for the control universally means it should not have to be explained with supplemental text outside of the main control window, which for that control is the UCP, as it is fundamentally a user preference.

Comment by schnorrer42 [ 11/Apr/10 ]

"I am going to say this one last time [blah blah blah]..."
Whassa matta, you don't like your self-forgotten potshots returned? You started with the insults, not me, which you continued in a completely ad hominem post after I asked you to not be so disagreeable, especially over something so completely trivial.

In my experience, it is users like you that kill communities; many users who might have become contributors will just take your abuse once and walk away allowing you to run roughshod over your little fiefdom. phpBB would be well advised to understand the impact you have on their community and weigh your contributions against the harm you cause.

Ta ta.

Comment by A_Jelly_Doughnut [ 11/Apr/10 ]

Here's how the "hidden" setting works:

Users can choose to be hidden for all time in the UCP (or an admin can choose this for them in the ACP).
Users can choose at login time whether to be hidden just for that session. If the user has multiple open sessions, the most restrictive hiding setting is used.

So:
When a user changes the permanent setting in the UCP to "hide me", we can easily resolve what the user wants by setting the current session to hidden, regardless of what other sessions may be doing.

When a user changes the permanent setting in the UCP to "show me", we cannot easily resolve what the user wants because the current session is set to hidden, and we cannot determine whether the "hide me for this session only" checkbox was checked at login time based on the data available.

Thus there is not a bug when going from "hide me" to "show me". And, per narqelion, and the code itself, there is no bug when going from "show me" to "hide me" when the user is not a bot.

This is the ''intended behavior'' of the switch. See http://code.phpbb.com/projects/phpbb/repository/revisions/7755 for when it was changed.

So that leaves us with the following issues from this ticket:
(a) Inconsistent explanatory text
(b) Bots whose session handling is not equivalent to regular users.

Regarding (a):
If an explanatory text is important enough to be included one place in the UI, it should be important enough to be included everywhere the same interface is presented. This is how phpBB generally does things, for better or for worse.

Regarding (b):
I don't see any reason to fix this behavior in 3.0. It would be good at some point in a future version to make bot sessions more congruous with regular sessions, though.

Comment by Andreas Fischer [ 11/Apr/10 ]

Since bots cannot create hidden sessions when logging in, why not change it so the action takes effect immediately for bots.

Comment by narqelion [X] (Inactive) [ 11/Apr/10 ]

A Jelly Doughnut wrote: Thus there is not a bug when going from "hide me" to "show me".

You are correct it is not a bug since you intended the behavior, however it is a massive design failure. The immediate update of the session for toggling 'hide me' On should never have been allowed. The only way that is acceptable would be if the Off setting worked the same way. If you look at the revision changelog you linked to, the description of the feature itself is wrong,

[Feature] Make effect of a changed hideonline permission instantaneous

Fail. Quite obviously the effect is not instantaneous for the whole setting, as setting it to 'Off' requires a new session.

A Jelly Doughnut wrote: So that leaves us with the following issues from this ticket:
(a) Inconsistent explanatory text

Yes now indeed you have inconsistent supplemental text (because the text states "Changing this setting won’t become effective until your next visit to the board.") which is no longer accurate so long as the current design exists. As such the text needs to be removed from the UCP -> Preferences UI.

A Jelly Doughnut wrote: Regarding (a):
If an explanatory text is important enough to be included one place in the UI, it should be important enough to be included everywhere the same interface is presented. This is how phpBB generally does things, for better or for worse.

I really hope you are not saying here that just because phpBB generally does things a certain way, good or bad, is a reason to not change the bad ... So you would keep going down the wrong road even after you found out it wasn't going to take you where you want to go? I know you do not have any designer or usability skill sets on the development team (per Meik) but you can avail yourself of numerous resources available to correct the many problems that exist already, and commit to not escalating the bad design practices by adding to them. I thought you (as a project) had already committed to overhauling the existing ACP for Ascreus, did that go up in smoke already?

Comment by A_Jelly_Doughnut [ 11/Apr/10 ]

I really hope you are not saying here that just because phpBB generally does things a certain way, good or bad, is a reason to not change the bad

It is as long as we're talking about changes involved in a minor version.

And you're not reading or understanding what I'm saying.

... we ''cannot determine'' whether the "hide me for this session only" checkbox was checked at login time based on the data available.

To say it another way, we choose the least permissive option in the case that the user has provided potentially conflicting input.

There is nothing about this that constitutes a "massive design failure".

Comment by narqelion [X] (Inactive) [ 11/Apr/10 ]

It is as long as we're talking about changes involved in a minor version.

As I said above,

. I thought you (as a project) had already committed to overhauling the existing ACP for Ascraeus, did that go up in smoke already?

I was referring to Ascraeus 3.1. Afaik that is not considered a minor version. Or is it? Not sure you understand what I am saying either as far as escalating commitment so let me try this, if you have already stated the intention to change specific UI design & behaviors of 3.0.x in 3.1 why would you continue to add to the UI of 3.0.x things you will only undo for 3.1?

And you're not reading or understanding what I'm saying.

I understand exactly what you are saying and exactly what the code is doing. What I am saying is that from a Usability perspective (aka the user trying to use the control in the UI) the design fails. Imagine yourself a new user bopping around in the UCP giddily clicking on radio buttons as you explore your user settings. Ooops! you just set hide online status to 'Yes' and you didn't mean to. Ok no problem you'll just set it back to 'No' right? Wrong, doesn't work, you are still hidden. "WTH you think....if I turned it on how come it won't turn off the same way? Now I have to logout and back in just because I clicked a wrong button on the preferences page?!" <- no other way to look at that scenario than as a design failure. You have to remember to view the issue from the perspective of the user trying to use the widget you have supplied.

Comment by A_Jelly_Doughnut [ 11/Apr/10 ]

You have to remember to view the issue from the perspective of the user trying to use the widget you have supplied.

This is exactly what is being done.

User: "I checked the box that said hide me until I log out and then I went and changed the preference that says no longer hide me on a permanent basis. I'm now visible. wth?"

The current behavior is in line with the general way that phpBB works - the principle of least permissions.

Not sure you understand what I am saying either as far as escalating commitment so let me try this, if you have already stated the intention to change specific UI design & behaviors of 3.0.x in 3.1 why would you continue to add to the UI of 3.0.x things you will only undo for 3.1?

I can't see the future, and would not know if any single specific change would be undone in that future, or not. Might as well fix it now if its broken.

Comment by Andreas Fischer [ 12/Apr/10 ]

The code that updates the session table when setting it to 'hide me' is actually in $user->setup();, not in the UCP and/or ACP. This means that the session table is not updated until the user (or bot) himself refreshes the session (visits the board). This also explains the different behaviour between ACP and UCP.

In the UCP this is not a problem because $user->setup() is called right away when reloading the page. Things like "let me set your session to hidden" however do not work from the ACP, which might also cause unexpected behaviour.

In my opinion the ACP page should also update the session when setting user's settings to 'hide me'. And it should also update the session table when setting it to 'show me' if the user is a bot.

Comment by narqelion [X] (Inactive) [ 12/Apr/10 ]

A Jelly Doughnut wrote: we ''cannot determine'' whether the "hide me for this session only" checkbox was checked at login time based on the data available.

You are scopelocked on the wrong thing, you do not need to determine whether the user is hidden because of the "..for this session only" checkbox, that is completely irrelevant all that matters is what state the user is in, hidden or visible. If the user is hidden and they select Hide my online status = No then they should become visible. If the user is visible and they select Hide my online status = Yes then they should become hidden. How they got to whatever state they are should never factor into the ability to change from one state to the other using the same steps.

AJD wrote: User: "I checked the box that said hide me until I log out and then I went and changed the preference that says no longer hide me on a permanent basis. I'm now visible. wth?"

User: "I checked the box that said hide me until I log out Hide my online status this session and then while still in that session I went and changed the my user preferences that says to no longer hide me. on a permanent basis. I'm now visible. wth? Success!"

bantu wrote: In my opinion the ACP page should also update the session when setting user's settings to 'hide me'.

@bantu, the testing I did showed that it already does.
me wrote: Actually bantu, it appears the UCP & ACP both behave the same (so both are broken) on the latest release. Changing a non-bot user's online status to hidden takes effect immediately when done from either the UCP or the ACP.

Comment by A_Jelly_Doughnut [ 12/Apr/10 ]

that is completely irrelevant all that matters is what state the user is in, hidden or visible.

I disagree, because that would be ignoring user input, especially in the case that the administrator changes the setting. I agree that there is ambiguity in the case I cited - the user has provided conflicting input, and the way we handle it now is (again) the principle of least permissions. Your "corrected" example violates that principle, and should not be implemented for that reason.

me wrote: Actually bantu, it appears the UCP & ACP both behave the same (so both are broken) on the latest release. Changing a non-bot user's online status to hidden takes effect immediately when done from either the UCP or the ACP.

Changing a non-bot user's online status to hidden takes effect on the user's next page load, not immediately.

Comment by narqelion [X] (Inactive) [ 12/Apr/10 ]

I disagree, because that would be ignoring user input, especially in the case that the administrator changes the setting.

You are already ignoring user input, my example shows that explicitly. My proposed implementation removes that behavior and again puts the user (or admin) back in control of their own choices.

Use case example #1:

User chooses to login and for whatever reason (the reason is irrelevant it is simply the users choice at that point in time) they check Hide my online status this session, so they enter that session as a hidden user. Let's assume 10 minutes go by and User is now in their UCP board preferences and decide they wish to unhide themselves. They set Hide my online status: to No but they remain hidden. The application is taking it upon itself to ignore the latest user input in favor of older user input as if the application presumes that it knows what User wants more than User does. What rationale are you basing that behavior on? How can you assume that a User choice made 10 minutes earlier should be honored but the most recent input should be ignored? If they had the freedom to turn something on that they now wish to turn off, who is the application to say they cannot?

Use case example #2:

User chooses to login and for whatever reason (the reason is irrelevant it is simply the users choice at that point in time) they do not check Hide my online status this session, so they enter that session as a visible user. Let's assume 10 minutes go by and User is now in their UCP board preferences and decide they wish to hide themselves. They set Hide my online status: to Yes and voila! they are hidden. The application is now choosing to honor the latest User input(to hide) and ignore the older input (not to hide) so why suddenly does the application think the User can make such a choice? If User made a conscious choice to not hide their online status for that session, why should they get to change their mind when they cannot if the opposite were true?

There is no conflicting input, there is simply older input being overridden by newer input. The most recent user input is what should be honored, in any workflow. The existing behavior ignores current user input when it comes to 50% of the functionality of hiding your online status. My illustration of the correct behavior ignores no user input and makes the existing functionality work 100% of the time. If these last two examples (the use cases) do not illustrate the discrepancy in the existing behavior, I fear nothing will.

I have no idea what you mean when you keep saying "principle of least permissions" because in this scenario the state requiring the least level of permission is being visible. In order to hide you must have explicit permission set to do so, therefore a higher level of permission. Since no permission is required to be visible and it is the de facto state of all users, the ability to make oneself visible should always possible.

Changing a non-bot user's online status to hidden takes effect on the user's next page load, not immediately.

Immediately in that context was as in "not requiring a new session", a page load is required to update the existing session regardless of whether the user does it via the UCP or an admin does it via the ACP. When the user does it themselves the actual submission and subsequent page reload in the UCP takes care of updating it. When the admin does it via the ACP they have to wait until the user does something, might be a bit delayed if the user is sitting on one page but it does get updated when done via the ACP, without a new session.

Comment by A_Jelly_Doughnut [ 12/Apr/10 ]

The "principle of least permissions" I keep referring to is simple: if the user provides two conflicting inputs, we use the one which gives other users the least permissions. Here, if a user requests to be hidden for the duration of the current session, and then requests to be un-hidden in the future, the application chooses to keep them hidden until the "future" (a new session) arrives.

There is no conflicting input, there is simply older input being overridden by newer input.

This would be the case if the two inputs were to the same question. They are not. The checkbox on the login screen explicitly says "hide my online status this session". The UCP option explicitly says that it does not take effect until a new session begins (even though that is not entirely true, and could/should be addressed).

But I don't think I can be moved from the position that the current behavior is essentially correct.

Comment by schnorrer42 [ 12/Apr/10 ]

How about a "Hide me now"/"Make me visible now" option on the two CPs?

Comment by Andreas Fischer [ 13/Apr/10 ]

Here is some code for what I suggested earlier. http://github.com/bantu/phpbb3/commit/c09cb1390dec0e1690509f03ecf35a78d214f8d5

Comment by stevemaury [ 13/Apr/10 ]

test comment

Generated at Sun Nov 18 00:12:23 UTC 2018 using JIRA 7.9.2#79002-sha1:3bb15b68ecd99a30eb364c4c1a393359bcad6278.