e2e changes

repositories/partnerRepository.go

@@ -87,30 +87,65 @@ func (r *partnerRepository) GetPartners(aid, pid, uid int) ([]models.Partnerinfo
 	var q1 string
 	var args []interface{}
 
+	// Every variant joins partnerlocations, and that join is the whole point.
+	//
+	// ── It is what separates our partners from somebody else's ──────────────
+	//
+	// `partnerinfo` is shared. It has no column saying which product a row
+	// belongs to — no configid, no appid — so a partner created by another app
+	// on this database is indistinguishable from ours by its own fields, and
+	// this read used to return every Active row on the platform. The console
+	// made that worse rather than better: it asks `getapplocations` for EVERY
+	// region and then fetches partners region by region, so the applocationid
+	// filter below never narrowed anything.
+	//
+	// `partnerlocations` is the difference. Only `CreatePartner` writes it —
+	// one row per region, in the same transaction as the partner — so a row in
+	// that table means "registered through this console". The partners that
+	// predate it were inserted by hand and have none, which is why two of them
+	// are called "Test".
+	//
+	// ── The region filter reads the link table, not the home region ─────────
+	//
+	// `partnerinfo.applocationid` is the HOME region — CreatePartner writes
+	// `regions[0]` there — while partnerlocations holds every region covered.
+	// Today those are always the same one region, because `regionsOf` returns a
+	// single district and the console's form offers one ("never a set"). So
+	// this is not a behaviour change yet; it is the filter being applied to the
+	// column that is allowed to grow. The moment a partner covers two cities,
+	// filtering on the home region would hide them from the second, and the
+	// link table is the whole reason that table exists.
+	//
+	// DISTINCT for that same future: a partner covering three regions has three
+	// rows in the join and is still one partner. Only partnerinfo columns are
+	// selected, so there is nothing per-region for it to fail to collapse.
+	const columns = `select distinct p.partnerid,p.applocationid,p.partnertypeid,p.partnername,
+			 p.primarycontact,p.primaryemail,p.contactno,p.address,p.suburb,p.state,p.city,p.partnerimage
+			 from partnerinfo p
+			 inner join partnerlocations l on l.partnerid = p.partnerid
+			 where p.status='Active'`
+
 	if pid != 0 {
-		q1 = `select partnerid,applocationid,partnertypeid,partnername,primarycontact,primaryemail,
-			 contactno,address,suburb,state,city,partnerimage 
-			 from partnerinfo where status='Active' and partnerid=?`
+		// Scoped the same way on purpose: asking for a partner by id must not
+		// be a way round the separation above.
+		q1 = columns + ` and p.partnerid=?`
 		args = append(args, pid)
 
 	} else if aid != 0 {
-		q1 = `select partnerid,applocationid,partnertypeid,partnername,primarycontact,primaryemail,
-		      contactno,address,suburb,state,city,partnerimage 
-			  from partnerinfo where status='Active' and applocationid=?`
+		q1 = columns + ` and l.applocationid=?`
 		args = append(args, aid)
 
 	} else {
-		q1 = `select partnerid,applocationid,partnertypeid,partnername,primarycontact,primaryemail,
-		      contactno,address,suburb,state,city,partnerimage 
-			  from partnerinfo where status='Active'`
+		q1 = columns
 	}
 
+	q1 += ` order by p.partnername, p.partnerid`
+
 	err := r.db.Raw(q1, args...).Find(&data).Error
 	if err != nil {
 		return nil, err
 	}
 
-	print(q1)
 	return data, nil
 }
 
@@ -615,13 +650,17 @@ them are named "Test".
 
 Where a partner works is recorded twice, on purpose and not by accident:
 
-  partnerinfo.applocationid   their home region — `GetPartners` filters on it
-                              and the rider app reads it
+  partnerinfo.applocationid   their home region — the rider app reads it
   partnerlocations            every region they cover
 
 Both are kept in step here. Writing only the first would confine a partner to
-one city, and writing only the second would hide them from every existing
-query. */
+one city, and writing only the second would hide them from the rider app.
+
+`GetPartners` reads the SECOND: it joins partnerlocations, which both scopes a
+region query to every city a partner actually covers and — because only this
+function writes that table — separates partners registered here from the ones
+another product put in the shared `partnerinfo`. So the link rows are not
+bookkeeping; they are what makes a partner ours. */
 
 // CreatePartner onboards a delivery partner and records the regions they cover.
 func (r *partnerRepository) CreatePartner(input models.NewPartner) (int, error) {