CoffeeCake

Why not? What are you trying to integrate?

FINE... 😁 https://invisioncommunity.com/third-party/providers/

This looks like the out of the box theme, as @Pete T pointed out, with some adjustments in the theme settings, however I will gladly take $500 to match it exactly. Edit: Oh you wanted references. @Jordan Invision vouches for my gladly taking $500 from you.

The obvious answer from support will be to see if upon disabling all those applications and plugins, the issue is resolved. You may want to try that first, or list out the plugins and applications you have (and/or the hooks they are inserting into). If you've had something for years, and the handling of invisible users has changed recently, it's possible something that had no impact on versions prior to 4.5 is now having an impact.

It seems very possible. Do you have any third party plugins or applications installed?

No need to apologize. It seems an oversight that the guide doesn't mention the limitation, or consider all the possible scenarios and provide solutions for each. Primary membergroup only Secondary membergroup only In group(s) and also not in group(s) In any group, regardless if primary or secondary @Jordan Invision who will either be sick of me or get a raise or both.

Think about what makes a community successful and how a person without the experience of managing and administering a community might not have that innate knowledge. Onboarding both members and administrators. Start with the basics. The Help Guides tell you what options there are, but they don't help guide the important factors to consider when thinking about what a setting should be or how something should be configured. Draw connections between what your goals may be with your community, and the configuration decisions that best enable getting there. A new administrator too often will enable something or configure something because of the technical novelty of it. A good recent example was the thread statistics sidebar. Just because something is there doesn't make it useful or appropriate when considered in line with the culture and direction of a community. The successes of communities and the ability for IPS to translate features into culture only serves to increase the successes of the company and its clients.

Good job, @DawPi. This should be out of the box functionality.

As an untested example, while I fully pay attention in the first droning Zoom meeting of the day: {{if \IPS\Member::loggedIn()->inGroup(4,5)}} Members with secondary or primary group IDs of 4 and/or 5 are cooler than all the other members. Pass it on. {{endif}}

See the solution in this comment in reply to that guide (inGroup):

Clearly you don't appreciate iMessage as the defacto standard interface for business and technical communication. Must be a discerning gentleman of an Android guy. Like myself.

Another addition to the Commerce Support tool that I was just reminded of. The ability for an agent to receive notifications of new requests or replies should be a controllable permission as well. For communities where moderators do not have a site-specific e-mail account, receiving copies of inbound communications in their personal e-mail account is a liability, and not every moderator meets the threshold for an e-mail account. If your model is that moderators do not have access to PII, and do not e-mail customers, then it makes little sense to provision them with an e-mail account.

Wordpress is at a level of saturation that on a completely different plane of existence than IPS. I've been involved with very large online learning platforms in the past, and were I thinking about an LMS today that needed a community component outside of the classroom, I'd be looking at an established option and focusing my energies on integration of the sign-on/session process and theming with IPS. I'm not sure what you're creating your course content with, but there are a few standards (SCORM, AICC, etc.) and serious commercial and open-source players in the LMS market that are best-in-class experiences and used at for-profit and not-for-profit institutions globally. Any one of them likely has a larger userbase than IPS. This is a wheel I would need serious motivation to try and reinvent. If you have a need for this, it's very likely you have a dependency on this working, and putting this into the fateful hands of a single third-party developer would be an organizational decision I would not want to have to admit responsibility for. Spanner's LMS application had a total of 9 purchases in Marketplace. LMS may mean different things for different people, yet if you're wanting something of the likes of Sakai, Moodle, Canvas, during a time when the need for distance learning is skyrocketing, and all attention and resources are focused on these specialized tools, I just don't see how that would fit into IPS' business model this late in the game.

I had separately noticed an issue where a member in a user group that forces anonymous login is in fact not logging in invisibly.

We do that as well. However, we operate using the principle of least privilege. For our use case of the support system, the majority of support requests we create and reply to do not require the moderator to know anything other than the display name of the poster. There is a setting for the front end that disables the display of e-mail addresses for moderators, yet these settings are not considered in Commerce. Our moderators do not need to know IP addresses, real names, addresses, etc. and even though we have legal protections in place through contractual agreements, there's no reason to expose that information unnecessarily.

Our provider is part of that alliance too. It has significantly reduced costs. Fantastic. Thanks, Joel!

We already are leveraging Cloudflare, and on a paid level. Great to know. I'll be investigating this.

Well, shoot. I dunno. I thought it was there, but can't find it either. What's up with that IPS?

Oh, hundreds. But! Here's two to start: Setting up a local dev and test copy of IPS. Bonus points if you build it in a virtualized/containerized way. This is the basis of everything one needs to develop new templates/plugins/applications/translations/etc., and test things out without running the risk of impacting their production community. Building a public facing feature request tracker for IPS using Pages. Collect votes from customers on utility of a feature, commenting, status/roadmaps, etc. Exactly. This is something that has no reason to be arduous, so as you find the pain points, you can identify where there are gaps in the documentation, leverage your relationships with IPS developers, and fill in the gaps with a guide that other customers will be able to follow step by step and it won't feel so insurmountable.

We severely limit non-text content for our end users because of the costs we'd incur in storing binary data. And you know I love a gif. This is quite a savings. You're running an image-heavy community, right @Joel R?

I'd log a support ticket, though, in the interim--some questions someone is bound to ask: How do you know this is happening? Have you seen the setting in its anonymous and visible status states when looking at a member's record in the ACP before and after the change? How do members know this is happening? Where are you storing sessions? Redis? Database?

Create a post in the Feedback and Ideas forum, pretending that this thread is not already in the Feedback and Ideas forum. Wrap yourself up in bubble tape and prepare yourself to receive the lashings of those who fear change. Tag @Jordan Invision and light three candles.

What version of IPS are you using, and if 4.5, how long ago did you upgrade? This behavior changed from 4.4 to 4.5 from what used to be a per-login setting to an account level setting.

This is already there, assuming you are integrating with Commerce > Support.

Right now, staff with access to Support within Commerce have the ability to see details about the member that may disclose their identity. Things like a customer's real name, email address, and other details. In our community, we've removed this access this via a custom modification we've developed, however I believe this should be an out of the box permission. Please provide a discrete permission to restrict personally identifiable information from staff without the necessary administrator permission to do see that information. It is not necessary for someone replying to support requests to necessarily have access to e-mail addresses, the real name of the customer, etc. Shout out to @theipsguy for this format for sharing ideas that I'll totally steal.