• Content count

  • Joined

  • Last visited

About TSP

  • Rank
    Frequent Contributor

Contact Methods

IPS Marketplace

  • Resources Contributor
    Total file submissions: 8

Profile Information

  • Gender
  • Location

Recent Profile Visitors

104,858 profile views
  1. There isn't, but I would like this as well.
  2. I agree. Although the following linked topic was originally about something else, my reply in it does highlight my thoughts on this:
  3. We will also be utilizing S3-storage. That S3-storage is delivered by the same host that delivers our servers and is not delivered by Amazon, so I'll have to do the same thing.
  4. Yep, it's also missing error messages. I'm still waiting patiently for them to add in these two things that were already being included in the IP listings for 3.4.
  5. Complaining that you have to pay 15 USD for the amount of hours someone else has had to put into translating 10 000 strings seems unreasonable to me. It's a bargain, really. As with all language packs in the Marketplace. Calculate the opportunity cost it would be for you to spend twenty+ hours doing it yourself.
  6. I agree, it's been suggested before:
  7. The behavior is unexpected to users. Because if you're still using device 1 on day 179, and then on day 181 you log in with device number 2, it logs them out from device number 1. Where as if I hadn't logged in with device 2 on day 181, I would still be logged in with device number 1 on day 182. The behavior feels buggy and users are saying so as well. This behavior provides no clear explanation to the end user why logging in to other devices will sometimes cause them to be logged out from all other devices, while other times it will not. The fact the timeout of the cookie was 7 days was never the real issue here.
  8. I decided to do a search in my own server logs belonging to one of the domains we have hosted with us, but there were quite few hits from IP-adresses starting with this. Either, way the user agent on the ones I did find was: "Mozilla/5.0 (compatible; XoviBot/2.0; +http://www.xovibot.net/)" http://www.xovibot.net/ (Which belongs to https://www.xovi.de/ ) The xovibot.net page contains information on how to throttle them or disallow them entirely, as they do say they adhere to robots.txt.
  9. It is indeed a true story, unfortunately.
  10. The autosave feature is something I find very useful myself. If only it had kept my post in situations where I would actually be likely to need it in 10/10 cases, like when receiving error messages. (They are emptied on submit rather than successful post ¯\_(ツ)_/¯ ) The issue here is that removing things from the editor is buggy (which is the real issue) and that it might have been an idea if the autosave-feature had some sort of timeout value that could be defined by the administrator.
  11. ... You're taking one thing I wrote and using it against me, great. Just as I initially suspected you would do when I first saw you like that post. Obviously bug reports should be triaged. Just as regular tickets need to be triaged in some sense. Just as feedback needs to be triaged. I'm like merely pointing out the obvious here. That doesn't mean it's only one possible to triage them the "Charles way". Does that mean I said "Bug reports should be handled in the ticket system"? No. Does that mean I said "a non-developer should triage them"? No. One of my bug reports had me have to explain tier 1 support staff one extra time what I said, while I'm pretty sure any of your developers would've caught on right away. The delay from when I report a bug, to when it end up in the bug tracker is extended. Your reiteration of the bugs also have less information in them, leaving your developers to have to more regularly jump between bug tracker and tickets. How I think triaging here should work: I report bug -> Anyone else can see and comment on my issue with any additional information they may have etc. -> An assigned developer to take care of new reported bugs for the current week takes a look. Any "5 seconds fixes" are done then and there, if the issue is more complex it get's triaged to be completed and looked more closely at later, then they continue to go through the reports. Many many years back you had terabyte in your staff whom I remember was very good at this. It's a situation like that I would primarily like to see again. Ultimately it's like not any harder than to say "Let's make sure all bug reports are dealt with within two months of submission in some way.", and the situation you have would be like 10 times better.
  12. Charles, this new situation where we end up submitting bugs through the client centre, and you post it as a bug report just leaves me utterly demotivated. I know it probably doesn't make any ounce of sense to you, but I'm simply put off the thought of continuing to submit bugs now. You're making this harder than it has to be, both for you and for us, and I just end up feeling unappreciated as well. I hope this is not meant to be a permanent thing and that you really reconsider this.
  13. If they had someone that would respond to and/or properly triage the bug reports as they come in, that wouldn't be a problem.
  14. I guess it could be an option in the move window itself too, in the same way there is an setting to leave a topic link in the old forum or not. And the default state of the checkbox could be decided by a setting like the one you suggest.
  15. I feel like I have mentioned this before, but I could not find the topic. Either way, on a related note: when a topic is moved it should be sent a notification about the topic for members following the forum it is moved to. Now that will only happen if it happens to fit in with the cycle of daily or weekly digests. But for example those who follow immediately will not be notified about the topic under any circumstance. Those who follow the forum the topic is moved to should be notified.