Thanks for the request. It almost follows the guidelines so we'll consider. A few questions.

1. Should there be a user privacy setting for "Show in online activity search results" or some such thing. Needs better wording so please feel free to give suggestions.

2. Does it need an admin setting to "Show staff in online activity search results" as some sites actually hide staff. 

Anything else that might have been missed?

ITLJames said:

It was my first request

Best to use the stickied guidelines that are at the top of the feature request area to help structure the requests as it does help. It was still a good request.

1. I would think wording could be something like "show most recently online" - then have it sort as such descending... In essence it is just a sort feature. I wouldn't want to see when people were online though as I am sure everyone has members in their database that are 1 hit wonders.

I meant user privacy permissions.

2. For me, no; I want my staff reachable. But I would expect that it should apply privacy settings from the rest of the site and respect hidden members.

gs said:

That makes sense to me because I believe in most things having at least an ADMIN setting (to allow each ADMIN to determine what they want for their site, not SE or any dev), and then some of these to allow the User an option.  I guess I think that many (most?) functions/features should have the following minimum in ADMINcp:

• Enable (for all)
• Enable, but allow User to make their own setting based on ML
• Disable (for all)

This provides ADMIN with control of their site, not the software dev.  Plus it (optionally) allows the User to determine what's best for them.  Flexibility is key to me, and no non-custom developed software company should have the audacity to think they know everything about what I (or the Users) want for my site, or what's best.  This reminds me of the auto-save feature (not auto-backup, that's another whole discussion) becoming more prevalent in recent years.  If the software has a setting to enable/disable then great, otherwise their 'helpful' is often a major hassle.

Remember, software devs also have to consider site load and issues. For example, another script added a feature that clients wanted even though they knew it was a bad idea because clients were upset that it hadn't been added before. Adding that feature destabilized the feed and caused data loss. Best to do two things:

1. Consider client requests and investigate if they can be implemented without harming the overall core product.

2. Investigate whether that implementation will be detrimental to the overall site load and performance. If so, it's not something that will benefit a lot and will end up harming a higher percent of clients. In that case, it's best to leave it to third party experts so that clients who want that high load and cost can choose to do so without messing up the higher amount of clients who don't want that. 

So, remember not to think of a software company as the enemy here. We have a lot to consider when looking at feature requests. If we don't add something, there is a very good reason for that. It's not just to be mean or controlling. Developers LOVE to code. It's what they do. They spend a LOT of time researching new code, learning new techniques, reading about latest security issues and code standards, etc. There are also limits to what mysql, php, etc can do without breaking other things or requiring server updates that may break other things. 

Look at what happened recently when a client updated their server to PHP 7. Their site broke. Not due to SEPHP, due to their third party plugins that won't work in PHP 7. We have to consider everything when considering a feature request and what settings can or can not safely go in that request.