Depends on the law, though often gov and corporate heads and IT stuff think they can do anything, because this is their property. Property it is, but they dont automatically have rights to see someones private data. There is a directive in Europe Union about privacy at workplace. It defends employee privacy and employer can have hard times when violating that (there should be an agreement with employee always). There are already some examples of such cases in courts. In Finland heads of some company were sentenced to pay fines and even to jail for collecting phone calls data of their employees (only the numbers and durations of calls).
I would like to see spark force users to fill out the vCard on initial login if they created their account on a non-LDAP install of openfire. Rosters depend on the nickname field which is not present until the vCard is completed.
Some users will not want to be forced into entering any information they don’t want to, also Spark would not know if the server is LDAP or not. We can’t force users into doing anything they don’t want to. I really don’t think this should get into Spark, it’s upto the user to fill it in or not, not based on what type of database/backend the server is running.
I actually like that idea… If spark would query the server to see if “force vcard” is set, and then act according to what the server is set to, that would be cool. You know… I under stand that in a “open” community, you don’t want to force people to put in personal information. But many of us are running spark in a private setting, business, education, whatever and a feature like this would be valuable to us.
Wayne
added… granted, most of us could be running ldap too, but as an addition to this idea: If the proposed “Force Vcard” did exist, it would be awesome if it would “Write” the changes to existing ldap accounts.
I’d like to see a force client upgrade from the server end. For example, new client version comes out and rather than click every client to check for updates you can force an upgrade via the server and have it install from the server rather than download the client each time from the web on each computer.
I don’t think this is very appropriate really, forcing the user to do anything isn’t a good idea. It should come down to the user to upgrade, we can only advise them to.
I’m thinking more from an IT Administrator’s corporate enviornment scenario.
In reality this software is used in more than just Enterprise/Company environments, this software is also used on personal computers connecting to public servers. And this could pose a danger to them.
epritchett wrote:
I’m thinking more from an IT Administrator’s corporate enviornment scenario.
IT Administrators has other ways to do corporate wide upgrades (GPO, MSI, scripts, etc.)
That’s why you would put a “Allow automatic update” option in the preferences, with it defaulted to allow… Just like so many other programs do… This way, when we in the corporate/education world can update it automatically, but clients who are not in those environements can choose to disable the automatic updates… But most won’t… Why, because most people are too lazy to think about updating their software and actually like it when it does it automatically. But those rare catz that don’t like it can shut it off… Doesn’t seem that hard to me.
Wayne
All of which are a pain in the butt compared to the feature being built into the software. I guess I just don’t see the problem. All the major IM services have automatic updates built in. Some even do a good job of hiding the option to shut it off… Yet people still flock to use them…
I understand that spark is one of the LEAST annoying IM clients in existance and I understand that we all want it to stay that way, but this is a good idea that should not discounted so lightly. Privacy and end user chioce can easily be addressed by adding it as an option as I stated in an earlier post. And just because there are other ways sys admins can accomplish the upgrades, doesn’t mean this feature shouldn’t be added.
just my 2 cents,
Wayne
I see nothing wrong with the current method, Spark does currently ask the user if they want to update. Realistically people could add malicious code that could cause problems for the user and their computer.
That’s because they pull their software from their servers in terms of updates, whereas Spark will try and update from the server it’s connected to, and if the server, like i’ve said decides to push out malicious code then severe problems can be made.
I would say that most clients have the ability to check for updates and provide an option to download and install, or link out to the site. I have yet to come across one that automatically downloads and installs with no interaction. I personally would never wish this to happen to me or even my worst enemy. This is how malware speads. The Client control plugin is fine for me, combined with AD Group policy to push new versions.
So what’s the difference between an upgrade/update and a customized Spark client that someone builds and put on their site for their end users to download and use? Just as much threat to them as the updates would be. More if you ask me.
And just exacly why couldn’t it be hardcoded to get the update from the ignite site, instead of the server it’s connected to and also have the option to override it with a “trust the server I am connect to for updates” option? You know, just in case the IM server is actually trustworthy!
I mean, this is supposed to be about enduser choice, right?
Wayne
whooa… I never said that there shouldn’t be interaction… I have no problem with the end user being prompted to allow the updates. As well, the prompt probably should have information from the sys admin, like the origin of the update, the reason for the update, version#, etc. I have absolutely no problem with that at all. As a matter of fact, I would consider an additional benefit for sys admins.
Wayne
added: sorry for the confusion… I didn’t even think about the “lack of interaction” as part of the original idea as I would never have even considered that a possibility, because this software is so multipurpose as stated earlier, it’s not just for corporate/educational use. I guess I missed the boat on that one. But I still think that with the proper prompts and options in the preferences, that it is a good idea…
Errica,
I really hope that if you get a custom plug-in that accomplishes this, that you will release it to the community… I can actually see where this could be a valuable tool for many offices… I wish I could do it, but sadly I am not a programmer…
Wayne
Speaking about prompts. Many users will likely press Skip / Cancel / " I dont care, stop bothering me with your “important” computer stuff". So, with prompts we are getting at starting point. If i were asking my users to update Windows themselves, most of my computers will be with old software and vulnerable. So i’m pushing updates centrally without prompts (well, they can select Install and Shutdown) and setting deadlines, so the software will be installed without choice and on time. So admin pushing of update via AD seems more appropriate to me. Especially that you can do it anytime when PC is connected to AD (on startup, without bothering user), and with Openfire control user will have to connect to Openfire.
Speaking about the MUC, i sometimes miss PSI feature to put a line before unread messages. Now, when my muc window in Spark is not focused and there are new messages, there is no way to distinguish them. Some separator for unread messages would be cool.
How about idle times? Can Spark show idle times of contacts (on Openfire server and Gateways too would be nice). I know that my spark sets me away after XX minutes, but every just sees that I am away, not how long I have been away.