---
# System prepended metadata

title: Zelda BE

---

# ZELDA BE 🐙

# TBD SPV V2

- [ ] (frontend) create new CASAVO valuations with V2
- [x] migrare transactionId su staging con lo script di edu (così non ci sono più non nullable) [katia]
- [x] togliere transactionId nullable da spv V1 e DB
- [x] populate business liness for v2 ucsc ( CASAVO recent spv with nullable business lines are on 2022-10-13 - no sense to migrate them)
- [x] make businessLines relation not nullable for v1 and v2
- [x] make businessLines not nullable in domain v1 and v2
- [~] move migrate user script to job
- [~] stop recurring valuations user job (as they are handled by `User` aggregate)
- [~] change logic of SPV repo for recurring
- [~] migrate users:
     * if user already exists by email on userservice - do not create or update it. just get the externalUserId and save it.
     * do not migrate users already anonymized on snake
     * if user doesn't exist we create it. la creazione può fallire se il phoneNumber esiste già -> non facciamo nulla vediamo quanti ne rimangono e poi valutiamo caso per caso. 
     * do not delete contact data during this migration but after.
- [ ] inform Fede Giudici / supertokens when the migration ends
- [ ] cancel contact details after the migration
- [ ] delete `User` aggregate (tables etc...)


## recurring valuations
- [ ] [during/post merge v1/v2] dobbiamo cambiare il metodo `SellerPropertyValuationRepository::findAllSubscribedUsers`, perchè attualmente quel metodo prende solo le SPV create con V2. Dopo la migrazione, il metodo dovrà ritornare tutto (perchè V1/User non funzionerà più)


# verificare con frontend:
- l'api di "edit contact" ora può fallire per un motivo in più (numero di cellulare già esistente)




# reconvert per seller che è undecided
- possiamo eliminare questa feature? così non dobbiamo preoccuparci di gestire il doppio transactionId

## after merge v1/v2:
- [ ] review `RecurringPropertyValuationUpdated` event, a lot of useless nullable
- [ ] potremmo togliere nullability anche da transactionId, ma su staging li abbiamo molti a null

# Cose che non facciamo per mancanza di tempo, da fare eventualmente dopo: 

- [ ] add test per buyer count in HubspotEmailService, se > 3 si usa un template altrimenti un altro