Jump to content
Invision Community

Lindy

IPS Management
  • Content count

    3,919
  • Joined

  • Last visited

  • Days Won

    242

Lindy last won the day on October 22

Lindy had the most liked content!

About Lindy

  • Rank
    That Lindy Character

Contact Methods

Profile Information

  • Gender
    Male
  • Location
    Forest, VA

Recent Profile Visitors

101,969 profile views
  1. As noted in your ticket: I can appreciate you've done some research on this, but you are referencing deprecated extensions in MySQL. Invision Community utilizes mysqli and the process (ssl_set()) is different than simply appending a flag. In addition to changes to the database handler, you would need to generate a certificate, bind that certificate to your installation, etc. It's certainly not as simple as setting a flag and while Azure may provide a mechanism to somewhat simplify this by generating a certificate (though it doesn't work with mysqli without additional setup), it's unfortunately not something we presently support on an application level or have roadmapped to support in a self-hosted capacity. The proper method, with SSL DB or not, is to secure transmission between your web nodes and the database on a network level. There should never be an opportunity to "sniff" a connection from other nodes on a network to database, because only your web nodes should be able to access the DB. A virtual network, vlan, virtual private cloud and appropriate security rules should be utilized so that only web nodes are able to communicate with your database. In the case of off-premise access to the database, network rules to only allow specific IPs should be created and enforced. I apologize for any frustration and inconvenience. This is rather environment specific and not generally an out-of-the-box offering. I'm sorry I couldn't be of more assistance, but we appreciate the feedback.
  2. Support Tickets - Let me "edit" comments

    Sure, I'll add this to our list.
  3. Support Tickets - Let me reopen tickets

    Thank you for the feedback. Generally, all you need to do is reference the ticket ID (as mentioned, it's better if you can just give the ID rather than the full URL, which is unique to your account.) The only circumstance in which a tech will not be able to view your previous ticket is if it was classified as an escalation and/or otherwise assigned to management, which removes it from general view. Resolved tickets only occur if you manually mark them as resolved, or after two weeks of "awaiting customer action." Several years ago, we decided to "lock" resolved tickets not so much because of abuse, but general confusion and slowing the support process down for everyone (staff and clients alike.) A search across the email box for "Invision" or logging into the client area and clicking the last ticket is super easy for the client (and we do want the support process to be easy, mind you) however, in the case of a ticket that involved advanced support and other departments, there could be 2 pages of just hidden notes and client replies that make it difficult to traverse for new, unrelated issues. Further, our technicians are required to work by start date sort order, so it's not fair to other clients to get bumped to the front of the queue by reopening an old support request. It should ideally be a rare circumstance to need to reopen a resolved support request and I'd like to address the circumstances in which that's happening. In cases where that's necessary (such as an update "this will be resolved in a future maintenance update") and you're following up after a couple of updates, please do just open a new ticket and reference the previous ID and we will be happy to assist. I'll also make a note to evaluate how we can make this a bit less painful, such as extending the resolve time to a month. Thanks again for the feedback.
  4. Security risk

    I can't imagine why that would be considered a security risk? We're not collecting your personal details (nor would we via an email link) or anything other than your feedback and URL via a very popular survey service. There is an email address listed there you're of course welcome to email should you have any concern about future authenticity. You're also welcome to unsubscribe via the link at the bottom of the email. If you chose to participate, we appreciate your feedback!
  5. The greed is absolutely palpable.

    I'm sorry you had a negative experience with an author. Communicating expectations is extremely important from all sides. If an author intends on reserving the right to share a custom resource with other clients via the marketplace, that should be communicated. Likewise, when a custom project is created for a client, the author generally retains the copyright. While it's ok to share a general experience, it's not appropriate to share private messages and as such, they have been removed from your OP. If you wish to address this at a higher level without posting personal conversations and details, you are welcome to do so, but I'm afraid we're going to have to shut this particular topic down. Thank you.
  6. Let us know we made a mistake

    I only see two posts hidden. One was reported as spam (topic was about video embeds - you promoted your media uploader app and prefaced it with "this doesn't do embeds, but...") and one was inflammatory towards another member and you reported each other calling each other racists, yada yada. Sometimes we just assume you know you shouldn't have posted it and we move on with our day. In other cases where it's an actual issue, we will issue a warning - sometimes with action, sometimes without.
  7. 1. We will explore account deactivation further. 2. We can add a blurb "if you wish to close your account, please <contact us.>" The GDPR requires you address account deletion requests no more than 30 days after submission. There are no requirements to automate this process or provide instant deletions. 3. There are too many considerations to develop anything less than a comprehensive, proper solution and that would take an amount of development time that doesn't make sense (to us) to allocate at this juncture. There are third party solutions to handle a robust, automated account removal system and again, we'd rather focus our efforts on people joining and using your community, not leaving it. We appreciate the feedback and the dialogue. This is unfortunately going in circles - feedback has been provided, we have addressed it and are considering a partial implementation of the original request and now it's simply time to move on. Thank you.
  8. IPS 4.2 observations

    I'm sorry, I misunderstood your feedback based on "don't force us to use real currency." I understand your use-case and we can consider it in a future release.
  9. Weekly digest summary?

    We don't ignore feedback - we can not engage every suggestion that comes in, we often simply need to see where it goes and how popular the suggestion becomes. As an example - your post has had 6 reactions and a few replies in a year (3 last year), whereas, the "selling subscriptions" suggestion has come up multiple times, most recently 3 days ago and already has more "likes" and engagement. Because of this and other avenues of feedback, we recognize subscriptions as something we need to prioritize and we're going to do so. There are thousands of ideas in this forum. In coming weeks, we'll be using a new system to log ideas that allows essential up-voting (not to be confused with bumping, which would not be possible) by other clients. We can then get a broader idea of how to prioritize feedback and clients can get a general scope of ideas that are gaining traction. Incidentally, simply expanding the digest is something we intend to do to include "our picks" and popular content engagement. I don't have an ETA for this, but it's not something that's years away.
  10. Yes... and it's a function within the AdminCP, not a user-initiated function. There's a pretty significant difference there. Yes, absolutely, we could throw a quick "delete your account" function together. We're not going to do that. If we were to incorporate a user-initiated function that led to the account and content being destroyed, it would have to be a far more thought out system than what you're thinking as a single client. @Makoto's app https://invisioncommunity.com/files/file/8571-account-deactivation/ is really quite comprehensive and I'm confident involved a fair amount of development time and we'd have to take it even further to address things like Commerce. I'll reiterate one last time -- I'd rather our development efforts be spent on people joining and staying on your site than leaving. Account deactivation is something we can look at. If you want to truly automate account deletions, you'll need to rely on a third party method to do so as I don't envision being able to justify working this into a roadmap item in the foreseeable future. In short: account deactivation - yes, I will log that as an internal feature request. Automated self-deletion - I'd suggest a third party solution for now.
  11. Of course signing up is easy. Signing up does not disrupt discussion and content flow. Signing up does not destroy content and records. Surely, you want people to freely join. As I said, account deactivation is fine and would be easy enough to implement. To do properly, to our standards, an account self-deletion system would be more complex - it would require a request and approval system (both on the admin and the user side to prevent "hacked" and accidental deletion), provisions in other apps such as Commerce for the previously mentioned reasons, etc. I'm not saying we will never do it, but we prioritize functionality that encourages people to join and stay on your site, not leave it.
  12. Selling Subscriptions

    We agree with a dedicated subscription option - we've roadmapped it.
  13. I've never quite understood the notion that not deleting someone's account is the virtual equivalent to locking them in your basement and holding them against their will. Perhaps it's a US vs EU cultural difference, but generally, if I don't want to use a site anymore, I just... stop using it. Beyond that though, I recognize it's a preference and as an admin, if you want to delete a user's account, more power to you. It's important to remember, however, we're not just a forum company -- people can use our software to perform financial transactions. As a US-based company, I am not familiar with the rest of the world's financial record retention requirements, but in the US, you can't just willfully destroy customer data, even if the customer says pretty please. Further, there are other considerations - as a provider, we've processed hundreds of subpoenas and warrants over the years (as have clients) and many are preceded by an order called "motion to preserve evidence" that demands we retain data for X days, or even months. Certainly, those cases do not happen every day for us, but it would be quite unfortunate for an admin to receive such an order and often, the subject is aware of the investigation and deletes or requests to delete their account (and an admin, perhaps not site owner) approves it. Or you undergo a financial audit and suddenly, you're missing blocks of financial data because you let users delete their data and you can no longer correlate credit card transactions to purchases. Yes, it's not uncommon for social sites to allow you to delete your account. Once money is involved, however, it's trickier. Account deactivation would not be a problem. I don't see an issue with disabling an account, ensuring a disabled account cannot be emailed, etc. For account deletion, I would be more inclined to add a link under account deactivation "want to delete your account entirely? please <contact us.>" That is still in compliance with the GDPR and presumably, you aren't getting requests to delete accounts regularly or you may have bigger issues. If you would still prefer to completely automate users deleting their own accounts, I think the third party resources mentioned would be the best course of action for you.
  14. IPS 4.2 observations

    Invoices are necessary to serve the varying needs of Commerce and its clients - I'm unsure where you've been shopping where you don't deal with invoices in some form -- some may call them "orders" but ultimately, they're invoices. They can be transparent to the client in Commerce as well. If you want to allow no grace period and change settings to focus more on instant transactions and you needn't mess with expirations, etc. Please understand, it's an e-commerce product. The entire system relies on some form of valid currency and changing it to use a unapproved currency would be an expansive undertaking, for a rather niche use-case. If you're trying to sell points, you could perhaps consider the account credit feature, a custom field, or similar? It's not that we're trying to just make it simple for you in terms of knowing where to deliver the product. If you pay via credit card with PayPal, an address is required. Most merchant processors - auth.net, etc. are going to require an address. 2checkout, at last check, requires one. If you're handling physical products, you're most likely supposed to be collecting tax based on the customer's location (which you wouldn't know, if you didn't get their location), fraud screening won't work properly, fraud rules in Commerce won't work properly. I understand you have an edge case... from my experience, not requiring an address for physical products is, by far, the exception, not the norm. It may seem "simple" to just allow people to do whatever they please with the product with no engineering limitations at all, but we do have an obligation to maintain the integrity of the product, keep support minimal and try to avoid issues the client may not have considered (ie: "I don't require addresses and I've gotten 30 chargebacks!", "I don't require addresses and now the revenue service is auditing me.", "I don't require addresses and I can't get PayPal to work if the user is using a credit card.") etc. We allow you to ignore all of that for non-physical products if you really, really want to - but the extremely limited cases where you'd even be able to sell a physical product online without knowing who your client is at all, do not warrant the potential ramifications. Nonetheless, I will investigate the ability to have a power user setting - no promises. In the interim, if it's a sticking point for you, then I suppose you could try (I've not tested) editing the language strings for the address fields and instruct them to put "n/a" if they don't want to provide an address if you're ok with that, you're using a payment processor that doesn't require addresses and you're not using fraud rules. If you'd like to PM me, I'd be happy to review your shop and make suggestions. Commerce shouldn't be difficult for end-users, if you can articulate further feedback, we would be happy to review. I like this idea a lot and will log it internally. Subscriptions is, by far, the most common usage scenario for Commerce, so I would agree making it easier to add and manage would make total sense. On it! @Colonel_mortis - I just want you to know, why perhaps irrelevant now, we've not ignored your feedback on PayPal billing agreements. We have been working with PayPal and have made changes to the gateway for agreements in 4.3. As for the original invoice concern - are we good on that?
  15. IPS 4.2 observations

    To address the various Commerce discussions related to subscriptions: I like simple solutions and we're leery of adding pages of potentially confusing settings to accommodate all possible usage scenarios - Admin A sells tiered subscriptions and only wants subscriptions in a group to be unique because he's fearful of a user purchasing multiple subscriptions at once. Admin B has an automotive repair support community and sells subscriptions based on what vehicles they need service info on and he WANTS people to be able to purchase "Chrysler, Ford and/or GM" subscriptions simultaneously in the "Domestic Vehicles" group. If Admin A's subscriptions expire, he wants them to buy a new one. Admin B wants them to be able to renew past invoices and NOT buy new subscriptions because his bookkeeping and analytic requirements dictate he needs to isolate new sales vs renewals. Admin C uses subscriptions to sell recurring online game credits that can stack, so his needs are also different than Admin A and B. Admin D wants to prevent people from ordering multiple subscriptions at initial checkout, but wants them to later be able to order simultaneous subscriptions once they're a client. Invision makes an attempt to specifically accommodate Admins A-D and Admin E comes along that wants to simply sell a single premium subscription and has difficulty because there's a series of what-if complications they need to traverse through. I hope the above better explains why things are done for what you may consider "no good reason." As you know, users tend to get focused on their specific needs - totally understandable, we don't expect you to consider every possible angle, it's your needs that you should be most concerned about. Our job is to parse feedback and incorporate the simplest solution that benefits the most. On the simplest level, if your issue with selling subscriptions is people can't renew from expired invoices -- the solution is quite simple - don't expire the invoices. If you don't have a specific need, it's not a requirement and you can in fact disable that today. That seems to solve the brunt of the issue, which as best as I can tell are: you've set invoices to expire and also enabled one-purchase protection, so they can't pay expired invoices and they can't purchase a product they've already purchased. Both of these concerns are admin configured and changing only one of them resolves the issue at a basic level. If there are suggested tweaks that can be further articulated, I'm happy to act upon those internally. An example would be: a user tries to purchase a subscription that has protection enabled, we can modify that "error" to be more friendly and refer them to their purchases page, or even, a pending renewal invoice if one exists. Another potential solution to the expired invoice concern is to continue the global expiration time, but allow that to be overridden on a per-package level. So, for certain subscriptions, you may opt to allow the client to renew 10 years after it expired. Others, you may only want 30 days. Finally, it may be a good idea to allow for product groups (categories) to have the unique/one purchase protection for those that desire it. In short: we want you to be able to use the product to be successful. We are happy to make tweaks and try to accommodate various use-cases without overcomplicating the product. Again, the best solutions are often the simplest. If you agree, we'll proceed with further internal discussions and try to get these ideas materialized.
×