CoffeeCake

Depending on the community, there may be other reasons for display name changes. Imagine if you registered for a community that dealt with something embarrassing and two months later you realize using your full legal name as your display name may have not been the best life decision. It would be a nice, welcome feature to have the names displayed in quotes and in mentions update with display name changes to help keep continuity over time. If someone simply refers to the name otherwise (not in a mention or quote), I don't imagine we'd want that to be handled by such an extension of the display name change functionality that presently exists.

This may be an issue with the modification itself. Also, have you considered removing /index.php?/ from your URLs?

Updated with the third way I didn't realize IPS had. This would probably have a better user experience using something else, like an app, that would have the ability to store a key locally. For this to work, the end user would need to provide their decryption key somehow/somewhere when they'd want to access their messages. I would strongly recommend looking into integration with a service that has figured this all out if important to your membership.

We also do not use PMs and instead use the support system in Commerce. Creating a support request that would be a fantastic option as well (we maintain a separate solution to notify on new support request, so we'd need the ability to disable that part preventing two notifications).

Are you using Redis?

That's what I get for translating the phrase "Support" 🤓

What is this?? I've never seen a SQL toolbox. Edit: Never mind I just found it hidden as a link the support page. How on earth do you disable that? Is that considered part of diagnostic tools? That really should have a separate permission. I would like to clear cache and such, but no access to SQL toolbox. I don't see a separate permission for it. This should totally have a separate permission.

You may want to audit your administrator settings then. It can certainly be configured in such a way that you cannot see them through the interface. Turn this off: Members > Administrators > <Your Administrator Group> > Settings > Can sign in as members To stop the ability to report private messages: For each of your user groups, turn off "Can report Personal Conversations." Disable SQL Toolbox in Members > Administrators > <Your Administrator Group> > Support > SQL Toolbox to prevent direct, unfettered access to the database via Admin CP, a gaping security hole feature I didn't even know we had. Those are the only two three ways (I'm aware of) you can see messages that are in another user's PMs via the web interface.

Can't speak for anyone else, but want to make sure for those happening upon this, that it's not as simple a thing as it seems on its face. There are legal, technical, and policy factors to consider that make this a tough cookie to break, and if the goal is an assurance that the owner of the site cannot in any way read the data in any circumstance, end-to-end encryption where only the end users have the keys is the only viable solution and where no plain text data of those messages are stored.

That means there's a plugin with an update available. Scroll down and click on the "update available" bubble to go to the Marketplace to install the update. If you don't want to install the update, I don't think there's a way to silence those counter notifications.

To address the language issue, you can use the translation feature to rename "Private Messages" or "Personal Messages" (or whatever it's called--we don't use private messaging, so.. no idea) to whatever you'd like it to be called instead. I think that you'll find that when you start to explore preventing this, you'll find that you're just adding layers to that illusion. The only way to achieve assurances that communications are private are to encrypt those communications in a way that you, and anyone with access to your site's infrastructure, cannot decrypt them. Maybe you create an extension that blocks access via the interface, but someone at your provider accesses the database directly? Maybe an admin turns off the modification to access messages and then back on? Where does it end? You'd need to permanently encrypt the data in the messaging tables to prevent decryption even after the modification were removed. And now that you've done this, how do you address individuals using this functionality for illegal things? Are you now liable for providing a mechanism to do so? You can't address people reporting bad messages because you can't see them now that they're encrypted. Nothing within IPS can decrypt the messages in this hypothetical modification, so you're now just relying on the reports of those involved in the conversation. As for logging and displaying logging, that's again dependent on no access to the database. Another illusion. Certainly it would address those with limited access, but you? Your web host? I'd ask a lawyer lots of questions. As @christopher-w points out, make sure your disclosures are clear. Be clear with the technical limitations, set policies that are appropriate for your site, audit those policies regularly, and be clear with what your platform is not. Encourage people that want end-to-end encryption to take their conversations to a place that provides that and make the assurances someone else's responsibility so you can focus on your core audience. Turn off the native messaging feature in IPS and find a provider that will work with OAuth or similar to integrate.

Edit: I just re-read your post. I see it's a matter of principle now... missed that on the first read. You have to ask principled questions, to which there are no "right" answers--whatever fits for your community: Do you want to be able to respond when a member is being harassed or spammed or something similar by another member via private messaging? If so, you probably want to keep the ability to report PMs enabled, and you probably want to read only those PMs in the report center. Do you want to make sure that no one can log in as another user? Turn off this option for your account, and don't extend it to anyone else. Do you want privacy protections above what is provided by IPS? You'd need to do something like encrypt PMs, transmit those encryption keys to members, and not store a copy of those encryption keys so that the data within the database is unreadable without the key and can only ever be decrypted by the member. This would make things rather user unfriendly, but maybe there's a need for you. This is probably a very large technical hurdle to cross. At the end of the day, you are entrusted with user information as an administrator. You probably want to look into things like non-disclosure agreements if you bring in others that have elevated access.

What's the thing you're trying to accomplish here? As @Daniel F pointed out, there's no built in mechanism to access private messages of anyone else (other than if the private messages are reported by a participant in the conversation). Are you trying to block the ability to report PMs? Are you trying to block the ability to "log in" as a user? This is a setting you can restrict in the Members > Administrators, as @Adriano Faria shared. Do you have some third party app that allows you to read member PMs? I'm assuming you're trying to block this from a group of administrators that cannot install/uninstall/enable/disable applications.

Ohhhhh. Never did that. Thanks 🙂

When does this happen? Is this a CIC thing?

I'd open a support request. Perhaps not all instances were fixed, yet there was a code change that attempted to fix this in 4.5.3.

This particular issue was fixed in 4.5.3.

We are integrated with Google cloud platform. I'm not sure. It all goes through GCP. It doesn't look like there's anything on their pricing page that matches what we have, so I'm not sure if we're grandfathered in some way. On their pricing page, you'd need the $90/month option to get a dedicated IP for outbound/inbound mail. No matter what service you'd go to, you want dedicated IP addresses to mitigate against someone else doing bad things and you getting blacklisted as a result. Otherwise, it may just be a matter of time from these reports.

It looks like it's the luck of the draw then? We are on a paid plan, though not with dedicated IP addresses.

That's interesting. Just gave this a review. Good indicator messages are going into Spam folders, yet nothing seems out of whack. I wonder if we're just on a lucky pool of IP addresses. Are you using SPF/DKIM?

The plugin you linked seems to do exactly what I thought you were asking for. What would make it more elegant?

This is our scenario. Trying to do find/replace operations via SQL to the post content blob field are at the point where it's simply unworkable. Yet, with some engineering and creative indexing, this is not an insurmountable issue. Look forward to seeing it addressed.

That link has a discussion from 2017. We use sendgrid, and haven't had reports of any issues. Deliverability seems to be just fine. I'm sure there are others with issues, yet this has not been an issue for us (or at least one we've been made aware of). We have made attempts to reduce the amount of outbound mail significantly by defaulting members to notifications only unless they opt-in to e-mail notifications, but this makes sense for our community and may not work for yours. We use @stoo2000's bounce email management application to address any bouncing addresses with great success (though it's not yet upgraded to 4.5).

What leads to this error? Can you give some of the background of what you or your users do before getting the error above? What are the steps taken to reproduce? Did this work before? What changed before it stopped working? Are users adding things to their cart and then seeing this? That error happens when a user attempts to check out and there are no items selected in the invoice/shopping cart: if ( !\count( $invoice->items ) ) { \IPS\Output::i()->error( 'your_cart_empty', '2X214/2', 403, '' ); }

We are using caching, security, and firewall features. It helps us mitigate spammers quite a bit more than IPS' spam service, which I think we're just acting as a honeypot for some days. 🙂 We have been able to limit bad behaviors from ever reaching our infrastructure, and we can mitigate against DDoS attacks and the like by having everything going through their CDN. We're at the basic paid plan--using nothing particularly fancy. Caching seems to work great. There are some adjustments we had to make for certain administrative functionality, yet for the most part, the impact has been nothing but positive and we're saving quite a bit on bandwidth expenses compared to otherwise. The security features alone make it worth it for us.