Hi James,
To be honest, I’m a bit sad that I have to bring this issue to a public forum and defend my actions instead of focusing on the core problem. Still, I truly appreciate you taking the time to join the discussion personally.
Please allow me to clarify the timeline as I experienced it from the perspective of a user and developer:
July 9
I submitted a support ticket describing a critical “Unauthorized” error that appears when using the default Toggle component linked to a many-to-many property between the Users ↔ Audio collections.
I included a detailed description, specific steps to reproduce the bug, and screenshots.
Even at that point, it was clear from the console that the issue was unrelated to any component – and certainly not the private one – but instead was tied to backend or database logic when modifying relationships.
The response I received was: “Please resolve this first with the component developer” – which, in this case, is me.
July 10–11
I sent several updates to the same ticket – including logs and additional details. But I received no reply or confirmation of receipt.
July 12
I sent a simple follow-up message:
“Did you receive my emails where I described the database write error?
I need confirmation that you’ve seen them and that someone is working on the issue.”
Again, no response.
July 14
At that point, I felt like my messages were either being lost to spam or ignored, so I opened a new ticket where I once again summarized the entire issue – this time with zero presence of any private component.
Yet I received the exact same reply as before – that the issue was due to a private component.
Even though I had already submitted screenshots and test results clearly showing that the component had been completely removed from the app.
Just to clarify further – I created a test screen that contains only the default Toggle component connected to a many-to-many relationship between Users ↔ Audio.
There are no other components, no actions – and yet clicking this toggle still triggers the “Unauthorized” error.
You can see this for yourself – you have access to the app.
And once again, I want to stress: the Audio Player component is no longer present in the app at all.
I hope this summary helps clarify the situation.
My goal was never to apply pressure on the forum, but simply to get any kind of response – especially after multiple attempts via support felt completely one-sided.
And one personal note at the end.
In recent days, I’ve had the strong feeling that “private component” has become a kind of magic word at Adalo – as soon as one appears in an app, all other root causes seem to be ruled out automatically.
I understand you can’t support all third-party code, but in this case, I’m the developer of the component myself and have full control over it.
Even so, I removed it from the app and provided clear evidence that the bug still persists.
I’m convinced that the issue is not a general database problem – but a very specific corruption in the many-to-many relationship between Users ↔ Audio.
In my case, the two properties (UserLike, UserFavorite) appear to be broken in a way that I cannot fix on my own.
James, please believe me – I truly like Adalo.
I’ve spent years building on your platform. I can feel how it’s evolving, and I’m genuinely excited with every improvement.
It’s a great tool for no-code developers, helping them level up in their work.
And it has a fantastic community – @Dilon for example, deserves a huge thanks for his constant willingness to help others.
That’s exactly why it’s frustrating to me that the issue I reported back on July 9 only started receiving real attention after I posted here on the forum.
Unfortunately, I repeatedly feel that my replies to the support emails are not correctly linked to the open tickets – I currently have two other cases where I replied, but never received any follow-up.
This issue in my app is not a general one that could be interpreted as systemic – it’s a damaged Audio collection and its relationship with Users. And that’s why other developers aren’t reporting this. That’s my conclusion.
And if I’m wrong – I’ll buy you dinner. 
Best regards,
Kamil