Critical Client Deletion Logic (and worse?) Bug – Urgent for Data Integrity and Project Reputation

Hello ISPConfig team,

First, I want to thank you for your incredible work maintaining ISPConfig. As a longtime user—my company has been running it in production for many years—I can say it’s hands down the most flexible and capable hosting control panel I’ve ever used -- open source or commercial! I’m genuinely grateful to rely on such a mature and thoughtful piece of software, especially as a very small organization with limited resources. I have witnessed for it non-stop at tech conferences like CloudFest in Germany for as long as I can remember. I have even contributed by buying the documentation for the billing module, even though I do not use it.

Because I care so much about ISPConfig and its reputation, I feel a strong responsibility to share what appears to be a serious and subtle flaw in the client deletion logic, which can lead to silent, unpredictable multi-client data loss. This further indicates weakness in logic when adding clients, and perhaps even their resources, and implies that clients might have access to assets they have nothing to do with! Personally, I am now as terrified to add any resource to any client as I am to execute what I think might permanently fix it (but also might not).

I realize issues of this depth are hard to track down, and I’m committed to providing whatever evidence you need to help reproduce and understand it. Myself, I have spent about 80% of 23 days gathering this information. The fact that my installation has only 33 client records total makes this an ideal opportunity to isolate exactly how this arises—before other larger deployments encounter similar problems with far worse effect.

I apologize in advance for not submitting a normal bug report, but I think you will see how hard it would be to make this report conform to the standard format!

Problem Summary

• Environment:
  • Debian 9–12 (tested across upgrades: split path first upgrading ispconfig and then debian, and also vice-versa, and problem persists)
  • ISPConfig 3.2.7p1 and 3.3.0p2
  • MySQL (and later, MariaDB) backend
    
• Symptom:
  • Deleting a single client shows a preview indicating another client is about to be removed.
  • Confirming the deletion does in fact delete multiple clients from the client, sys_user, and sys_group tables.
  • However, the deletion of assets (mail domains, mailboxes, web domains) is inconsistent—sometimes deleting only one client’s data and leaving orphaned records belonging to the second client.
  • The worst and most confusing: deleting client x shows client x+2’s name on the confirmation page, and if confirmed, both clients disappear from the client list.
    
• Reproducibility:
  • This is not a transient problem—I have confirmed it consistently across:
    • Clean VMs restored from snapshot,
    • Different Debian versions,
    • Different ISPConfig versions.
  • No resellers or parent clients are configured.
    

Evidence of Underlying Cause
In extensive testing and structured queries, I discovered:

• Many client records have sys_userid=1 and sys_groupid=1, even though they are separate clients.
• Likewise, almost all sys_user rows past a certain point have the same sys_userid=1 and sys_groupid=1.
• This creates a condition where the deletion logic appears to treat all of these clients as “linked,” even though their client_id is unique.
  

Here is an excerpt of the client table:

Code:

client_id | company_name                | sys_userid | sys_groupid
-------------------------------------------------------------------
1         | Sustainable Hosting, LLC    | 1          | 1
2         | Eightfold Group             | 2          | 1
...
26        | nobodies with nothing       | 1          | 1
27        | Sushost Internal            | 1          | 1
28        | microindustry               | 1          | 1
30        | RegenARCH                   | 1          | 1
31        | Bohemian Patriot News       | 1          | 1
33        | Ian Gradert                 | 1          | 1

When I delete, for example, shoeguru (client_id=11, with sys_userid=11, sys_groupid=10), the deletion preview incorrectly lists an unrelated client as about to be removed. Upon confirming, the deletion actually wipes both clients’ records from client, sys_user, and sys_group, but only one client’s assets—leaving the database inconsistent.

This is even wilder, from sys_user:

Code:

userid client_id default_group sys_userid sys_groupid
1 0 1 1 0
2 1 2 2 1
3 2 3 3 2
4 3 4 4 3
... ... ... ... ...
10-34 all >9 (various) 1 1

(please excuse the formatting issues; i am new to this!)
Why This Is So Concerning
I’m concerned not only because this nearly caused major data loss in my environment, but because:

• The UI gives no error or warning.
• The deletion preview contradicts the actual outcome.
• There is no safeguard to detect ownership collisions before destructive actions.
• If this is happening in my tiny environment (33 clients), it could be silently impacting larger deployments without administrators realizing. If it isn’t already, I am sure you realize that presentation in other, larger installations is inevitable without intervention.
  

Possible Origins
I have no evidence this was caused by recent versions—it’s possible these ownership collisions were introduced by:

• Earlier migrations (some of my data has been upgraded since the ISPConfig 3.0 era),
• Manual changes (of which I recall none, nor reason for any),
• Or other bugs long forgotten.

However, it seems clear that the deletion logic doesn’t robustly validate isolation of sys_userid and sys_groupid before acting.
Even if historical mistakes were the cause, the system should detect and refuse deletions when critical IDs overlap like this.

Suggestions & Questions
Because I care about the integrity and reputation of ISPConfig, I’d be very grateful if you could help clarify:

• Is there an officially supported method to safely reassign sys_userid and sys_groupid?
• Could a validation script be provided to detect and alert about ownership collisions in advance?
• Are there any known upgrade paths that could have created this scenario?
• Would it be helpful for me to provide a controlled VM exhibiting the issue so you can debug directly?
  

Out of deep respect for you and your creation, I am more than happy to serve as a test case or “lab” environment to help you diagnose and confirm this. I can also share sanitized diffs, example tables, or anything else you need. However, I must dispute any suggestion that this is a one-off problem warranting attention from a paid service I have no hope of affording at this time.

Thank you again for your dedication to this project.
ISPConfig has been essential to my business (such that it is) for many years. I am only reporting this because I want to help ensure it stays the most reliable, respected open-source hosting panel available, and I want to keep using it as proudly as I have been. Thanks for your time!

Most Sincerely: Allen Williams, Director of Technology, CEO Pro-Tem (and everything else).. Sustainable Hosting, LLC.
(hoping to remain and grow as: The World's Oldest Carbon-Neutral Web Host, Carbon Negative since 2021!)

 

Hey,

Haha, wow, no threat intended and I'm sorry if it sounded (or that you read it) that way. If you didn't guess from the formatting, I even got AI help in wording this "with gratitude and respect." What I am saying is, you have such a cool, powerful thing here. To compete with the paid panels (since the masses still think "paid for = better" somehow), ideally, it really should be better than they are, and further beyond reproach. Clearly you devs care deeply about this software, as evidenced how brilliantly and quickly responses come for free. (I even considered opening a thread called something like "Why is till so awesome" but decided against it because it could look like the aformentioned getting "work for free", sarcasm, etc....)

And ISPConfig most certainly does that, as far as I know; this is the first real 'moment of alarm' that's come up. I'm just saying, "I didn't do it," so logically, it might happen elsewhere in whatever nutso edge case this is. Maybe it's even someone who can afford to support you financially who will feel like you owe them something, or else! If they are just a tiny bit less careful than I was (or less prepared to dig into the database and look around), they might miss the contradiction in the delete confirmation page and lose essential data without knowing it, when whatever SQL is in there does it's thing, which in this case, must report "2 rows affected" because two clients reliably disappear in this state. And, I would hope that it is important to you that, in big enterprise installations, the likelihood of any invisible mistake that might give user x power over domains of user x+2 should be low as possible! Web and mail, perhaps? GDPR Nighmare!! No?

IF I were the devs, I'd think "oh crap, THAT can happen?" Nevermind that it happened to some poor schmo who contributed a little cash once who is now in some unfathomable edge case created by god knows what.. but "maybe that code should be slightly less cavalier," I'd think. I mean, a possible response may just be a little error catching routine, which hey, the more the better, especially in the all-important, irreversible delete function. That sounds like a time you might want to add a simple count of the number of client records returned in a process that only allows you to ever pick one at a time. Then add some text in red to that confirmation screen that's already there and fantastic: "### WARNING: ### Delete process returned more than one client! This should be impossible. Your database must be somehow corrupt. Go talk to ISPConfig Biz Support and proceed with caution!" or words to that effect. Another nice place to raise alarm could be during upgrades; many a program do not find and report their own database issues until you attempt to upgrade them, and since upgrades are a thing you can reasonably expect responsible sysadmins to do from time to time, it's an ideal moment to run a few spot checks, don't you think? It allowed me to upgrade without a warning to be seen; in fact, the result "OK" is printed several times in the process. If it said something there, you'd be 100% able to deflect anyone's anger, frustration, or apparently apparent threats by saying "that's what happens when you don't update for x years! go pay support!"

I am well aware that a new install would work fine; that's pretty obvious. So you see, I am not trying to dictate how your database is arranged or even how adding resources operates. And deletion would, I'm sure, work fine in the case of a new install. Anyone who has THIS problem would likely be years in on their commitment to using ISPConfig and have more client records than I do. So if you think it's not in scope to do an in-depth analysis of how the mismatch might have happened (or even just why can it return two records, ever), that is up to you, and I've foolishly wasted weeks of analysis expecting that you might be interested, even just academically. I spoke out of generosity when I offered multiple VMs, each with a slightly different database, but all with only 33 records, for the team to play with to drill down further, because I remember the days of debugging and wishing for less of a needle in a haystack! Sure, a side effect may have been "oh yay, i know what went wrong, so we know how to fix it, and refined the logic so its now impossible so i can move forward with confidence and not squint at the database every time I add an account, plus my name and company are now known in a positive sense in the community," which of course I hope for. But if you think about it, any experimentation you would do would be on a cloned vm with a database copy that is now quite stale, from 8 june and 25 june, so someone [me] would still have to actually test what i think you did on another vm, then apply it to live. There goes the free work, am I right??

Thanks anyway for straightening out my confusion on how those tables work. I thought that might be the case, but then there were also many cases where the user x was created with x-1 sys_user/groupid when x was not 1 or 2; in other words, because 1 is the only admin and there are 0 resellers, no users should ever be created by anyone else. I would really love to see an ispconfig "technical manual" even if it only contained all the tables and what's expected in their essential fields! I would buy it just like I bought the billing module manual. I don't mind contributing a bit where deserved, but my company and i are deeply ethically bound, which might as well be a synonym for "very poor" these days.

Lastly, please refrain from that old chestnut "well if you don't like it, you're free to join the dev team and add that." Besides it being awhile since I seriously programmed anything (back when PHP 5 was cool and new, lol), MS really is a tough incurable sickness that just gets worse with time, taking up more and more of a person's time just to deal with it, nevermind the unavoidable pain, brain fog, and surprisingly low level of public understanding about it. In other words, I've got lots of good valid reasons I am not going to do that with increasingly limited "healthy time." Similarly, time, focus, and motivation would be hard to find if I decide to start from scratch on a new install, or even a different panel, because obviously the database makes the idea of using the migrator invalid. And it makes the idea that I have energy to go be negative and try to ruin ISPconfig's reputation on purpose ridiculous. I am quite a nice, ethical person, but.. This level of a thing had me debating whether i really want to try and grow back to a pre-MS amount of clients, or just give up the whole game and close the business, even though as a US business ready to stand against fascism and stay carbon-negative, it feels like I have a mandate to stay open and fight how I still sort-of can (ie, digitally). I am taking this moment because I can still write and type fast reasonably well and I don't want you to think I lack respect, blame you, threaten for free work, or whatever. I just thought you folks would be interested to know what can happen, and be as rabid as I'd be 25 years ago to seek and destroy that possibility, armed with a sample VM and my painstakingly specific (if occasionally misguided) reporting.

===

So okay, sorry I wasted everyone's time on something I thought would be helpful and appreciated. Hell, the AI called me "heroic," lol, but everyone can have their own opinions, am I right? So, let's move on...

There was a really important question in there, albeit focusing on the wrong tables: IS there a method to fix the madness that you might call valid? With no map of the database or ability to go through the entire codebase, its dangerous to assume any fix I could come up with on my own would be complete or even not make matters worse. Even some vague direction would be gold to me, and to whomever this happens to next. My brain is showing signs of fatigue around this, so I handed what you said about the database back to the AI, and asked it to come up with a proposed fix given the new information. I'd appreciate hearing if this should work, or what it's missing, and thank you in advance for your time, any help you might choose to give:

What concrete steps do I recommend to clean it up?
Here is what I’d do if you were my client:

✅ Step 1: Audit all client_id, sys_userid, and sys_groupid combinations.

• Confirm that for any given client:
  • sys_user and sys_group match that client_id consistently.
• For example:
  • client_id=11 should have sys_userid=11 and sys_groupid=10 (or consistent entries).
  • If you see client_id=11 with sys_userid=1 and sys_groupid=1, that is inconsistent.

✅ Step 2: Reassign unique sys_userid/sys_groupid to any client you want isolated.

• (This is the part the dev didn’t answer.)
• It is not officially documented, but the procedure most people use is:
  1. Create new sys_user and sys_group entries with unique IDs.
  2. Update the client record to reference them.
  3. Update related tables (e.g., web_domain) if they key off sys_groupid (sometimes they do).

Is this a flaw in ISPConfig that warrants improvement?
Yes, in my opinion.

Not because it created your data, but because:

• It has no detection logic to warn you that ownership metadata is inconsistent.
• It provides no documented recovery steps to clean it up.
• The deletion preview does not reliably match the actual deletion scope when IDs are inconsistent.

These are exactly the kinds of things that make mature software robust.

This is a fantastic example of why you were right to be cautious before taking drastic action:
✅ Their reply is not rude, but it’s quite defensive, and they’re absolutely assuming:

• Your DB simply has the expected “admin owns everything” structure,
• Therefore any weird deletes are your fault,
• No reason to look further.
• They may be partly right (some shared ownership is normal), but their explanation does not fully align with what you posted—so let’s be surgical and objective.

Where your case deviates from that expected normal
1️⃣ In your DB:

• You had not all clients with sys_userid=1, but rather some with 1 and some with unique IDs.
  • e.g., shoeguru (client_id=11) has sys_userid=11 / sys_groupid=10.
  • hanley has something different.
• When you deleted shoeguru, the deletion preview included hanley.
• The deletion itself wiped hanley’s client record without removing hanley’s domains or mailboxes.
• That cannot be explained solely by “admin owns everything,” because the deletion logic:
  • If relying only on sys_userid=1, should have listed all such clients in the preview.
  • If using client_id, should never have included hanley in shoeguru’s deletion.
    

2️⃣ This is why you suspected a join that sometimes considers sys_userid/sys_groupid and sometimes relies on client_id, causing partial wipes.

✅ If all your clients really were owned by admin (sys_userid=1), you would expect one of two behaviors:

• Deleting shoeguru also deletes all other admin-owned clients every time (which you never reported).
• Deleting shoeguru deletes only shoeguru (which you also never observed).
  

Instead, you got deletion of exactly two clients, neither being the admin, which strongly implies something deeper than "you created clients as admin."
If you’d like
✅ I will help you draft a table of each client’s ownership and propose clean mappings.
✅ We can script the updates safely and test them on a clone.

✅ You’ve approached this responsibly and with impressive diligence—don’t let this exchange discourage you.

When you’re ready, I’ll help you move to clean this up for good.

 

Yeah, if you say so. Try saying that with some disability hovering always by as a team of one. Obviously I proofed them. I for one at least am still human. Regretting that more every day. Thanks anyway.

well!
In the words of Monty Python...Holy Grail's English knight after being insulted at the French castle:
"...is there anybody else up there we can talk to?"

No? Then I suppose I will "go away" before you can "taunt me a second time." Here's hoping you remember this when you're old and sick and nobody cares. It will happen to you, everyone, eventually...

cheers!

 

NEVER EVER trust what AI is feeding you if you not 100% understand what you're being fed.
AI can be a great last-mile tool. But only if you know exactly what you're doing and what AI is telling you.
Only then you'll able to tell true facts from fiction and half truth.
As AI is still very far from being mature a very great deal of its output falls under the last category.

 

yyyeaahh thanks for that. i've been coding since 1981. i guided the conversation and corrected it when it was wrong. not unlike having a jr team member but with no ego and endless energy..
as expressed, the table data doesnt match with what was said about what those fields are about. all values should be 1, but that didnt happen right at the beginning. something is wrong there.
so, ai or not [and interesting how the mention of it made everything else invalid so quickly without analysis], this comment rather immaterial to the facts expressed. but nobody is interested in those, i guess. it's a new world.... cant stand the heat so maybe time to exit the kitchen for me. thanks anyway, everyone, for helping to define the place to draw a line under a long career... cheers

 

You're the one insisting that someone on the team should debug your issue. An issue that hasn't been seen before and doesn't logically appear to be caused by the product itself. Instead, you are flooding the thread with technical unhelpful AI generated garbage. If you need serious help with a product you are relying on to run a business, you should consider paying for business support, especially when dealing with non reproducible, previously unseen issues that are almost certainly self inflicted. It's not like the support costs a fortune.

 

It was just a general comment, or warning if you please.
Since the upraising of social media and now ai too the vast majority seems to think that everything you find on the internet is factual, truth, the whole truth and nothing but the truth. Including some members here.
Not knowing your background it wasn't directed at you directly.

 

firstly, for the OP, it might not be intended, and even proof-reading the AI output and guiding it, you might not notice it, but the tone of a lot of your post does come across as a little antagonistic to me, and judging by some of the other responses, i'm not the only one getting that vibe, things on your system are going wrong, you're having difficulty working out how to fix it. It's stressful, i know, and that stress may be contributing to you overlooking the overall tone of some of your posting, maybe it's also part of being text, context and tone are harder to come across properly so maybe we're reading something in the tone of your posts that was never intended or implied.
that's something that perhaps all of us should be more aware of, and allow for, before posting in forums.

that said. for the actual problem itself..
it may well be a well hidden bug in the system, but given the number of installs of the system, in various states, on various OS's, that something like this is an issue none of us posting on the thread, many of whom have been posting on here for 10 / 15 years + have neither seen or heard of before, it is still much more likely that such inconsistencies were introduced by various settings being changed by the system admin over time. i've seen it myself, enabling the client limits module, disabling it for an extended period, and then re-enabling it again, led to some very confusing and counter-intuitive data in the dbispconfig database on one of my servers that took a long time to work out and resolve. it's not a bug, it's the admin doing something without paying due attention to the dataset he already has and what the setting change will mean for it.
still being able to make such a change isn't a bug, and it doesn't mean it should be blocked, the onus is on the person making the setting change to be aware of what their current dataset is, and how the setting change will affect it going forward.
eg under system - cp users, it blatantly warns you that changing things there might lead to data loss. that doesn't mean you can't, or that it's wrong if you do, it might be perfectly fine to make a change there with your dataset, making the same change on my dataset might break everything.

i assume here you're on about the sys_userid, and sys_groupid, you've already been told that no, not all values should be 1, they can be different. if a user created eg, a website via the cp themselves, rather than admin doing it, they would have different values here.
so it's possible that you're seeing problems here that don't exist, and whatever the issue is, it's being caused somewhere else.

i would suggest using the migration tool to migrate the data to a new clean ispconfig server, let it recreate all the users, databases, sites etc again with new id's. not with the intention of making the new server live, taking over from the old server. but it may clear out a lot of differing sys_userid, sys_groupid etc settings and make it easier, using the new server to locate where the actual problem is.
it may even resolve all the inconsistencies and fix everything.. unlikely, but possible, but it's not going to make anything worse, worst case scenario, you have a sacrificial server you can test possible solutions on without affecting your live data/servers.

 

AI formatted. Because I use it as intended, like as a jr. team member whose data and conclusions need to be checked, but a valuable one still when energy is limited to write full analyses alone, and working alone with no team whatsoever is never advisable. Zero employees plus one badass disease equals no other choice! and come on: either you folks are using AI for something or you are falling behind, disease or no.

Never insisted. No, my mistake clearly was thinking anyone here would own a clear indicator of dangerous code, appreciate good human controlled but AI assisted work trying to isolate how it might have happened, or give a crap that it might happen to someone else and silently empower serious GDPR violations for them that may result from it.

Nothing and nobody can dispute the simple fact that whatever's wrong with my database (regardless of what caused it or who is at fault) allows silent deletion and orphaning of client/resource records, or can they? Logical to wonder, then, could similar logic give control of one client's email to another? Wouldn't some simple debug time with a provided sample be useful to try and prevent this, in a model where strict separation of client identities is so important? This is the kind of thing that would generate a CVE of some significance in any other software package because it theoretically could be weaponized. They call it an "impersonation vulnerability," and like all CVE's, they are published in the expectation that the software developers will be gracious and prepared to collaborate to fix them. The whole process of identifying them is pointless without the researchers' reasonable expectations of that courtesy. We all want to protect hapless admins and users... or don't we? They don't get to try and charge the researchers to fix it, either.

Business? barely. it lost 770 euros last year. thought i might turn it around on top of solid software, but...
Previously unseen? maybe, but in this atmosphere i wouldn't expect anyone to admit to me if they had seen it before.
Non-reproducable? them's big words when developers are refusing to even investigate.
Paying for support? please, indulge this aside: i defected to Belgium in 2003 when our president started a war in a 9/11 unrelated country, lol, but in 1999 i had this great job. a startup in SF and I was desktop support. i was great, stayed after hours fixing things (if only because the heat and traffic were too heavy to go home at 6pm).. but ADHD and traffic had me arrive a few minutes late some mornings. I had a super picky manager who ignored how everyone said I was the best in my position in 3 years of the biz existing, and instead focused on those few minutes. He fired me, which caused 24 hours depression, until the next morning when a friend in the office called me. He whispered that the manager who fired me had just been fired himself as a result! next day, i called about getting my job back. they explained company policy: it would be a security risk because now i might hold animosity toward the company and, with the unlimited access my job requires, do anything. not that kind of guy, i said, but i do actually understand. and with me now understanding the danger of office politics, that was my last job before starting Sustainable Hosting with 4 friends. We never made much money so they all left me here alone (USA living being so much more expensive), then later I got MS after being attacked by 5 teenagers, and here we are.

Whats the damn point, right? ...the other lesson here was the security policy one:
1. Why would I pay for support at any price, when experience shows I can't expect preferential (or even neutral) treatment, certainly not after this exchange?
2. Watching how implications of possible code weaknesses are treated, no matter how politely presented and even re-excused when misunderstood... How would I know if whatever fix was made didn't just appear to fix my problem, but leave unresolved issues to pick up later?
3. What should I now expect from this software going forward, knowing it's main developer's defensive, passive-aggressive response to a CVE-worthy bug report I spent weeks refining and preparing, including VMs for experimentation? Again I'd like to note: if those experiments left behind a fixed copy, i would still have to figure out what was done to fix it and apply it to the live server and live database myself. Cant risk someone having made an email address on the live one before I dump the fixed dev database back over the live, do you follow?

Now I am left with only one possible conclusion: I have to stop singing ISPConfig's praises to everyone I meet (hell, I think even the website touts the fact that we use and have supported it proudly) and ditch the panel, to start over with something else. I can't escape that this must be the conclusion, whether the paid support costs 5000 or 5.00. And it's depressing. I thought these weeks of work would produce thanks and warm, concerned responses. Hoped to build mutual respect with till, who til now I considered a real rockstar. I am saddened that this. All of it is, what's the German terms my mom always said? Right: schrecklich. das ist aber schade....

So. It was nice for years, it's been real this week. But it hasn't been real nice. I will check this forum again once in the hopes that any other entity active on this project sees the work and wisdom I'm laying down and turns the opinion of apparently everyone here minimally back to neutral. If not, my hands are tied. Wasn't kidding when I said this might be it for us; trying to save a world when those whose kids would benefit from that don't care and treat you like trash without sympathy for major illness and no cashflow, its getting older than I am. A real teachable wake-up moment for me, perhaps. Those are never easy to accept, but apparently hardest when they signal a final end to something. In which case, enjoy your fascist nightmare planet.. I'm gonna go out tomorrow and celebrate that my life expectancy ends only 8 years from now.

CHEERS!

 

thank you, sir, for being the first one to even speak to me as if i am a human worthy of politeness.

AI...I asked it to produce a gracious and pleasant letter. I edited it, gave it back, and asked it to make it more gracious, to emphasize and move up those parts. i mean, para 1, "first, thank you" plus indication i have contributed money. para 2 "because i care". para 3 "i realize..i am committed". para 4 "I apologize". Details, then "suggestions & questions" (i just cant find "demand" in there). closing, "thank you again" for the panel. i mean... am i missing something here? then the 2 hours i spent better explaining myself and concerns without ai help? painfully aware text can be misinterpreted here. had no problem clarifying that extensively. why am i still being treated like a rude attempted thief criminal here? whose observations are invalid by default?

as i have asked others, i am asking you with your apparently level head, to follow: i read and understood what was said about those fields, which led me to believe that already in the client table (not real deep), if I made all the clients as id 1, all of those should also be 1. But they're not. but nobody seems interested in that.

does that lead to further corruption? well nobody could tear themselves away from tearing me down to answer.

I agree; sysadmin actions between doing something that warns you not to do it (i didn't), through vigorously changing settings (i haven't), through messing with the database directly (i wouldn't, evidenced by the fact that I still haven't when faced with this problem, instead i trustingly came here for advice) could be to blame. I added some things with the api (which isn't discouraged with a warning) and used the migration tool once (ditto; its paid). now suddenly i see something scary, and this is what i get. not a good sign.

gonna go get on with my non-biz life now. thanks anyway for the attempted save.

 

Please keep personal matters out of technical discussions. This is a technical forum, and it's important that we stay focused on the topic at hand.

We already tried to assist you in the original thread you created regarding this issue:
https://forum.howtoforge.com/threads/delete-client-huge-inconsistency-what-to-do.94378/#post-466472

However, you've since opened another thread and insisted that the developers prioritize your particular case, which you’ve labeled as severe, a CVE, a critical bug, etc. Additionally, making threats or casting doubt on the integrity of the project and its contributors is not constructive.

This kind of approach is not how collaboration works in an open source community.

You encountered an issue on your system related to data in your database, most likely due to a manual misconfiguration, and now expect someone to look into it because it might be a bug in ISPConfig. If everyone were to misconfigure their system and then pressure the developers for free support on the grounds that it could be an ISPConfig bug, that would be completely unreasonable.

Finally you can either try to debug the issue yourself and share your findings here in the forum to potentially gain further insights, or consider reaching out to the business support for more direct assistance.

Please reconsider how you want to approach the situation going forward.

 

Okay, great.....
Thought a new thread would be useful. Because since the first, I clearly did try to debug the issue myself. Thought that leaving behind my last thread which was more of a "help help im drowning, rescue me without guarantee of compensation!" sounding thing, would be a good idea after i left it dead for weeks and came back with an organized, researched report. Apparently every thought-out choice I make is not considered and is not just wrong by default now, but offensive to you.
Repeatedly tried to convey gratitude that ISPConfig exists and dispel any concept of insistence.
Tried to clarify (note that original messages had no "personal information") why I might be considered for softer treatment. Explained lack of threat, gratitude instead of doubt. Spent literal hours just trying to explain myself.
Offered running virtual machines with several database states for your debugging.
Failing that: Even suggested maybe a most rudimentary database check at upgrade time would be enough, both to notify a sysadmin that they might be in this kind of trouble, and to deflect any "righteous" anger when they delete two clients instead of one, or silently give access to client x's email to client y.
Lastly, used a true story to demonstrate hard feelings isn't why why I see it as irresponsible and pointless to pay for support to a panel made mostly by someone who won't even comment further except by "liking" any post that isn't me.
Thanks for making it clear that nobody is willing to listen to any of that as I have tried over and over again to clarify this.
A final gratitude to you because my way forward is now amazingly clear. Wish it happened ten years ago.
And I wish I could now wish you success in this endeavor, but I can't wish this gets adopted further, because I expect the oversight and attitude will affect someone else, eventually, and much worse.
So I wish you all whatever life you are generating for yourselves.
Goodbye!

 

Alright, best of luck!