pezkuwichain/pwap
1
0
Fork 0
mirror of https://github.com/pezkuwichain/pwap.git synced 2026-08-12 20:51:37 +00:00
Code Issues Packages Projects Releases Wiki Activity
Files
fix/repair-missing-db-functions
pwap/web/supabase
T
History
pezkuwichain 658c99b9bb fix(db): repair functions their migrations recorded but never created 
A user hit "Could not find the function public.upsert_user_profile(...) in the
schema cache" when toggling push notifications. The function was missing, and so
were the profiles columns it writes — while schema_migrations listed both 002 and
004 as applied.

That pattern turned out to be widespread. Comparing every function declared
across the migrations against the live database: 25 are missing, from six
migrations all recorded as applied. Their tables exist; only the function bodies
are absent. Those files carry "Run this in Supabase SQL Editor" headers, so they
were pasted in by hand before apply-migrations.sh existed and a run that stopped
partway was still recorded. The runner has skipped them ever since, which is why
this stayed invisible until it surfaced as a user-facing error.

apply-migrations.sh is not at fault: it wraps each migration and its tracking row
in one transaction with ON_ERROR_STOP, so it cannot half-record anything. It
inherited a dirty history.

Three of the 25 are actually reached by the app, so those are repaired here:

  apply_for_tier_upgrade   MerchantApplication.tsx:213 - tier upgrades were dead
  check_tier_eligibility   called by the above
  update_p2p_reputation    shared/lib/p2p-fiat.ts:803 - reputation never updated

This is forward-only repair, not a replay of the source files. Replaying them
would abort on their bare CREATE POLICY/INDEX/TRIGGER statements now that the
tables exist, and 20241117054602 in particular would overwrite 016's newer
cancel_expired_trades with its own older definition.

Verified before writing: every table the three functions touch is present, and
the whole migration was run inside BEGIN/ROLLBACK against production — three
functions created, signatures matching what the callers pass, then rolled back
leaving nothing behind.

The remaining 22 stay missing on purpose and are listed in known-schema-gaps.txt.
Nothing calls them, and several are trigger bodies whose triggers were never
created either, so creating them would switch on behaviour that has never run.

Also adds a drift check to apply-migrations.sh: after applying, it compares
declared functions against the database and flags anything missing that is not in
the known-gaps list. Being recorded as applied is not proof of having been
applied, and that gap should never again be discovered by a user. The check
already earned itself — it caught update_p2p_reputation, which my own first pass
had missed to a regex that dropped digits from function names.

upsert_user_profile and the profiles notification columns were applied directly
to the database from their existing migrations (002, 004), which are fully
idempotent; no new migration was needed for them.
2026-07-30 09:16:01 -07:00
..
deploy
fix(db): repair functions their migrations recorded but never created
2026-07-30 09:16:01 -07:00
functions
fix(security): identify the caller from their token, not the request body
2026-07-30 04:05:03 -07:00
migrations
fix(db): repair functions their migrations recorded but never created
2026-07-30 09:16:01 -07:00
tests
feat: add Telegram mini app connect for P2P access
2026-01-29 21:27:13 +03:00
.gitignore
feat(p2p): add Phase 4 merchant tier system and migrations
2025-12-11 10:39:08 +03:00
config.toml
feat(p2p): add Phase 4 merchant tier system and migrations
2025-12-11 10:39:08 +03:00
DEPLOY_RUNBOOK.md
docs(p2p): track the security deploy runbook (ordered migrations, edge functions, secret names)
2026-07-25 02:46:40 -07:00
README.md
Reorganize repository into monorepo structure
2025-11-14 00:46:35 +00:00

README.md

Supabase Setup Guide

Overview

Bu klasör Supabase database setup için gerekli migration dosyalarını içerir.

Quick Start

1. Supabase Dashboard'a Giriş

  1. https://supabase.com/dashboard adresine gidin
  2. PezkuwiChain projesini açın: https://supabase.com/dashboard/project/vsyrpfiwhjvahofxwytr

2. SQL Editor'ı Açın

  1. Sol menüden SQL Editor sekmesine tıklayın
  2. New Query butonuna tıklayın

3. Migration Script'ini Çalıştırın

  1. supabase/migrations/001_initial_schema.sql dosyasını açın
  2. Tüm içeriği kopyalayın
  3. Supabase SQL Editor'a yapıştırın
  4. Sağ alttaki Run butonuna tıklayın

4. Sonuçları Kontrol Edin

Migration başarılıysa şu mesajı göreceksiniz:

Database schema created successfully!

Oluşturulan Tablolar

1. profiles Tablosu

Kullanıcı profil bilgilerini ve referral verilerini saklar:

  • id - User ID (auth.users'a reference)
  • username - Benzersiz kullanıcı adı
  • email - Email adresi
  • full_name - Tam ad
  • avatar_url - Avatar resmi URL'si
  • referred_by - Referans kodu (kim davet etti)
  • referral_code - Kendi referans kodu (otomatik oluşturulur)
  • referral_count - Kaç kişi davet etti
  • total_referral_rewards - Toplam kazanılan ödüller

2. admin_roles Tablosu

Admin ve moderator rol atamalarını saklar:

  • id - Benzersiz ID
  • user_id - User ID
  • role - Rol: 'admin', 'super_admin', 'moderator'
  • granted_by - Rolü kim verdi
  • granted_at - Ne zaman verildi

3. wallets Tablosu

Kullanıcı wallet adreslerini saklar:

  • id - Benzersiz ID
  • user_id - User ID
  • address - Wallet adresi
  • network - Network adı (pezkuwichain, polkadot, etc.)
  • is_primary - Primary wallet mı?
  • nickname - Wallet nickname'i

4. referral_history Tablosu

Referral ödüllerini ve geçmişini takip eder:

  • id - Benzersiz ID
  • referrer_id - Davet eden user ID
  • referred_user_id - Davet edilen user ID
  • referral_code - Kullanılan referral code
  • reward_amount - Ödül miktarı
  • reward_token - Ödül token'ı (PEZ, HEZ, etc.)
  • reward_claimed - Ödül talep edildi mi?

Automatic Features

1. Referral Code Auto-Generation

Her kullanıcı kaydolduğunda otomatik olarak benzersiz 8 karakterli bir referral code oluşturulur.

2. Row Level Security (RLS)

Tüm tablolarda RLS etkin:

  • Kullanıcılar sadece kendi verilerini görebilir/düzenleyebilir
  • Admin'ler admin_roles tablosuna erişebilir
  • Public profiller herkes tarafından görülebilir

3. Timestamp Updates

Profile güncellendiğinde updated_at otomatik olarak güncellenir.

Test Etme

1. Sign Up Testi

  1. Web uygulamasını başlatın: npm run dev
  2. /login sayfasına gidin
  3. Sign Up sekmesine tıklayın
  4. Yeni kullanıcı bilgilerini girin:
    • Full Name: Test User
    • Email: test@example.com
    • Password: Test1234!
    • Referral Code: (opsiyonel)
  5. Create Account butonuna tıklayın

2. Database'i Kontrol Edin

  1. Supabase Dashboard → Table Editor sekmesine gidin
  2. profiles tablosunu seçin
  3. Yeni kaydın oluştuğunu doğrulayın
  4. referral_code alanının otomatik doldurulduğunu kontrol edin

3. Login Testi

  1. Oluşturduğunuz email ve password ile login olun
  2. Başarılı giriş yapabildiğinizi doğrulayın

Admin Rolü Ekleme

Bir kullanıcıya admin rolü vermek için:

  1. Supabase Dashboard → SQL Editor
  2. Şu SQL'i çalıştırın:
-- Get user ID first
SELECT id, email FROM auth.users WHERE email = 'info@pezkuwichain.io';

-- Then add admin role (replace USER_ID with actual ID)
INSERT INTO public.admin_roles (user_id, role, granted_by)
VALUES ('USER_ID', 'super_admin', 'USER_ID')
ON CONFLICT (user_id) DO UPDATE SET role = 'super_admin';

Troubleshooting

Problem: "relation 'profiles' already exists"

Çözüm: Tablolar zaten oluşturulmuş. Sorun yok, devam edebilirsiniz.

Problem: "duplicate key value violates unique constraint"

Çözüm: Bu kayıt zaten var. Normal bir durum.

Problem: Sign up başarılı ama profile oluşmadı

Çözüm:

  1. AuthContext.tsx'deki signUp fonksiyonunu kontrol edin (line 148-186)
  2. Browser console'da hata mesajlarını kontrol edin
  3. Supabase Dashboard → Logs → Postgres Logs'u inceleyin

Problem: "Invalid JWT token"

Çözüm: .env dosyasındaki VITE_SUPABASE_ANON_KEY değerini kontrol edin.

Security Notes

🔒 Row Level Security (RLS)

Tüm tablolar RLS ile korunuyor:

  • Kullanıcılar sadece kendi verilerine erişebilir
  • Public veriler (profil bilgileri) herkes tarafından görülebilir
  • Admin rolleri sadece admin'ler tarafından görülebilir

🔑 API Keys

  • anon key: Frontend'de kullanılır, RLS kurallarına tabidir
  • service_role key: ASLA frontend'de kullanmayın! Server-side only.

📝 Best Practices

  1. Production'da:

    • VITE_ENABLE_DEMO_MODE=false yapın
    • Demo credentials'ları kaldırın
    • Service role key'i asla commit etmeyin

  2. Development'ta:

    • Test verileri ile çalışın
    • Real user data kullanmayın

Additional Resources

Last Updated: 2025-01-28 Version: 1.0.0

Reference in New Issue View Git Blame Copy Permalink