So, I see that the Client Control plugin has been updated to allow disabling of the Login As Invisible option, but

…what I’d really like to see is the ability to disable the Invisible status altogether.

Right now, this option only disables the initial invisibility of a user, and doesn’t prevent them from selecting it as a status after login.

Seems kinda pointless to me.

The effect is small, but hiding a checkbox in GUI is a rather easy task compared to redoing the status management code. Spark and other projects here are open source driven by volunteers and Spark doesn’t have much attention from the experienced developers. Patches are welcome.

Personally i find it useful to have it hidden on the login screen as some of my users were enabling it accidentally sometimes by hitting all the checkboxes. They rarely change their status in the running program, so less accidents here. And when you login online and then change to invisible, someone can still see you online for a brief moment

My users never see the login frame. Not the way I have things set up. They log in automatically and that effect is non-existent.

The Invisible Status didn’t even exist until fairly recent versions of Spark/Openfire. And in it’s current incarnation it’s just… buggy.

Sure, it “hides” your status, it also interferes with incoming messages. If we can’t make it cease to exist, I’d rather see it become “optional”- and from an Administrative standpoint, not a user’s.

My users are setup to auto-login also, but if you log out (not exit) the Auto login checkbox will be deselected. I sometimes find such case among my users (they have logged out at some point for some reason, maybe wanted to restart Spark). As i’ve said the effect is minimal.

Invisible state has been added since 2.7.0, which is more than 1.5 years old (actually it was in the source even before that, but there was nobody to move Spark project forward and no releases were made https://issues.igniterealtime.org/browse/SPARK-1526). Spark is a xmpp client. Invisible presence is defined in xmpp standards XEP-0126: Invisibility . It has some issues (though i think main quirks have been fixed in the latest version). But the thing that it is visible to users is not a bug. This is a feature. The thing that it can’t be disabled by administrator is an inconvenience, i agree. I will file a ticket for that, but it won’t be removed.

[SPARK-1868] Add an option to disable Invisible presence - IgniteRealtime JIRA

I have assigned this to me and will try to look at it maybe this weekend. But i’m not a developer myself, so it might be out of my league. Then we will have to wait for some developer to contribute a patch.

Btw, i can receive messages while being Invisible.

Well, returning to the matter of what the ClientControl plugin can/can’t do: you can disable log-out (I have).

So again, in 98% of cases, a user of mine isn’t going to see that frame- and in the other 2, the systems administrator (me) is already involved (because he’s setting someone up newly, usually).

I have a decidedly non-technical userbase that I will say is “selectively-intelligent” when it comes to this stuff- which is a polite way of saying “observant enough to cause trouble”.

And in every test I’ve done, an invisible user may as well be an offline one. Messages won’t go through- or at least the (invisible) user sees no indication they were sent at the time they were sent.

Which I find somewhat sad seeing as that’s something DND status should do and seemingly doesn’t.

I appreciate you putting in the ticket. Thank you.

Yes, you can disable Log out menu. I haven’t disabled that yet, as i may need to log out sometimes.

That’s strange. Are you using 2.8.3 version? I’ve just tested this and after switching to Invisible my priority stays ‘1’ and i can receive messages. When you switch to Invisible does your priority value change (check in Admin Console)?

Yes, DND should not let messages though in my opinion, but it was initially done this way by JiveSoftware (indicative only). There is a ticket for this [SPARK-1026] Should queue new messages in Offline storage when in DND mode - IgniteRealtime JIRA and i have tried to change that once, but it wasn’t as simple as i first thought. Spark is lacking strong Java developer working on it.

Spark 2.8.2. I’m assuming 2.8.3 must be a beta, as I don’t see it in official announcements. I have a minor revisional update to do on Openfire as well though. Perhaps that’s to do with it.

I don’t necessarily mind looking for users in the “Offline” group. I mind not being able to send those users messages in a way they’d notice. Still, being able to control available statuses seems like a thing that would be broadly useful. I seem to recall people complaining about misuse of the Custom status indicators, as a for-instance.

As for the rest, I figure I can force-kill Spark from task manager if I have to- though the ability to define ClientControl profiles by User Group would sure be handy as well.

My bad. 2.8.2 is the latest. As i work on 2.8.3 now it has mixed in my head

Anyway, i can’t reproduce this on Openfire 4.0.4 and 4.1.1. I’m using latest 2.8.3 build, but there is nothing related to presence or privacy settings in the changelog. That must be something else. Probably specific to your setup. What version of Openfire are you using?

I do get a warning on the other side, that my message will only be delivered when the users gets online (the other side thinks the user is offline). But i do get messages right away when i’m invisible. Wonder if anything is logged in the logs on the invisible user’s side, if he doesn’t get the message (C:\Users\User\AppData\Roaming\Spark\logs). And you can also try enabling the debugger (in Advanced settings) and see incoming raw packets to see if the message is actually coming through, but Spark is not showing it in the GUI for some reason.

Openfire 4.0.4. The 4.1.1 is the last update I have to apply, and haven’t yet.

I see nothing in the logs clientside. Nothing even very recent, for that matter.

All I know is I’ve got a couple users who like to hide while here. One of them I needed to communicate with and figured I’d send him a message anyway. I was remotely looking at his desktop and watching the messages not appear. And I’ve seen this kind of thing before.

This issue has been fixed and will be available in Spark 2.9.0. See: https://issues.igniterealtime.org/browse/SPARK-1868