Show ToDo.txt syntax highlighted
- Tabela 'session' ne DB duhet zbrazur ne menyre periodike,
p.sh. me nje cron job ne oren 24:00 te cdo nate.
Moduli Superuser:
-----------------
- Te faqja e superuserit, shto edhe mundesine per te bere backup
dhe restore, per te krijuar nje databaze te re nga e para
(e cila eshte e dobishme ne castin kur instalohet aplikacioni), etj
Rregullo keto gabime (bugs):
----------------------------
Permiresimet ne framework per optimizimin e aplikacionit
---------------------------------------------------------
Kerkesa te Reja:
----------------
- Nxirre raportin NeedToSell edhe per te gjitha zyrat.
(Duhet diskutuar me Antonin se si do jete kjo, sepse nuk
eshte shume e qarte).
- Departamentet kane nga 1 dept_id qe eshte e ndryshme per cdo
departament, dhe nje off_id qe e lidh nje departament me nje
zyre te caktuar.
Eshte mire qe te shtohet edhe nje depttype_id (ose dicka e
ngjashme) qe te lidh nje departament me nje tip te caktuar.
Tipet jane: Audit, FAS, T&L, etc. Kjo duhet sepse ne disa
raste kerkohet qe te nxirren raporte totale nga disa departamente
te te njejtit lloj, ne zyra te ndryshme.
- Mund te behet ruajtja e sessionit per cdo user. Kjo do te thote
qe kur useri te hyje ne aplikacion, te vendoset ne po ate gjendje
qe ishte kur beri [logout] heren e fundit. Kjo mund te jete e
dobishme per ti thjeshtuar userit pune. Ose mund te vihet si nje
preference (te user preferencat, qe mund te shtohen te user profile)
qe useri mund ta zgjedhe sipas deshires.
- Te UserProfile userit mund ti dalin edhe oraret e tij
te punes (schedule), pra ne cilat projekte ka per te
punuar dhe sa ore cdo jave.
- Te UserProfile (qe mund te quhet thjesht User ose me nje
emer tjeter) mund te shtohet edhe mundesia qe nje user ti
dergoje nje shenim (mesazh) dikujt tjeter, ose disa userave
te tjere, si tip e-mail, per komunikim te brendshem. Userit
qe i ka ardhur nje mesazh, i del nje ikone ose nje njoftim
ne nje cep te ekranit. Mund te shtohet edhe nje bulletin
board, per njoftime te pergjithshme, nje chat per te
diskutuar me nje ose disa usera te tjere (si Yahoo Messanger),
etj.
- Aplikacioni mund te mbaje te dhena se kur hyn dhe kur del nje
user (pra sa kohe ka punuar), cfare ka bere gjate kohes se
punes, etj. Ne baze te ketyre te dhenave superuseri mund te
nxjerre statistika, raporte, etj.
Te Pergjithshme:
----------------
- Shqyrto aspekte te sigurise se aplikimit.
- Bej permiresime dhe optimizime ne database.
- Permireso dizajnin grafik, me XHTML te paster dhe CSS,
me imazhe grafike dhe me butona.
Kete duhet ta bej nje grafist.
+ Nderkohe mund te shtohet ne framework edhe mundesia per
per te ndare automatikisht dizajnin e permiresuar neper
templeta.)
- Ndryshoje terminologjine e perdorur ne aplikacion (emrat e
variablave, funksioneve, tabelave etj.) ne menyre qe te mos bej
fjale per projekte, contracted, proposal, etj., por per
dokumente dhe lloje dokumentesh. Ne kete menyre aplikacioni
pergjithesohet (gjeneralizohet) dhe mund te pershtatet me lehte
per situata te tjera, te ngjashme me kete.
- Dokumentat qe ruan aplikacioni (te dhenat e projekteve) jane
pak a shume te strukturuara (ne forme peme). E njejta gje mund
te thuhet edhe per lloje te tjera dokumentash. Meqe jane te
strukturuara, ndoshta do ishte me e pershtatshme dhe me e
natyrshme qe te ruheshin ne XML, sesa te ruhen ne Relational DB
(DB me tabela).
Te shqyrtohet mundesia per ti ruajtur dokumentet e aplikacionit
ne XML files, ose ne XML DB (XML Repository), ose ne
Object-Oriented DB.
Nje Object-Oriented DB qe eshte edhe Free Software (Open Source)
eshte Ozone. Ajo nuk ka PHP API, por ka Java API, dhe Java API
mund te perdoret edhe qe nga PHP-ja. Ka patur edhe nje perpjekje
per te ndertuar nje XML Repository te bazuar mbi Ozone, por nuk
e di deri ku ka shkuar.
=====================================================================
Kur behet nje selektim sipas timeframe-it, shfaqen te
gjithe projektet qe jane aktive ne ate periudhe kohore.
Nje projekt eshte aktiv qe nga data e rregjistrimit (register_date)
dhe deri ne daten e mbylljes (close_date).
Kur nje projekt mbylled, vetem shenohet data e mbylljes, dhe nuk
fshihet nga databazja.
Kur ndryshon statusi krijohet nje record te ri dhe nuk fshihet
dokumenti korent. Useri nuk ka mundesi ta ndryshoje statusin
e dokumentit ne menyre te parregullt (p.sh. nga Contracted ne Opportunity,
etj.).
Keshtu, mund te kemi me shume se nje dokument qe kane te njejten
proj_id, por kane status_id te ndryshem.
Kur regjistrohet nje projekt, lista e departamenteve ku mund te
regjistrohet perbehet nga departamentet e zyres te ciles i perket
regjistruesi, dhe default i listes eshte departamenti i regjistruesit.
Lista e stafit perbehet nga userat qe i perkasin zyres se regjistruesit.
Lista e manaxherave perbehet nga te gjithe manaxherat e zyres se
regjistruesit, kurse lista e partnerve perbehet nga te gjithe partneret.
Kur hyn nje user qe nuk ka te drejte ne asnje departament,
hapet faqja user data.
Raporti "Need To Sell" ka nje TimeFrame Box te ndryshem nga
te tjeret, nuk ka SelectByStatus, dhe SelectByDepartment
lejon zgjedhjen e vetem 1 departamenti.
Raporti SummaryReport nuk ka SelectByStatus.
Te dhenat NSR dhe budget NSR qe fut finacieri, futen per cdo departament.
Nje dokument qe eshte i mbyllur nuk lejon editim.
Lista e departamenteve ku nje dokument mund te regjistrohet
ka departamentet ku useri ka mundesi editimi.
Kur nje dokument ndryshon statusin transferohen te gjitha te
dhenat e tij ne dokumentin e ri qe krijohet (Work Distribution,
Portion of Work, Managers, Partners, etj).
Te modify/list_of_projects eshte edhe nje buton [remove] ([X],
i cili e fshin nje dokument komplet nga databazja.
Dokumenti mund te fshihet vetem nga nje user qe ka te drejte
administratori ne departamentin ku eshte regjistruar projekti.
Adminstratori nuk mund te ndryshoje te drejtat admin per veten e vet.
See more files for this project here