Your permissions test is the diagnosis. If it only works when the collection
grants the action to Everyone, then the call is arriving with visitor
authorisation — not yours. The server isn’t failing to register your
permissions. It isn’t seeing you at all.
That matters because of how the two permission systems line up. In the
dashboard you’re a Wix user, which is a different identity from the roles the
CMS permission table is written in — those are member-side roles. Frontend
dashboard code calling wixData directly depends on that translation happening,
and in your case it isn’t. Everyone is the only row that doesn’t require an
identity, which is exactly why it’s the only row that works.
Move the write into a backend web module and the problem disappears, because
suppressAuth bypasses collection permission checks entirely. Identity
resolution stops mattering.
backend/tickers.web.js
import { Permissions, webMethod } from ‘wix-web-module’;
import wixData from ‘wix-data’;
export const updateTicker = webMethod(
Permissions.Admin,
async (item) => {
return wixData.update(‘All_Tickers’, item, { suppressAuth: true });
}
);
Then from the dashboard page:
import { updateTicker } from ‘backend/tickers.web.js’;
await updateTicker(myItem);
Note the .web.js extension — suppressAuth only works in backend code, so this
has to be a real backend module, not a helper file in page code.
Two things worth doing while you’re in there.
Put your collection permissions back. If you’ve currently got All_Tickers set
to let Everyone update just to make the dashboard work, that’s a public write
endpoint on your live site right now. Once the write goes through the backend
module you can set it back to admin-only and it’ll still work.
Keep Permissions.Admin on the web method rather than loosening it. If the web
method itself rejects your call from the dashboard, don’t switch it to
Permissions.Anyone to get past that — that would make the write callable by
anyone, and Wix’s own docs note that dashboard page code is publicly visible.
A rejection there is actually useful: it’s clean proof the identity isn’t
resolving as admin, which is the thing to put in a support ticket.
On the ticket — your point about the months-old backup behaving identically is
the strongest evidence you have, so lead with it. Unchanged code, unchanged
backup, changed behaviour, and a permission matrix where only Everyone works.
That’s a platform-side change, and it’s specific enough to be actionable. But
don’t wait on it; the backend module makes you immune either way.
Last thing: treat the upload error separately for now. “Unexpected error” is
too vague to diagnose, but if that dashboard also writes to a collection it’s
plausibly the same root cause wearing a different message. Fix this one, then
retest the upload before chasing it.
