Miisiiks - Revision history

Caruste: /* Analüüs */

2018-06-05T19:45:23Z

Analüüs

← Older revision		Revision as of 22:45, 5 June 2018
Line 407:		Line 407:

	Klientrakendus oleks võinud olla eraldi projektis, mitte veebiteenusega samas kohas. Muidu on vajalik funktsionaalsus olemas. Omajagu kohtab küll poolikuid lehti või lihtsalt kohatäitvat funktsionaalsust, eriti töötaja tüüpi kasutajate juures.		Klientrakendus oleks võinud olla eraldi projektis, mitte veebiteenusega samas kohas. Muidu on vajalik funktsionaalsus olemas. Omajagu kohtab küll poolikuid lehti või lihtsalt kohatäitvat funktsionaalsust, eriti töötaja tüüpi kasutajate juures.


			===XML retsensioon===

			Kõik esitatud XML failid valideeruvad. XML andmefailile esitatud nõuded on täidetud, ehk 4 dimensiooniline, mõne koha peal näeb isegi vähemalt 5 dimensioonini minemist ja neile dimensioonidele on ka jaotatud mõistlike andmeid. Näiteks kasutaja nimi, email, automudel, auto tüübi nimi jne. Andmefailil on loogiline ja selge ülesehitus. Vajalikud teksti väärtused on ümbritsetud CDATA märgistusega, mis keelab selle sisu tõlgendada XML-ina. Samas on ka näha kuupäevade kasutamist ja isegi valuuta väärtuse sidumist euroga.

			HTML-i transformatsiooni faili nõuded on ka täidetud. Lisaks for-each-ile on kasutatud choose-i. Pärast transformatsiooni on kõik broneeringud ja nendega seotud andmed esitatud listi kujul. Arusaamatuks jääb miks on kasutatud osades kohtades id järgi sorteerimist <xsl:sort select="@id"/>, sest väärtustel, millele sorteerimist rakendatakse, puuduvad id-d.

			XML-i transformatsioon on ka olemas. HTMLi viies on ilusti selgelt näha kolm broneeringut, millest esimene ja viimane on “pending” ja teine on vastu võetud. Siin puhul on ka ilusti värvi kasutatud kus vastuvõetud broneering on tähistatud roheliselt ja ootel olevad punaselt. Ülejäänu on väga standartselt grupeeritud nii et on pealkiri (N: Klient, Auto) ja siis selle all on tabuleeritult toodud täpsem info selle osa kohta. Selgelt on kõik eristatav ja arusaadav, midagi kurta pole.
			XSLis on sisse tulnud väikene kirjaviga, kus iga Booking on kirjutatud kolme o’ga. Elementide nimedeks ei ole kasutatud “xsl:element-name” vaid on otse pandud nimetuis, mis ei tundu küll otseselt vigane olevat kuid siiski XLS’is võiksid need olemas olla. XLS’is ei ole samuti kasutatud atribuute, näiteks kaovad kõik ID’d ära. Need oleksid võinud tuua välja atribuutidena või elementidena iga elemendi juures. Kuna ID’d kaovad transformeerimisel ära, siis võib sellest tulla probleeme hiljem terviklikkusega.

Hmalkov at 20:48, 3 June 2018

2018-06-03T20:48:18Z

← Older revision		Revision as of 23:48, 3 June 2018
Line 383:		Line 383:

	Antud programm on hästi tehtud ning kommenteeritud. Kõik liidesed, mida oleks vaja on olemas, kuid puudavad Data Transfer Objekt klassid, mis ei ole küll nõutud, kuid API vastusteks sobiksid palju paremini. UnitOfWork tundub olevat antud projektis üleliigne ja API peale ei ole täielikult läbi mõeldud. API'le ei pääse ligi kuna ei ole tehtud viisi tokenite küsimiseks ega loomiseks. Kuna veebiteenus ja klientrakendus töötavad ilusti koos, siis see ei ole API absoluutselt vajalik, kuid kui juba tehtud on, siis võiks olla töötav. Kuna API ei ole hetkel kasutatav, siis ei ole antud projekt väärt maksimum punkte.		Antud programm on hästi tehtud ning kommenteeritud. Kõik liidesed, mida oleks vaja on olemas, kuid puudavad Data Transfer Objekt klassid, mis ei ole küll nõutud, kuid API vastusteks sobiksid palju paremini. UnitOfWork tundub olevat antud projektis üleliigne ja API peale ei ole täielikult läbi mõeldud. API'le ei pääse ligi kuna ei ole tehtud viisi tokenite küsimiseks ega loomiseks. Kuna veebiteenus ja klientrakendus töötavad ilusti koos, siis see ei ole API absoluutselt vajalik, kuid kui juba tehtud on, siis võiks olla töötav. Kuna API ei ole hetkel kasutatav, siis ei ole antud projekt väärt maksimum punkte.


			===Klientrakenduse retsensioon===
			Meeskonnale: [https://wiki.itcollege.ee/index.php/Meeskond_Raavo_V2%E2%84%A2 Raavo V2™]

			Klientrakenduses on olemas kõik Must have funktsionaalsused. Analüüsis välja toodud Nice to have funktsionaalsusi sinna lisatud ei ole. Rakenduses saab registreerida kasutajaid, muuta kasutajainfot, vaadata pakutavaid teenuseid, vaadata ning teha broneeringuid. Administraator saab broneeringuid hallata. Ka töötajatel võiks olla broneeringute haldamise võimalus. Vastaval lehel on olemas nupud broneeringute kinnitamiseks ja kustutamiseks, kuid töötaja kontoga sisenedes need nupud ei tööta. Töötaja saab rakenduses ainult broneeringuid vaadata. Võimalused teenuste lisamiseks või muutmiseks puuduvad.

			Kõikjal kus toimub info sisestamine võiks pärast edukat lisamist väljad tühjendada, mõnes kohas seda tehakse, mõnes kohas mitte. Niimoodi on palju mugavam järjest asju lisada, siis ei pea enne sisestamist välju ise tühjendama.

			Kasutajale tagastatavaid teateid võiks paremaks teha. Näiteks kohas, kus kasutaja saab autot lisada, kuvatakse pärast auto lisamist teade: „added new car type“. See teade võib kasutajas segadust tekitada, sest lisati ju uus auto, mitte auto tüüp.

			Broneeringute lisamise kõrval on väga oluline ka võimalus neid muuta ja kustutada. Sellist võimalust kasutajal kahjuks ei ole. Sarnane probleem on ka administraatori kasutajal. Seal ei ole näiteks võimalust teenuseid ja garaaže muuta. Neid saab ainult juurde lisada või kustutada. Garaažide majandamine on üldiselt puudulik funktsioon. Garaaži info on piiratud nime, ühe aadressi ja ühe telefoninumbriga. Usun et reaalne firma tahab rohkem vabadust oma info määramisel. Samuti tundub et töötaja tüüpi kasutajad peaksid olema seotud erinevate garaažide, mida praegu ei ole näha ehk veel üks koht kus tundub töötaja unarusse jäetud.

			Teenuste lehel võiks olla teenuse otsimise võimalus. Kui teenuseid on nimekirjas palju, siis on kasutajal raske endale sobivat teenust üles leida. Kahtlane on ka see et admin kasutaja peab erinevatele garaažidele teenuseid lisama, kuna admin kasutajal on väga lai võimekus kõige üle. Seega kui mõni garaaž peaks tahtma oma teenuseid muuta siis peab see tegevus käima läbi mõne lehe admini kuna igale lehel olevale garaažile ei või ilmselt anda kätte administraator kasutajat. Lisaks on teenuste lisamisel hinna piirang 1-100 vahel, kuna seal on ka võimalus määrata hinna ühik siis on erinvaid valuutasid arvestades tegu väga suure piiranguga. Valuuta tüüpide valimisel on probleemne ka vaba teksti kast mis lubab ühikuid ise välja mõelda. Samuti kui mingile teenusele määrata ühik siis broneeringu all näitab hinda eurodes aga üld nimekirjas kasutab teenuse registreerimisel määratud ühikut.

			Autode lisamisel on väljalaske aeg väga täpselt pandud (päev, kuu ja aasta), kuigi peaks piisama ainult aastast. Hea on see, et tuleviku kuupäevade lisamine on ära keelatud.

			Administraator kasutajaga on pisut liiast anda võimalus deaktiveerida see kasutaja millega ollakse sisse logitud. Kasutajate haldamise lehel tundub ka puudu olevat võimalus muuta teiste kasutajate rolle või siis luua uusi administraator või töötaja kasutajaid. Hetkel ei ole seega võimalik läbi kasutaja liidese uusi töötaja või administraator rollis kasutajaid luua.

			Javascripti kood on jaotatud funktsioonidesse, mis teeb selle paremini loetavaks. Funktsioonidel on asjakohased nimed ning kommentaarid.

			Lehel on ilusti lisatud erinevad vaated iga kasutaja õiguse kohta, nii et iga kasutaja saab oma õiguste tasemel funktsionaalsusele ligi. Kuigi pisut üleliigne on kõigile kuvatud menüüvalikutest hoida kõrvuti nuppe “garagefy” ja “home” mis mõlemad teevad täpselt sama asja.

			Klientrakendus oleks võinud olla eraldi projektis, mitte veebiteenusega samas kohas. Muidu on vajalik funktsionaalsus olemas. Omajagu kohtab küll poolikuid lehti või lihtsalt kohatäitvat funktsionaalsust, eriti töötaja tüüpi kasutajate juures.

Caruste: /* Veebiteenuse retsensioon */

2018-06-03T18:54:59Z

Veebiteenuse retsensioon

← Older revision		Revision as of 21:54, 3 June 2018
Line 382:		Line 382:
	Projekti käivitades luuakse andmebaasi kohe kolm erinevat rolli, Admin, worker ja User ning kõikidel neil on erinevad õigused teenuse kasutamisel. Ükski roll ei ole ülearu, kuid näiteks worker ei saa lisada teenuse tüüpe ja teenuseid seega mõndade rollide õigused tunduvad algselt poolikud. Kohe alguses luuakse ka administraator, mille parooli vahetamist peaks kasutajalt sisse logides nõudma, et muudaks. Selle jaoks võib ka teha teavituse ülesse serva, kui on algne parool, siis tuletaks meelde, et muutke ära. Igat kasutajat on ka võimalik deaktiveerida, sellehulgas ka administraatori oma. Administraatori kasutaja on ainuke, kelle oma ei tohiks deaktiveerida, kui ta on ainuke administraator. Ehk teha selle jaoks test, kui on ainult 1 isik administraatori rollidega, siis teda deaktiveerida ei saa.		Projekti käivitades luuakse andmebaasi kohe kolm erinevat rolli, Admin, worker ja User ning kõikidel neil on erinevad õigused teenuse kasutamisel. Ükski roll ei ole ülearu, kuid näiteks worker ei saa lisada teenuse tüüpe ja teenuseid seega mõndade rollide õigused tunduvad algselt poolikud. Kohe alguses luuakse ka administraator, mille parooli vahetamist peaks kasutajalt sisse logides nõudma, et muudaks. Selle jaoks võib ka teha teavituse ülesse serva, kui on algne parool, siis tuletaks meelde, et muutke ära. Igat kasutajat on ka võimalik deaktiveerida, sellehulgas ka administraatori oma. Administraatori kasutaja on ainuke, kelle oma ei tohiks deaktiveerida, kui ta on ainuke administraator. Ehk teha selle jaoks test, kui on ainult 1 isik administraatori rollidega, siis teda deaktiveerida ei saa.

	Antud programm on hästi tehtud ning kommenteeritud. Kõik liidesed, mida oleks vaja on olemas, kuid puudavad Data Transfer Objekt klassid, mis ei ole küll nõutud, kuid API vastusteks sobiksid palju paremini. UnitOfWork tundub olevat antud projektis üleliigne ja API peale ei ole täielikult läbi mõeldud. API'le ei pääse ligi kuna ei ole tehtud viisi tokenite ~~saamiseks~~. ~~Projektis~~ ei ole ~~võimalik ligi pääseda~~ API~~'le kuna tokeneid ei ole võimalik küsida~~. Kuna API ei ole hetkel kasutatav, siis ei ole antud ~~töö~~ väärt maksimum punkte.		Antud programm on hästi tehtud ning kommenteeritud. Kõik liidesed, mida oleks vaja on olemas, kuid puudavad Data Transfer Objekt klassid, mis ei ole küll nõutud, kuid API vastusteks sobiksid palju paremini. UnitOfWork tundub olevat antud projektis üleliigne ja API peale ei ole täielikult läbi mõeldud. API'le ei pääse ligi kuna ei ole tehtud viisi tokenite küsimiseks ega loomiseks. Kuna veebiteenus ja klientrakendus töötavad ilusti koos, siis see ei ole API absoluutselt vajalik, kuid kui juba tehtud on, siis võiks olla töötav. Kuna API ei ole hetkel kasutatav, siis ei ole antud projekt väärt maksimum punkte.

Caruste: /* Veebiteenuse retsensioon */

2018-06-03T18:51:18Z

Veebiteenuse retsensioon

← Older revision		Revision as of 21:51, 3 June 2018
Line 382:		Line 382:
	Projekti käivitades luuakse andmebaasi kohe kolm erinevat rolli, Admin, worker ja User ning kõikidel neil on erinevad õigused teenuse kasutamisel. Ükski roll ei ole ülearu, kuid näiteks worker ei saa lisada teenuse tüüpe ja teenuseid seega mõndade rollide õigused tunduvad algselt poolikud. Kohe alguses luuakse ka administraator, mille parooli vahetamist peaks kasutajalt sisse logides nõudma, et muudaks. Selle jaoks võib ka teha teavituse ülesse serva, kui on algne parool, siis tuletaks meelde, et muutke ära. Igat kasutajat on ka võimalik deaktiveerida, sellehulgas ka administraatori oma. Administraatori kasutaja on ainuke, kelle oma ei tohiks deaktiveerida, kui ta on ainuke administraator. Ehk teha selle jaoks test, kui on ainult 1 isik administraatori rollidega, siis teda deaktiveerida ei saa.		Projekti käivitades luuakse andmebaasi kohe kolm erinevat rolli, Admin, worker ja User ning kõikidel neil on erinevad õigused teenuse kasutamisel. Ükski roll ei ole ülearu, kuid näiteks worker ei saa lisada teenuse tüüpe ja teenuseid seega mõndade rollide õigused tunduvad algselt poolikud. Kohe alguses luuakse ka administraator, mille parooli vahetamist peaks kasutajalt sisse logides nõudma, et muudaks. Selle jaoks võib ka teha teavituse ülesse serva, kui on algne parool, siis tuletaks meelde, et muutke ära. Igat kasutajat on ka võimalik deaktiveerida, sellehulgas ka administraatori oma. Administraatori kasutaja on ainuke, kelle oma ei tohiks deaktiveerida, kui ta on ainuke administraator. Ehk teha selle jaoks test, kui on ainult 1 isik administraatori rollidega, siis teda deaktiveerida ei saa.

	Antud programm on hästi tehtud ning kommenteeritud. Kõik liidesed, mida oleks vaja on olemas, kuid puudavad Data Transfer Objekt klassid, mis ei ole küll nõutud, kuid API vastusteks sobiksid palju paremini. UnitOfWork tundub olevat antud projektis üleliigne ja API peale ei ole täielikult läbi mõeldud. Projektis ei ~~esine ühtegi suuremat viga ning väärib kõrget punktisummat~~.		Antud programm on hästi tehtud ning kommenteeritud. Kõik liidesed, mida oleks vaja on olemas, kuid puudavad Data Transfer Objekt klassid, mis ei ole küll nõutud, kuid API vastusteks sobiksid palju paremini. UnitOfWork tundub olevat antud projektis üleliigne ja API peale ei ole täielikult läbi mõeldud. API'le ei pääse ligi kuna ei ole tehtud viisi tokenite saamiseks. Projektis ei ole võimalik ligi pääseda API'le kuna tokeneid ei ole võimalik küsida. Kuna API ei ole hetkel kasutatav, siis ei ole antud töö väärt maksimum punkte.

Caruste: /* Veebiteenuse retsensioon */

2018-06-03T18:44:28Z

Veebiteenuse retsensioon

← Older revision		Revision as of 21:44, 3 June 2018
Line 358:		Line 358:

	===Veebiteenuse retsensioon===		===Veebiteenuse retsensioon===
	Meeskonnale: Raavo V2™		Meeskonnale: [https://wiki.itcollege.ee/index.php/Meeskond_Raavo_V2%E2%84%A2 Raavo V2™]

	Antud töö on ilusti kirjutatud ning ei oma suuremaid vigu ning kõik Must Have eesmärgid on edukalt saavutatud. Nice to Have eesmärgid on kahjuks kõik jäänud tegemata. Kogu projekt on ilusti kommenteeritud ning ei oma vigu, mis jäävad koheselt silma. Projekti struktuur on ilusti püsti pandud ning ükski klass ei ole suvalises kaustas. Projekti sees on tehtud eraldi lisaks WebAppile veel viis eraldi väiksemat projekti, kus hoitakse domeene, liideseid ning Entity Frameworkiga seostuvaid klasse.		Antud töö on ilusti kirjutatud ning ei oma suuremaid vigu ning kõik Must Have eesmärgid on edukalt saavutatud. Nice to Have eesmärgid on kahjuks kõik jäänud tegemata. Kogu projekt on ilusti kommenteeritud ning ei oma vigu, mis jäävad koheselt silma. Projekti struktuur on ilusti püsti pandud ning ükski klass ei ole suvalises kaustas. Projekti sees on tehtud eraldi lisaks WebAppile veel viis eraldi väiksemat projekti, kus hoitakse domeene, liideseid ning Entity Frameworkiga seostuvaid klasse.

Caruste: /* Veebiteenuse retsensioon */

2018-06-03T18:42:09Z

Veebiteenuse retsensioon

← Older revision		Revision as of 21:42, 3 June 2018
Line 358:		Line 358:

	===Veebiteenuse retsensioon===		===Veebiteenuse retsensioon===
	~~Meeskond~~: Raavo V2™		Meeskonnale: Raavo V2™

	Antud töö on ilusti kirjutatud ning ei oma suuremaid vigu ning kõik Must Have eesmärgid on edukalt saavutatud. Nice to Have eesmärgid on kahjuks kõik jäänud tegemata. Kogu projekt on ilusti kommenteeritud ning ei oma vigu, mis jäävad koheselt silma. Projekti struktuur on ilusti püsti pandud ning ükski klass ei ole suvalises kaustas. Projekti sees on tehtud eraldi lisaks WebAppile veel viis eraldi väiksemat projekti, kus hoitakse domeene, liideseid ning Entity Frameworkiga seostuvaid klasse.		Antud töö on ilusti kirjutatud ning ei oma suuremaid vigu ning kõik Must Have eesmärgid on edukalt saavutatud. Nice to Have eesmärgid on kahjuks kõik jäänud tegemata. Kogu projekt on ilusti kommenteeritud ning ei oma vigu, mis jäävad koheselt silma. Projekti struktuur on ilusti püsti pandud ning ükski klass ei ole suvalises kaustas. Projekti sees on tehtud eraldi lisaks WebAppile veel viis eraldi väiksemat projekti, kus hoitakse domeene, liideseid ning Entity Frameworkiga seostuvaid klasse.

Caruste: /* Veebiteenuse retsensioon */

2018-06-03T18:41:56Z

Veebiteenuse retsensioon

← Older revision		Revision as of 21:41, 3 June 2018
Line 358:		Line 358:

	===Veebiteenuse retsensioon===		===Veebiteenuse retsensioon===
			Meeskond: Raavo V2™

	Antud töö on ilusti kirjutatud ning ei oma suuremaid vigu ning kõik Must Have eesmärgid on edukalt saavutatud. Nice to Have eesmärgid on kahjuks kõik jäänud tegemata. Kogu projekt on ilusti kommenteeritud ning ei oma vigu, mis jäävad koheselt silma. Projekti struktuur on ilusti püsti pandud ning ükski klass ei ole suvalises kaustas. Projekti sees on tehtud eraldi lisaks WebAppile veel viis eraldi väiksemat projekti, kus hoitakse domeene, liideseid ning Entity Frameworkiga seostuvaid klasse.		Antud töö on ilusti kirjutatud ning ei oma suuremaid vigu ning kõik Must Have eesmärgid on edukalt saavutatud. Nice to Have eesmärgid on kahjuks kõik jäänud tegemata. Kogu projekt on ilusti kommenteeritud ning ei oma vigu, mis jäävad koheselt silma. Projekti struktuur on ilusti püsti pandud ning ükski klass ei ole suvalises kaustas. Projekti sees on tehtud eraldi lisaks WebAppile veel viis eraldi väiksemat projekti, kus hoitakse domeene, liideseid ning Entity Frameworkiga seostuvaid klasse.

Caruste: /* Veebiteenuse retsensioon */

2018-06-03T18:40:39Z

Veebiteenuse retsensioon

← Older revision		Revision as of 21:40, 3 June 2018
Line 361:		Line 361:

	Veebiteenuses on täidetud kõik nõuded peale kasutaja statistika. Seda nõuet saab küll täita mitut moodi ning kasutaja statistikat on ka võimalik võtta broneeringutest seega võib seda tehniliselt lugeda täidetuks.		Veebiteenuses on täidetud kõik nõuded peale kasutaja statistika. Seda nõuet saab küll täita mitut moodi ning kasutaja statistikat on ka võimalik võtta broneeringutest seega võib seda tehniliselt lugeda täidetuks.

	Kõik klassid, millele on mõttekas luua liides, on see ka tehtud. Domeenidel on kõik vajalikud väljad piiratud ning on ära märgitud, mida on vaja ära täita, mis on välisvõti, mis on võti ning väljastatakse ka veateated, kui ületab limiiti.		Kõik klassid, millele on mõttekas luua liides, on see ka tehtud. Domeenidel on kõik vajalikud väljad piiratud ning on ära märgitud, mida on vaja ära täita, mis on välisvõti, mis on võti ning väljastatakse ka veateated, kui ületab limiiti.

Line 366:		Line 367:

	Kontrolleritele ei ole tehtud eraldi teenuseid, seega seda võib-olla hiljem keeruline muuta ja testida. Kõik kontrollerid nõuavad autoriseerimist seega ei tohiks keegi pääseda ligi informatsioonile, millele tal pole õigust. Kahjuks tundub, et autoriseerimine on mingilt maalt jäänud pooleli ning muutmise meetodid pole avatud tavakasutajale. Näiteks kui soovib kasutaja muuta auto informatsiooni, siis ta peab selle hoopis ära kustutama ja uuesti lisama, kuna PUT meetodile on lubatud ligipääs vaid administraatoril. API’de juures oleks võinud kommentaari „summary“ osasse panna täpsema info, et millega antud meetod tegeleb. Hetkel on seal lihtsalt kuidas meetodile ligi pääseda, mis oli automaatselt genereeritud. Igast kontrolleri meetodist ei tule ka tagasi IActionResult, mille tõttu võivad mõned meetodid tagastada vale koodi.		Kontrolleritele ei ole tehtud eraldi teenuseid, seega seda võib-olla hiljem keeruline muuta ja testida. Kõik kontrollerid nõuavad autoriseerimist seega ei tohiks keegi pääseda ligi informatsioonile, millele tal pole õigust. Kahjuks tundub, et autoriseerimine on mingilt maalt jäänud pooleli ning muutmise meetodid pole avatud tavakasutajale. Näiteks kui soovib kasutaja muuta auto informatsiooni, siis ta peab selle hoopis ära kustutama ja uuesti lisama, kuna PUT meetodile on lubatud ligipääs vaid administraatoril. API’de juures oleks võinud kommentaari „summary“ osasse panna täpsema info, et millega antud meetod tegeleb. Hetkel on seal lihtsalt kuidas meetodile ligi pääseda, mis oli automaatselt genereeritud. Igast kontrolleri meetodist ei tule ka tagasi IActionResult, mille tõttu võivad mõned meetodid tagastada vale koodi.

	Antud töös ei ole kasutatud Data Transfer Objecteid (DTO’sid), seega kui kasutada API’t, siis saavad kasutajad palju informatsiooni tagasi, kui nemad peaksid saama. Kuna DTO puudub, siis võib ka läbi API saada ligi konfidentsiaalsele informatsioonile, kui ei ole ettevaatlik.		Antud töös ei ole kasutatud Data Transfer Objecteid (DTO’sid), seega kui kasutada API’t, siis saavad kasutajad palju informatsiooni tagasi, kui nemad peaksid saama. Kuna DTO puudub, siis võib ka läbi API saada ligi konfidentsiaalsele informatsioonile, kui ei ole ettevaatlik.

Line 371:		Line 373:

	Klientrakendus ja API ei ole ka väga kooskõlas. Näiteks saab klientrakenduses vahetada kasutajainformatsiooni ka kasutajana, kuid kui teha seda läbi API, siis peab olema administraator, et muuta kasutaja informatsiooni.		Klientrakendus ja API ei ole ka väga kooskõlas. Näiteks saab klientrakenduses vahetada kasutajainformatsiooni ka kasutajana, kuid kui teha seda läbi API, siis peab olema administraator, et muuta kasutaja informatsiooni.

	BookingArchive ei saa ka töötaja vaadata läbi API, see informatsioon peaks olema neile kindlasti ligipääsetav.		BookingArchive ei saa ka töötaja vaadata läbi API, see informatsioon peaks olema neile kindlasti ligipääsetav.

	Kasutajatele ei ole kuidagi võimalik läbi API lisada kasutajarolle, rolle on küll ennast võimalik lisada, muuta ja kustutada, kuid nende ühendamist kasutajakontodega ei ole veel lisatud (läbi API).		Kasutajatele ei ole kuidagi võimalik läbi API lisada kasutajarolle, rolle on küll ennast võimalik lisada, muuta ja kustutada, kuid nende ühendamist kasutajakontodega ei ole veel lisatud (läbi API).

	Projekti käivitades luuakse andmebaasi kohe kolm erinevat rolli, Admin, worker ja User ning kõikidel neil on erinevad õigused teenuse kasutamisel. Ükski roll ei ole ülearu, kuid näiteks worker ei saa lisada teenuse tüüpe ja teenuseid seega mõndade rollide õigused tunduvad algselt poolikud. Kohe alguses luuakse ka administraator, mille parooli vahetamist peaks kasutajalt sisse logides nõudma, et muudaks. Selle jaoks võib ka teha teavituse ülesse serva, kui on algne parool, siis tuletaks meelde, et muutke ära. Igat kasutajat on ka võimalik deaktiveerida, sellehulgas ka administraatori oma. Administraatori kasutaja on ainuke, kelle oma ei tohiks deaktiveerida, kui ta on ainuke administraator. Ehk teha selle jaoks test, kui on ainult 1 isik administraatori rollidega, siis teda deaktiveerida ei saa.		Projekti käivitades luuakse andmebaasi kohe kolm erinevat rolli, Admin, worker ja User ning kõikidel neil on erinevad õigused teenuse kasutamisel. Ükski roll ei ole ülearu, kuid näiteks worker ei saa lisada teenuse tüüpe ja teenuseid seega mõndade rollide õigused tunduvad algselt poolikud. Kohe alguses luuakse ka administraator, mille parooli vahetamist peaks kasutajalt sisse logides nõudma, et muudaks. Selle jaoks võib ka teha teavituse ülesse serva, kui on algne parool, siis tuletaks meelde, et muutke ära. Igat kasutajat on ka võimalik deaktiveerida, sellehulgas ka administraatori oma. Administraatori kasutaja on ainuke, kelle oma ei tohiks deaktiveerida, kui ta on ainuke administraator. Ehk teha selle jaoks test, kui on ainult 1 isik administraatori rollidega, siis teda deaktiveerida ei saa.

	Antud programm on hästi tehtud ning kommenteeritud. Kõik liidesed, mida oleks vaja on olemas, kuid puudavad Data Transfer Objekt klassid, mis ei ole küll nõutud, kuid API vastusteks sobiksid palju paremini. UnitOfWork tundub olevat antud projektis üleliigne ja API peale ei ole täielikult läbi mõeldud. Projektis ei esine ühtegi suuremat viga ning väärib kõrget punktisummat.		Antud programm on hästi tehtud ning kommenteeritud. Kõik liidesed, mida oleks vaja on olemas, kuid puudavad Data Transfer Objekt klassid, mis ei ole küll nõutud, kuid API vastusteks sobiksid palju paremini. UnitOfWork tundub olevat antud projektis üleliigne ja API peale ei ole täielikult läbi mõeldud. Projektis ei esine ühtegi suuremat viga ning väärib kõrget punktisummat.

Caruste: /* Veebiteenuse retsensioon */

2018-06-03T18:40:02Z

Veebiteenuse retsensioon

Caruste: /* Veebiteenuse retsensioon */

2018-06-03T18:39:25Z

Veebiteenuse retsensioon

← Older revision		Revision as of 21:39, 3 June 2018
Line 358:		Line 358:

	===Veebiteenuse retsensioon===		===Veebiteenuse retsensioon===
			Antud töö on ilusti kirjutatud ning ei oma suuremaid vigu ning kõik Must Have eesmärgid on edukalt saavutatud. Nice to Have eesmärgid on kahjuks kõik jäänud tegemata. Kogu projekt on ilusti kommenteeritud ning ei oma vigu, mis jäävad koheselt silma. Projekti struktuur on ilusti püsti pandud ning ükski klass ei ole suvalises kaustas. Projekti sees on tehtud eraldi lisaks WebAppile veel viis eraldi väiksemat projekti, kus hoitakse domeene, liideseid ning Entity Frameworkiga seostuvaid klasse.
			Veebiteenuses on täidetud kõik nõuded peale kasutaja statistika. Seda nõuet saab küll täita mitut moodi ning kasutaja statistikat on ka võimalik võtta broneeringutest seega võib seda tehniliselt lugeda täidetuks.
			Kõik klassid, millele on mõttekas luua liides, on see ka tehtud. Domeenidel on kõik vajalikud väljad piiratud ning on ära märgitud, mida on vaja ära täita, mis on välisvõti, mis on võti ning väljastatakse ka veateated, kui ületab limiiti.
			Projektile on lisatud UnitOfWork meetod ning startupis on ka olemas vajalikud sisendid, et seda kasutada, kuid mitte kordagi ei ole seda projekti vältel kasutatud. UnitOfWork lisab antud projekti palju üleliigset koodi, ilma milleta saaks edukalt hakkama. UnitOfWorki on lisatud ka kõik domeenid seega mingiaeg on mõeldud selle kasutamise peale.
			Kontrolleritele ei ole tehtud eraldi teenuseid, seega seda võib-olla hiljem keeruline muuta ja testida. Kõik kontrollerid nõuavad autoriseerimist seega ei tohiks keegi pääseda ligi informatsioonile, millele tal pole õigust. Kahjuks tundub, et autoriseerimine on mingilt maalt jäänud pooleli ning muutmise meetodid pole avatud tavakasutajale. Näiteks kui soovib kasutaja muuta auto informatsiooni, siis ta peab selle hoopis ära kustutama ja uuesti lisama, kuna PUT meetodile on lubatud ligipääs vaid administraatoril. API’de juures oleks võinud kommentaari „summary“ osasse panna täpsema info, et millega antud meetod tegeleb. Hetkel on seal lihtsalt kuidas meetodile ligi pääseda, mis oli automaatselt genereeritud. Igast kontrolleri meetodist ei tule ka tagasi IActionResult, mille tõttu võivad mõned meetodid tagastada vale koodi.
			Antud töös ei ole kasutatud Data Transfer Objecteid (DTO’sid), seega kui kasutada API’t, siis saavad kasutajad palju informatsiooni tagasi, kui nemad peaksid saama. Kuna DTO puudub, siis võib ka läbi API saada ligi konfidentsiaalsele informatsioonile, kui ei ole ettevaatlik.
			Kuigi kõik kontrollerid on ilusti ära kommenteeritud ning autorisatsioon on kõikidel meetoditel olemas, siis väga tihti on autoriseeritud roll ainult administraatoril, kuigi peaks olema ka teistel. Samuti on näiteks kasutaja lisamine läbi API lubatud ainult administraatoril ja seda tehakse valesti. Kasutaja informatsioon lisatakse otse andmebaasi läbi ApplicationDbContexti, paroole ei hashita ja informatsiooni üle ei kontrollita. Selle jaoks oleks võinud kasutada userManageri, kus on kõik vajalikud meetodid ja kontrollid juba sisse ehitatud.
			Klientrakendus ja API ei ole ka väga kooskõlas. Näiteks saab klientrakenduses vahetada kasutajainformatsiooni ka kasutajana, kuid kui teha seda läbi API, siis peab olema administraator, et muuta kasutaja informatsiooni.
			BookingArchive ei saa ka töötaja vaadata läbi API, see informatsioon peaks olema neile kindlasti ligipääsetav.
			Kasutajatele ei ole kuidagi võimalik läbi API lisada kasutajarolle, rolle on küll ennast võimalik lisada, muuta ja kustutada, kuid nende ühendamist kasutajakontodega ei ole veel lisatud (läbi API).
			Projekti käivitades luuakse andmebaasi kohe kolm erinevat rolli, Admin, worker ja User ning kõikidel neil on erinevad õigused teenuse kasutamisel. Ükski roll ei ole ülearu, kuid näiteks worker ei saa lisada teenuse tüüpe ja teenuseid seega mõndade rollide õigused tunduvad algselt poolikud. Kohe alguses luuakse ka administraator, mille parooli vahetamist peaks kasutajalt sisse logides nõudma, et muudaks. Selle jaoks võib ka teha teavituse ülesse serva, kui on algne parool, siis tuletaks meelde, et muutke ära. Igat kasutajat on ka võimalik deaktiveerida, sellehulgas ka administraatori oma. Administraatori kasutaja on ainuke, kelle oma ei tohiks deaktiveerida, kui ta on ainuke administraator. Ehk teha selle jaoks test, kui on ainult 1 isik administraatori rollidega, siis teda deaktiveerida ei saa.
			Antud programm on hästi tehtud ning kommenteeritud. Kõik liidesed, mida oleks vaja on olemas, kuid puudavad Data Transfer Objekt klassid, mis ei ole küll nõutud, kuid API vastusteks sobiksid palju paremini. UnitOfWork tundub olevat antud projektis üleliigne ja API peale ei ole täielikult läbi mõeldud. Projektis ei esine ühtegi suuremat viga ning väärib kõrget punktisummat.

← Older revision		Revision as of 21:40, 3 June 2018
Line 359:		Line 359:
	===Veebiteenuse retsensioon===		===Veebiteenuse retsensioon===
	Antud töö on ilusti kirjutatud ning ei oma suuremaid vigu ning kõik Must Have eesmärgid on edukalt saavutatud. Nice to Have eesmärgid on kahjuks kõik jäänud tegemata. Kogu projekt on ilusti kommenteeritud ning ei oma vigu, mis jäävad koheselt silma. Projekti struktuur on ilusti püsti pandud ning ükski klass ei ole suvalises kaustas. Projekti sees on tehtud eraldi lisaks WebAppile veel viis eraldi väiksemat projekti, kus hoitakse domeene, liideseid ning Entity Frameworkiga seostuvaid klasse.		Antud töö on ilusti kirjutatud ning ei oma suuremaid vigu ning kõik Must Have eesmärgid on edukalt saavutatud. Nice to Have eesmärgid on kahjuks kõik jäänud tegemata. Kogu projekt on ilusti kommenteeritud ning ei oma vigu, mis jäävad koheselt silma. Projekti struktuur on ilusti püsti pandud ning ükski klass ei ole suvalises kaustas. Projekti sees on tehtud eraldi lisaks WebAppile veel viis eraldi väiksemat projekti, kus hoitakse domeene, liideseid ning Entity Frameworkiga seostuvaid klasse.

	Veebiteenuses on täidetud kõik nõuded peale kasutaja statistika. Seda nõuet saab küll täita mitut moodi ning kasutaja statistikat on ka võimalik võtta broneeringutest seega võib seda tehniliselt lugeda täidetuks.		Veebiteenuses on täidetud kõik nõuded peale kasutaja statistika. Seda nõuet saab küll täita mitut moodi ning kasutaja statistikat on ka võimalik võtta broneeringutest seega võib seda tehniliselt lugeda täidetuks.
	Kõik klassid, millele on mõttekas luua liides, on see ka tehtud. Domeenidel on kõik vajalikud väljad piiratud ning on ära märgitud, mida on vaja ära täita, mis on välisvõti, mis on võti ning väljastatakse ka veateated, kui ületab limiiti.		Kõik klassid, millele on mõttekas luua liides, on see ka tehtud. Domeenidel on kõik vajalikud väljad piiratud ning on ära märgitud, mida on vaja ära täita, mis on välisvõti, mis on võti ning väljastatakse ka veateated, kui ületab limiiti.

	Projektile on lisatud UnitOfWork meetod ning startupis on ka olemas vajalikud sisendid, et seda kasutada, kuid mitte kordagi ei ole seda projekti vältel kasutatud. UnitOfWork lisab antud projekti palju üleliigset koodi, ilma milleta saaks edukalt hakkama. UnitOfWorki on lisatud ka kõik domeenid seega mingiaeg on mõeldud selle kasutamise peale.		Projektile on lisatud UnitOfWork meetod ning startupis on ka olemas vajalikud sisendid, et seda kasutada, kuid mitte kordagi ei ole seda projekti vältel kasutatud. UnitOfWork lisab antud projekti palju üleliigset koodi, ilma milleta saaks edukalt hakkama. UnitOfWorki on lisatud ka kõik domeenid seega mingiaeg on mõeldud selle kasutamise peale.

	Kontrolleritele ei ole tehtud eraldi teenuseid, seega seda võib-olla hiljem keeruline muuta ja testida. Kõik kontrollerid nõuavad autoriseerimist seega ei tohiks keegi pääseda ligi informatsioonile, millele tal pole õigust. Kahjuks tundub, et autoriseerimine on mingilt maalt jäänud pooleli ning muutmise meetodid pole avatud tavakasutajale. Näiteks kui soovib kasutaja muuta auto informatsiooni, siis ta peab selle hoopis ära kustutama ja uuesti lisama, kuna PUT meetodile on lubatud ligipääs vaid administraatoril. API’de juures oleks võinud kommentaari „summary“ osasse panna täpsema info, et millega antud meetod tegeleb. Hetkel on seal lihtsalt kuidas meetodile ligi pääseda, mis oli automaatselt genereeritud. Igast kontrolleri meetodist ei tule ka tagasi IActionResult, mille tõttu võivad mõned meetodid tagastada vale koodi.		Kontrolleritele ei ole tehtud eraldi teenuseid, seega seda võib-olla hiljem keeruline muuta ja testida. Kõik kontrollerid nõuavad autoriseerimist seega ei tohiks keegi pääseda ligi informatsioonile, millele tal pole õigust. Kahjuks tundub, et autoriseerimine on mingilt maalt jäänud pooleli ning muutmise meetodid pole avatud tavakasutajale. Näiteks kui soovib kasutaja muuta auto informatsiooni, siis ta peab selle hoopis ära kustutama ja uuesti lisama, kuna PUT meetodile on lubatud ligipääs vaid administraatoril. API’de juures oleks võinud kommentaari „summary“ osasse panna täpsema info, et millega antud meetod tegeleb. Hetkel on seal lihtsalt kuidas meetodile ligi pääseda, mis oli automaatselt genereeritud. Igast kontrolleri meetodist ei tule ka tagasi IActionResult, mille tõttu võivad mõned meetodid tagastada vale koodi.
	Antud töös ei ole kasutatud Data Transfer Objecteid (DTO’sid), seega kui kasutada API’t, siis saavad kasutajad palju informatsiooni tagasi, kui nemad peaksid saama. Kuna DTO puudub, siis võib ka läbi API saada ligi konfidentsiaalsele informatsioonile, kui ei ole ettevaatlik.		Antud töös ei ole kasutatud Data Transfer Objecteid (DTO’sid), seega kui kasutada API’t, siis saavad kasutajad palju informatsiooni tagasi, kui nemad peaksid saama. Kuna DTO puudub, siis võib ka läbi API saada ligi konfidentsiaalsele informatsioonile, kui ei ole ettevaatlik.

	Kuigi kõik kontrollerid on ilusti ära kommenteeritud ning autorisatsioon on kõikidel meetoditel olemas, siis väga tihti on autoriseeritud roll ainult administraatoril, kuigi peaks olema ka teistel. Samuti on näiteks kasutaja lisamine läbi API lubatud ainult administraatoril ja seda tehakse valesti. Kasutaja informatsioon lisatakse otse andmebaasi läbi ApplicationDbContexti, paroole ei hashita ja informatsiooni üle ei kontrollita. Selle jaoks oleks võinud kasutada userManageri, kus on kõik vajalikud meetodid ja kontrollid juba sisse ehitatud.		Kuigi kõik kontrollerid on ilusti ära kommenteeritud ning autorisatsioon on kõikidel meetoditel olemas, siis väga tihti on autoriseeritud roll ainult administraatoril, kuigi peaks olema ka teistel. Samuti on näiteks kasutaja lisamine läbi API lubatud ainult administraatoril ja seda tehakse valesti. Kasutaja informatsioon lisatakse otse andmebaasi läbi ApplicationDbContexti, paroole ei hashita ja informatsiooni üle ei kontrollita. Selle jaoks oleks võinud kasutada userManageri, kus on kõik vajalikud meetodid ja kontrollid juba sisse ehitatud.

	Klientrakendus ja API ei ole ka väga kooskõlas. Näiteks saab klientrakenduses vahetada kasutajainformatsiooni ka kasutajana, kuid kui teha seda läbi API, siis peab olema administraator, et muuta kasutaja informatsiooni.		Klientrakendus ja API ei ole ka väga kooskõlas. Näiteks saab klientrakenduses vahetada kasutajainformatsiooni ka kasutajana, kuid kui teha seda läbi API, siis peab olema administraator, et muuta kasutaja informatsiooni.
	BookingArchive ei saa ka töötaja vaadata läbi API, see informatsioon peaks olema neile kindlasti ligipääsetav.		BookingArchive ei saa ka töötaja vaadata läbi API, see informatsioon peaks olema neile kindlasti ligipääsetav.

	Kasutajatele ei ole kuidagi võimalik läbi API lisada kasutajarolle, rolle on küll ennast võimalik lisada, muuta ja kustutada, kuid nende ühendamist kasutajakontodega ei ole veel lisatud (läbi API).		Kasutajatele ei ole kuidagi võimalik läbi API lisada kasutajarolle, rolle on küll ennast võimalik lisada, muuta ja kustutada, kuid nende ühendamist kasutajakontodega ei ole veel lisatud (läbi API).
	Projekti käivitades luuakse andmebaasi kohe kolm erinevat rolli, Admin, worker ja User ning kõikidel neil on erinevad õigused teenuse kasutamisel. Ükski roll ei ole ülearu, kuid näiteks worker ei saa lisada teenuse tüüpe ja teenuseid seega mõndade rollide õigused tunduvad algselt poolikud. Kohe alguses luuakse ka administraator, mille parooli vahetamist peaks kasutajalt sisse logides nõudma, et muudaks. Selle jaoks võib ka teha teavituse ülesse serva, kui on algne parool, siis tuletaks meelde, et muutke ära. Igat kasutajat on ka võimalik deaktiveerida, sellehulgas ka administraatori oma. Administraatori kasutaja on ainuke, kelle oma ei tohiks deaktiveerida, kui ta on ainuke administraator. Ehk teha selle jaoks test, kui on ainult 1 isik administraatori rollidega, siis teda deaktiveerida ei saa.		Projekti käivitades luuakse andmebaasi kohe kolm erinevat rolli, Admin, worker ja User ning kõikidel neil on erinevad õigused teenuse kasutamisel. Ükski roll ei ole ülearu, kuid näiteks worker ei saa lisada teenuse tüüpe ja teenuseid seega mõndade rollide õigused tunduvad algselt poolikud. Kohe alguses luuakse ka administraator, mille parooli vahetamist peaks kasutajalt sisse logides nõudma, et muudaks. Selle jaoks võib ka teha teavituse ülesse serva, kui on algne parool, siis tuletaks meelde, et muutke ära. Igat kasutajat on ka võimalik deaktiveerida, sellehulgas ka administraatori oma. Administraatori kasutaja on ainuke, kelle oma ei tohiks deaktiveerida, kui ta on ainuke administraator. Ehk teha selle jaoks test, kui on ainult 1 isik administraatori rollidega, siis teda deaktiveerida ei saa.

	Antud programm on hästi tehtud ning kommenteeritud. Kõik liidesed, mida oleks vaja on olemas, kuid puudavad Data Transfer Objekt klassid, mis ei ole küll nõutud, kuid API vastusteks sobiksid palju paremini. UnitOfWork tundub olevat antud projektis üleliigne ja API peale ei ole täielikult läbi mõeldud. Projektis ei esine ühtegi suuremat viga ning väärib kõrget punktisummat.		Antud programm on hästi tehtud ning kommenteeritud. Kõik liidesed, mida oleks vaja on olemas, kuid puudavad Data Transfer Objekt klassid, mis ei ole küll nõutud, kuid API vastusteks sobiksid palju paremini. UnitOfWork tundub olevat antud projektis üleliigne ja API peale ei ole täielikult läbi mõeldud. Projektis ei esine ühtegi suuremat viga ning väärib kõrget punktisummat.