Bug description
Un asset adaugat in dashboard nu poate fi vizualizat.

Step to reproduce it

• adauga un asset nou in dashboard
• click pe asset pentru vizualizare
• componenta de asset view nu se incarca

Expected behavior
Dupa adaugarea unui nou asset, ca user pot sa vizualizez acest nou asset.

Additional info
Bug pentru API: code4romania/anabi-gestiune-api#146
API intoarce 200 OK pentru un asset care nu are address. API response nu intoarce niciun obiect, in cazul in care nu exista address pentru asset.

Ok, cam asa arata acum pagina de vizualizare a unui bun:

Momentan se pot adauga inculpati la un bun, dar, odata adugati, nu se pot modifica datele inculpatilor.
Vrem sa putem modifica datele inculpatilor. (practic, operatia de edit/update din CRUD).

Trebuie implementate atat BE cat si FE.

• Backend - endpoint de modificare inculpat
• Frontend

Validare pe campurile de tip numaric value sa nu poata sa primeasca valori negative.

Descriere

Ca un utilizator ANABI, vreau sa adaug un proprietar la un bun.
Un bun poate sa aiba zero, unul sau mai multi proprietari.

Campuri proprietar

Campurile pot fi vazute in Confluence - Entitati

Proprietar - proprietăți

• Tip: Persoana fizica / Persoana juridica
• Persoana fizica (obiect)
• Persoana juridica (obiect)

Persoană fizică - proprietăți

• Nume (camp obligatoriu)
• Prenume (camp obligatoriu)
• Nationalitate (camp obligatoriu)
• identificator - camp liber
• CNP (camp obligatoriu) - pentru cei cu nationalitate RO (daca la Nationalitate au completat alta tara in afara de Romania, campul asta devine free form ca sa completeze anything they might need)
• Data de nastere -

Persoană juridică - proprietăți

• Nume (camp obligatoriu)

• Tara de care apartine (camp obligatoriu)

• CUI - pentru cei care apartin de RO

• Identificator - camp liber - pentru cei care nu apartin de RO

  Unul din campurile CUI sau Identificator e camp obligatoriu.

• Frontend

• Backend - list proprietari bun

• Backend - adaugare proprietar la un bun

Redenumire in frontend camp Stare actuala in tip procedura.

Ca utilizator ANABI vreau sa pot sa adaug un spatiu de stocare in platforma.
Acest spatiu de stocare ar tb sa fie vizibil in lista de spatii de stocare care este dezvoltata ca parte a #42

Pe dashboardul de vizualizare spatii de stocare in stanga jos a ecranului tb sa existe un buton pentru Adauga spatiu de stocare, similar cu dashboardul de bunuri.

Un card pentru introducere spatiu de stocare trebuie sa fie displayed, care sa contina urmatoarele elemente:

• Nume: string
• Tip: Contracted
• Cod Judet: string,
• Oras: string,
• Strada: string,
• Bloc/Cladire: string,
• Detalii: string

Adaugarea unui spatiu de stocare se face printr-un call in endpoint:
POST /api/StorageSpaces

Verificare API: http://backend.anabi-dev.code4.ro/swagger/index.html
Sectiunea StorageSpaces.

Se pot adauga mai multi inculpati la un bun.

Wireframe: atasat

Campuri: (* inseamna camp obligatoriu)

Tip inculpat (PF sau PJ) *

In functie de ce alege (PF / PJ), apar un set de campuri.

Persoana Fizica

Nume *
Prenume *
Nationalitate *
Identificator - pentru cei cu nationalitate RO este CNP; daca la Nationalitate au completat alta tara in afara de Romania, campul asta devine free form ca sa completeze anything they might need *
Data nasterii

Persoana Juridica

Nume *
Tara de care apartine *
CUI (daca tara e Romania) * / Identificator (daca nu apartine de Romania) *

Note

In screenshot apar 2 campuri, CNP si Identificator. Trebuie sa apara un singur camp (CNP/Identificator).

Swagger:

Trebuie o pagina noua, cu un tabel asemanator cu cel din pagina de listare bunuri ("Bunuri"), care insa sa aiba coloanele pentru Spatii de Stocare (Depozitare) din pagina de Entitati:
https://codeforromania.atlassian.net/wiki/spaces/ANABI/pages/267256067/Entit+

Si anume:

• ID
• Nume
• Tip
• Adresa - (toate campurile din adresa concatenate intr-un singur camp)

Ideal ar fi ca tabelul sa fie similar cu cel din "Bunuri" si anume sa aiba :

• sortare pe coloane
• paginare (in frontend)
• cautare

Taskuri

• Backend - actualizare endpoint sa intoarca campurile care trebuie
• Frontend - tabelul

Endpoint PUT api/assets/{assetId}

Guidelines: https://codeforromania.atlassian.net/wiki/spaces/ANABI/pages/423657490/API+Guidelines?atlOrigin=eyJpIjoiZjllNDc0MzE5MWQyNDM2MThjNmY0YjA4MGE1NzNjZmIiLCJwIjoiYyJ9

• Frontend
• Backend

Feature de upload de documente pentru un bun.
Documentele pot fi jpg, png, pdf.

Ca un utilizator ANABI, vreau sa adaug un storage space (existent) la un bun. Practic, sa marchez un bun ca fiind intr-un spatiu de stocare, spatiu de stocare care exista deja in DB.

Deci, ar trebui un formular care sa listeze spatiile de stocare din baza de date, si apoi utilizatorul ANABI sa aleaga unul, si acel bun sa fie asociat cu spatiul de stocare respectiv.

Asociere bun - Backend
Controller nou in Anabi - Features - Assets: AssetStorageSpaceController

Cu endpoint nou pt adaugare:
PUT /api/assets/{id}/storagespace

Payload:
*storageSpaceId
*entryDate

Endpoint pt GET
GET /api/assets/{id}/storagespace

Si intoarce un storage space (cu toate campurile din storage space, nu cu campurile din bun).

Handler nou: AssetStorageSpaceHandler
Vezi model AssetHandler

• Backend - listare spatii de stocare
• Backend - asociere bun la un spatiu de stocare [PUT]
• Frontend
• Backend - DELETE - dez-asociere bun la un spatiu de stocare (Alex Albu)
• Backend - GET (sa vedem spatiul de stocare adaugat la un bun) (Cosmin Popescu)

Ok, cam asa arata acum pagina de vizualizare a unui bun:

Momentan, se pot adauga inculpati la bun, dar nu se pot sterge. Dorim sa se poata sterge.

Trebuie implemntat si BE, si FE.

• Backend - endpoint nou de stergere al unui inculpat
• Frontend

Subtaskuri

• Backend
• Frontend
• Endpoint pt Decisions
• Endpoint pt RecoveryBeneficiaries
• Endpoint pt CrimeTypes
• Backend - Endpoint scop masura asiguratorie
• Populate DB on dev environment
• Backend - proprietatile starile noi ale unui bun.

Descriere
Solutia = act juridic
Pot adauga o solutie sau mai multe la un bun.

Vezi pagina Entitati

In afara de campurile solutiei, mai trebuie sa apara un camp readonly cu starea actuala a bunului,
si un camp in care utilizatorul poate alege noua stare a bunului (sau poate s-o mentina pe cea veche).

Cand utilizatorul alege o stare noua, noi vom face o validare daca tranzitia din vechea stare a bunului catre noua stare este valida.

Aceasta validare o va face Backend-ul deoarece el are informatiile necesare pe baza entitatii Stare (Vezi pagina Entitati, respectiv entitatea Stare - acolo se specifica ce stari urmatoare sunt posibile pentru o stare, cat si anumite constrangeri).

Eu vad 2 variante pentru Frontend:

poate face apel Ajax catre Backend pentru validare (gen, sa verifice daca bunul X poate sa treaca in starea S2; backendul are deja celelalte informatii necesare pentru validarea tranzitiei - starea actuala a bunului, categoria bunului, valoarea lui estimata, etc )
sau poate trimite formularul catre Backend si se va intoarce cu eroare din Backend, si utilizatorului i se va arata iar formularul de adaugare solutie, cu campurile completate anterior de el, si cu erorile din Backend.
Prima varianta (cea cu apel Ajax) e preferabila, dar, daca e greu de implementat, atunci e foarte buna si varianta 2.

Exemple tranzitie valida:

starea ramane aceeasi
Sechestru (stare actuala) --> Ridicare sechestru (stare noua)

Notite pentru wireframe
grafica e total cu sens de sugestie, e un wireframe, nu o specificatie exacta, chiar sper sa nu arate asa in forma finala )
campul "Instanta" e readonly, utilizatorul nu-l poate schimba. Acest camp se competeaza de noi pe baza numarului de dosar introdus de utilizator (nr dosarului include si instanta)
sunt deschis si la alte sugestii de butoane, etc (ex: eu am pus radio la Solutie definitiva / nedefinitiva, se poate face si altfel, ex butoane separate, select etc).
unele campuri ar trebui sa apara doar daca utilizatorul selecteaza altceva inainte.
"Data rămânerii definitive" tb sa apara doar daca utilizatorul a bifat "Definitiva"
"Stare noua bun" sa apara doar daca utilizatorul a ales "Schimb starea bunului".
Campurile din wireframe de la "Stare X" sa apara doar daca utilizatorul doreste sa schimbe starea in "X" SAU daca utilizatorul doreste sa pastreze starea bunului si starea curenta e "X" (unde X e Sechestru, Confiscare , Valorificare, etc). Practic intotdeauna va aparea o subsectiune din wireframe de la "Stare X", in functie de ce alege utilizatorul.

Wireframe

GET /api/assets/{id}/address

• Backend - endpoint nou GET sa intoarca adresa bunului
• Frontend - sa afiseze adresa bunului in "Detalii bun"

Ca un utilizator ANABI, vreau sa adaug o adresa la un bun.
E vorba de bunurile nedepozitate in spatii de stocare.

Campurile de la adresa (luate de pe pagina https://codeforromania.atlassian.net/wiki/spaces/ANABI/pages/267256067/Entit+i):

Adresa:

• Județ - camp obligatoriu, obiect
• Localitate - camp obligatoriu, camp liber
• Strada - camp liber
• Numar - numarul cladirii pe strada (string)
• Detalii - camp liber

Detalii backend (scrise de Alex Albu):

Endpoint:

POST api/assets/{assetId}/address

In cadrul acestui User story se vor adauga coloanele din BaseEntity la tabela AddressDb. AddressDb tb sa mosteneasca BaseEntity si tb generata o migrare pentru baza de date. Daca in DbInitializer se adauga adrese, vor tb actualizate si acestea sa contina noua coloana.

Vezi liniile generale de urmat aici

Link vechi Jira

• Backend - adaugare adresa la bun
• Frontend
• Backend - modificare campuri adresa sa fie fix cele din pagina de Entitati

• campul de unitati de masura trebuie sa devina free text - un utilizator poate introduce orice valoare in acel camp

Problema: un utilizator sa poata sa vada pe un singur panel un singur tip de bunuri in functie de tipul de procedura

solutii:

• panel separat pentru fiecare tip de procedura
• filtrare pe tipul de procedura

Id ul pentru un bun are doua parti

• identificarea interna, id ul pe care il primeste la ANABI
• id extern, numarul de dosar pe baza caruia a ajuns la ANABI
  Ambele trebuie afisate in frontend si ca parte a introducere bun nou.

Feature de corelare bunuri -> un bun introdus la un moment dat este "spart" in mai multe bunuri, pentru valorificare, etc.
Trebuie sa putem sa display in frontend aceasta relatie de corelare intre un bun parinte si bunurile copii.

Bug description
Running sudo npm install inside the root folder fails with:
gyp ERR! stack Error: EACCES: permission denied, mkdir '/home/user/anabi-gestiune-client-master/node_modules/node-sass/.node-gyp'

Step to reproduce it
Following the installation steps on a Centos7 machine.
npm and node are installed and at the latest stable version.

Expected behavior
Successful installation.

Additional info
I also tried using sudo chown -R user:user /home/user/anabi-gestiune-client-master/node_modules/ but I still get the same error.

As dori sa pot lista instantele, intr-un tabel asemanator celui care apare cand listez bunurile.

• Tabelul ar trebui sa fie paginat.

Proprietatile unei instante sunt specificate in
https://codeforromania.atlassian.net/wiki/spaces/ANABI/pages/267256067/Entit+i

Lista instantelor poate fi gasita aici:
http://portal.just.ro/SitePages/Instante.aspx

• Backend - modificare campuri in DB
• Backend - populare instante cu lista luata de pe portal.just.ro (Cosmin Popescu)
• Frontend cu backend mockuit
• Legat FE de BE (Stefan Oproiu)

Denumirile de judete sau orice alt string care contine caractere cu encodare speciala trebuie sa fie afisate corect
Exemplu:

Bug description
Dupa ce se sterge un inculpat al unui bun, cardul cu inculpatul sters ramane afisat pe pagina de descriere a bunului.

Step to reproduce it
Se navigheaza pe http://anabi-dev.code4.ro
Bunuri -> primul bun -> se sterge un inculpat de pe bun

Expected behavior
Cardul cu detaliile inculpatului nu ar trebui sa mai fie afisat dupa stergere.

Additional info

Un bun aflat in procedura de valorificare anticipata are 2 stari posibile:

• evaluare
• valorificare

Fiecare din etape contine informatiile:
Etapa de evaluare

• evaluare bun

  • da/nu
  • comisie (nume, prenume)

• raport evaluare

  • necontractat
  • contractat
  • primit

Etapa de valorificare

• constituire comisie
• licitatia 1 - data, comisie
• licitatia 2 - data, comisie
• licitatia 3 - data, comisie
• licitatia n - data, comisie

Bug description
Fiecare bun poate avea o singura adresa adaugata.
Dupa ce a fost adaugata o adresa pe un bun, lista de adaugare proprietati nu mai trebuie sa contina adresa.

Step to reproduce it
Adauga o adresa pe un bun.
Lista de adaugare proprietati nu mai trebuie sa contina elementul Adresa.

Expected behavior
La un bun se poate adauga o singura adresa. Daca trebuie modificata acea adresa, trebuie folosit feature ul de modificare adresa: #39

Additional info

Dupa ce terminam #40, (adaug un inculpat la un bun), trebuie sa si putem vedea in pagina cu detaliile bunului si inculpatii asociati bunului respectiv.

Un bun poate avea 0, 1, sau mai multi inculpati. Unii pot fi persoane fizice, altii persoane juridice.