Sziasztok!
Ezen az oldalon: https://www.ttk.hu/telefonkonyv#
láttam egy klassz telefonkönyvet, amihez hasonlót keresek már egy ideje.
Amit tudnia kellene, azt tulajdonképpen a fenti linken látható telefonkönyv mind tudja:
-- Böngészőben fut
-- Magyar a kezelőfelület
-- A név mező nincs szétbontva (családnév, keresztnév)
-- Több telefonszám is tárolható egy kapcsolathoz
-- A telefonszámok formai megjelenítése a magyar telefonszámoknak megfelelően történik
-- Egyszerű, semmi sallang
-- A keresője nagyon részletes
-- Amit ebben nem látok, de kellene, az az e-mail címek rögzítésének lehetősége
-- Amit ebben nem látok, de feltételezem, hogy tudja: több felhasználó az adatok kezeléséhez (van aki írhatja, van aki csak olvashatja)
-- Amit ebben nem látok, de feltételezem, hogy tudja: az adatok mysql-ben tárolódnak
Tudnátok ajánlani ilyen -- esetleg szabadon felhasználható -- telefonkönyv alkalmazást?
Jelenleg egy addressbook 1.0 nevűt telefonkönyvet találtam, ami a fent nevezett oldalhoz hasonlóan egyszerű de nagyszerű, viszont a telefonszámok formázása nagyon nem tetszik, meg van egy pár olyan funkciója amire nem igazán van szükség (pl.: születésnapok tárolása)... ...de mindegy is, összességében a fent linkelt oldal telefonkönyve nagyon-nagyon szimpatikus.
Előre is köszönöm az ötleteket, javaslatokat!
Hozzászólások
Írj magadnak vagy írass egy programozóval egyet PHP + MySQL alapon, olyan funkciókkal, ami neked pont kell !!
Igen, köszönöm! Erre a lehetőségre pont nem gondoltam!
Három adattábla kell :
alapadatok:
alapadatokID, nev, beosztás, intézet, e-mail, ......
telefonszamok:
telefonszamokID, alapadatokID, telefonszam
jogok:
usernev, jelszo, jog
Ezzel alapszinten a fenti ígény kielégíthető .
kerdezd meg toluk, mit hasznalnak
header alapjan
WordPress 5.9.3gondolom valami plugin hozza... ha jol latom a forrasbol a wpdatatables-t hasznaljak erre
ha tippelnem kene azt mondanam a webfejleszto - szokas szerint - megkapta egy excelben a telefonkonyvet hogy rakja ki. kirakta.
Ágyúval verébre esete ... WP egy telefon-cím lista miatt ?
gondolom az egesz website abban van, nem csak a tel.konyv
A topik író arről nem nyilatkozott, hogy az ő oldala miben lesz megírva. MySQL -t említett csak, mint feltételt.
Hamarabb állnék neki WP-ben megcsinálni, mint hogy egy házibarkács usernev, jelszo, jog rendszer után írjam naponta a security breach jegyzőkönyveket. :)
Tetszőleges php framework-el megíratod, embert találsz hozzá bármikor. Ha a "security breach jegyzőkönyv"-ben a wp plugin-ra mutogathatsz az miben jobb?
Árban kb. mit saccolsz, mennyiért csinálja ezt meg neked egy bármikor talált ember? Konkrétan is érdekelne, mert benne lógok egy projektben, ahol hónapok óta nem találnak értelmes PHP-s embert.
Ezeket javítják gyorsan és automatikusan frissül a plugin. Ha rábízod egy bármikor talált emberre, akkor ez nem történik meg.
https://iotguru.cloud
Attól függ mennyi idő van rá; A legolcsóbb ha valami kis csapat bevállalja két nagyobb meló közé. Értelemszerűen ennek az ütemezése nem hetekben mérhető..
Persze amúgy költség oldalról az a legolcsóbb ami nyílt és azonnal elérhető.
Már ha a karbantartó valóban rendszeresen frissíti (ez a wp plugin repository nagyon kis százaléka). Volt pár bővítmény és több fordítás amit évekig karbantartottam, tudom mit jelent ez :).
Oké, a bullshit után: árban kb. mit saccolsz, mennyiért csinálja ezt meg neked egy bármikor talált ember?
Azért ne tegyünk úgy, mintha egy telefonkönyv plugint hárman használnának összesen. Meg lehet nézni, hogy mekkora a bázis és milyen gyakran frissítik.
https://iotguru.cloud
Nem lesz ilyen. Kizárt. Erre nulla, vagy elhanyagolhatóan kevés büdzsé lesz, és így is, úgy is lesz valamennyi maintenance meló, amit az összeszokott csapat a rendes projektjei között a háta közepére sem kívánna, az ügyfélnek meg pénze nem lesz rá.
A fentebbi security-s megjegyzés félreérthető volt talán, ne csak IT-s szemmel nézd. Ha mondjuk kijön a NAIH, és te csináltad a fostengert, abból könnyen bírság lehet, ha más csinálta a fostengert, de te az elvárható szinten elővigyázatos voltál (frissen tartott plugin, stb., akor is, ha a vendor egy idióta), akkor nagyobb eséllyel lesz csak ejnyebejnye a sztori vége.
A fentebb bemutatott 3 táblás megoldás a plaintext jelszóval pl. garantált seggbekúrás, de ha szeret valaki veszélyesen élni, hajrá. :)
Az uccsó NAIH hoz kérdés, mert ugye nem tudjuk mit akar az OP, külső telefonkönyvet, vagy belsőt.. mert belsőre kb. bármi jó lehet nem? Azért nem izélgethet meg a NAIH -> HRtől ekérve az adat -> helyben tárolva, saját fejlesztés, soha senki nem látja, stb...
Ofc, de ebben az esetben megint nem nulláról építenék auth réteget, hanem a meglévőből dolgoznék.
Mondjuk mint kiderült, nincs meglévő. Így nehezebb. :)
Írtam én olyat, hogy a jelszót az adatbázisban plaintext-ként kell kezelni ??
Természetesen kódolva kell. MD5 , vagy bármi.
Ez alap.
Előbb gondolkodj vagy kérdezz, utána kritizáld más ötletét !
Még mindig fenntartom, hogy CSAK telefon-címjegyzék célra kár WP-t használni. A topik nyitó persze tisztázhatná végre, hogy mibe kell ezt egyáltalán beilleszteni. Vagy csak egy PHP oldalt vár, ami MySQL háttérrel rendelkezik és teljesíti a leírt feltételeket.
Szerintem az md5 felemlegetésével inkább megerősítetted gelei commentjét semmint cáfoltad volna.
MD5 vagy bármi más titkosítás amit az SQL támogat.
Szóval hiába boldozol, olyan esett ki a szádból, aminek nem illett volna, ha erről a témáról beszélsz.
Én egyébként végignéztem már párszor (sajnos néha csinált(att)am is), hogy valaki nullárol implementál ilyesmit. Invariably fuckup van valamiben, szerencsés esetben csak abban, hogy tovább tart, és még a következő két iterációban is lesz vele munka. Az igazság az, hogy egy normálisan működő authentikációs réteg minimális funkciókkal is több munka, mint egy kereshető telefonkönyv.
És bár a topicnyitó nem nagyon tűnik úgy, hogy látná, de egyébként ez erősen GDPR hatályos mókának tűnik.
Nekem erről az egész diszkusszióról a Dunning-Kruger jut eszembe. Meg az, hogy amit itt látunk az a szakma jelenlegi állapota. Kicsit filozofikusabbra véve a dolgot érdemes elgondolkoznunk azon (egyénileg, jellemzően) hogy mit kezdünk ezzel a helyzettel. A szituáció abszolút nem csak hazai jelenség, mindenhol tapasztalom amerre csak "járok".
Gábriel Ákos
Mert ha excel táblában tárolunk telefonszámot az nem az? Vagy ne tároljunk telefonszámokat, e-mail címeket saját használatra?
amikor aláírod a munka szerződésed, abban kell lennie egy olyan pontnak, hogy:
- hozzájárulás, hogy személyes adatodat kezelhetik - a cég adatkezelési szabályzata szerint, amely megtekinthető: xy helyen
- biometrikus jellemző rögzítése és kezelése: pl. ujj nyomatra nyitó ajtók miatt
- képmás rögzítéséhez hozzájárulás: térfigyelő és biztonsági kamerák miatt
- hangrögzítése: irodai vezetékes telefon rögzítése setén
stb..
vagyis ezek a GDPR-es dolgok NEM most kell hogy előtérbe kerüljenek..
Bár az exceles nyilvántartás nem tudom, hogy szerepelvan az adatkezelési szabályzatban..
For Whites Only meeting room!
Külső kapcsolatok egyébként is nyilvános, számainak és mail elérhetőségeinek tárolásáról lenne szó. Ez egy pár fős kis nonprofit cég, munkatársak számait nem kell itt tárolni sehogy, mindenki tudja fejből a másikét. :-)
A külső kapcsolatok még problémásabbak. Hiába nyilvános a telefonszám és az email cím, az személyes adatnak minősül, és az adatkezelésnek megvannak a maga szabályai.
"mindenki tudja fejből a másikét"
2022-ben senki nem hív szám szerint senkit, valahol van egyébként ilyen táblázat, csak legfeljebb te nem tudsz róla. Plusz, mindenki elment mindenkit a telefonjának a telefonkönyvében, már csak azért is, hogy felismerje, ha XY hívja.
Blog | @hron84
via @snq-
Azt teljesen mindegy. Ha egy év múlva egy egész más ügy miatt egy sértődött munkatárssal megszűnik a jogviszony, akár szép kis csekkecske is lehet belőle a naihtól, ha úgy gondolja, hogy felhívja erre a hivatal figyelmét.
Ezeket le kell szabályozni, illetve alá kell a kollégákkal íratni. Onnantól nincs gond. Nyilván megfelelően alátámasztva az adatok kezelésének okát az adatvédelmi szabályzatban vagy annak valamilyen mellékleteként.
üdv: pomm
A 852-es kídlap telepötúsa sikeresen befejezádétt
A céges telefonok, számok a cég tulajdonát képezik, szerintem. Ha valaki ezzel visszaél , az követ el bűncselekményt.
Szóval nem érdemes feljelentgetni amiatt egy céget, hogy a telefonlista egy weboldalon szerepel.
Szerintem ...
1, Egy szó sem volt arról, hogy cégesek az adatok
2, A vezetéknév.keresztnév@ceg.hu e-mail cím is lehet necces...
üdv: pomm
A 852-es kídlap telepötúsa sikeresen befejezádétt
1: akkor ezt hogy értelmezed ? >> https://hup.hu/comment/2824313#comment-2824313
2: biztos, bár nem értem, ez most hogya jön ide ??
Véletlenül beleolvastam a topikba, ha már idekerült a sor, akkor egy kis korrekció a GDPR kapcsán. Munkavállalóval az egyenlőtlen erőviszonyok miatt nem iratunk alá hozzájárulást, érvénytelen lesz a dolog. Ajánlom ennek a gyakorlatnak elkerülését.
Biometrikus adatkezelés meg csak akkor lehet, ha a munka törvénykönyvében megjelölt esetben használják, egyéb esetekben idehaza tilos.
akkor nem azt íratom alá, hogy hozzájárul, hanem tudomására hoztam - vagyis tud róla és ha nem ért vele egyet, akkor x napon belül írásban jelezze és akkor nem lesz a nyilvántartásban (de a fizetési listában sem - ezt majd észre veszi).
Akkor egy munka szerződés minden pontja pl. fizetés - egyenlőtlen erőviszony miatt semmis ???
Minden szinten a lift után az ajtó ujj nyomattal működik - akkor mi van ??
For Whites Only meeting room!
Az adatkezeléshez nem kell hozzájárulást gyűjteni, a hozzájárulás kivétel és nem főszabály. Az adatkezelésednek jogalapja kell hogy legyen, ezek közül csak az egyik a hozzájárulás.
A foglalkoztatott emberek esetén a jogalap részben a szerződés teljesítése lesz (foglalkoztatáshoz kapcsolódó adatok), a maradék pedig a vállalkozás ilyen-olyan jogos érdeke. A munkavállalót egyszerűen tájékoztatod az adatkezelésről, hozzájárulást nem gyűjtesz és akkor elkerülőd hogy rossz jogalappal kezeled az adatokat.
Az egyenlőtlen erőviszony nem a szerződést semlegesíti, hanem a hozzájárulást. A hozzájárulás GDPR fogalma szerint önkéntes, márpedig egy munkáját féltő jómunkásember esetén amikor orra tolnak egy papírt, hogy add a hozzájárulásod, akkor az önkéntesség elve sérül.
Az hogy ti ujjlenyomatot használtok, a ti dolgotok. A munka törvénykönyvét lehet lapozgatni, le van írva, hogy ezt kizárólag milyen esetben lehet és pont. Ha nem akartok törvénysértőek lenni, akkor belépőkártyára vagy más nem biometrikus dologra cserélitek. Vagy együttéltek azzal, hogy esetleg egy kirúgott dolgozó felnyomja a céget...
Az Mtk szerint lehet használni biometrikus azonosítást különösen nagy érték védelmére, ami 50 millió forintot jelent és ezt a legtöbb cég meg tudja indokolni...
https://iotguru.cloud
Ez így van, van ahol megindokolható, valahol nem ... de a cég jobban teszi ha átforgatja az MTét meg a többit, mert ahogy fentebb olvasható volt, ők úgy gondolták, hogy hozzájárulást kérnek és aztán jólvan.
De, az. Csak egy fokkal könnyebb
De, nyugodtan, csak mikor ezek tulajdonképp mások személyes adatai, és rendszerben tároljuk őket, akkor legyünk vele tisztában, hogy ennek vannak szabályai. Márpedig tudjuk, hogy itt ez van:
És nem, az, hogy valami nyilvános helyről szedted, az nem jelenti azt, hogy te ezt csak úgy kezelheted, meg akkor le van szarva nálad a biztonsága.
Belső használatra akarja csak a telefon-cím jegyzéket, ahogy olvastam.
Az MD5-tel kapcsolatban igazad van.
De ez csak egy példa volt reflexből, bár beismerem rossz példa.
De, ahogy írtam, lehet más titkosítás a jelszóra, akár saját elvű is, amit csak a fejlesztő kitalál.
Ezért volt a boldozás ..
> akár saját elvű is, amit csak a fejlesztő kitalál.
Vadász-vadász, ...
És mennyiért találsz olyan PHP fejlesztőt, akinek minimum egy kisdoktorija van kriptográfiából?
https://security.stackexchange.com/questions/106186/writing-my-own-encr…
Nem kell hozzá kisdoktori. A saját elveimet követem csupán. Nem állítom, hogy visszafejthetetlen , de melyik az ?? Alap, hogy maga a jelszó ne legyen túl egyszerű. Én már csak egy matek alapú titkosítást végzek, és így tárolom el.
Hiszen a legtöbb titkosítás így működik ...
És a legtöbb regény úgy íródík, hogy gombokat nyomogatnak egy billentyűzeten. Aztán valahogy mégis vannak szignifikáns minőségi különbségek közöttük.
Nem a NASA-ról van szó ...
Ez egy kis cég , ahol a webes telefonlistát kell karbantartani.
Ehhez kell egy "írási-szerkesztési" jog, amit felhasználónévvel és jelszóval kellene védeni.
Gondoljuk már végig !!
Végiggondoltuk, és ezért ajánlottuk többen is, hogy nem nulláról kellene megírni és üzemeltetni, hanem valami meglévő megoldást kellene felhasználni.
Igen... Ez mindíg így indul, és akkor már jólenne tudná ezt, ha már úgyis csináljuk akkor azt. Ennek valahol üzemelnie kell, lehetőleg nem a sarokba hányva egy 10 éves homePC-n, meg csupa ilyesmi vonzata van. Ha kis cég, akkor valamilyen normálisan elérhető online megoldás a javasolt, és nem a házibarkács, különös tekintettel arra, hogy itt még a "karitatív jelleg" is felmerült. Most valaki összekalapálja, és akkor azzal 1-2-3 év múlva mi lesz?
Még mindig csak egy telefon listáról van szó ?? Vagy már komplett weboldalban, dokumentum-kezelésben kell gondolkodni ?
Csak lista, de próbálunk nagyon alap dolgokra figyelmeztetni.
A szerverről és tárolásáról már írtam, az autentikációt elég az ENSZ biztonsági tanácsával jóváhagyatni (esetleg a NATO rendkivüli értekezletein felvetni a témát),
sajnos kell 2 új munkatárs, adatvédelmi felelősök , a GDPR miatt. Ezek alap dolgok.
Aztán jöhet egy excel tábla/mysql import.
És még egy jó tanács, mivel kérdezőnek Péter a neve, semmiképpen ne PHP-ban legyen a program - azt csak phpPistikék csinálják-, a Péter név ugyanis már csak egy lépésre van a Pistitől.
https://blog.claryel.hu
Ez elég diszrkiminatív, sőt sértő. Ennyit a HUP liberális felfogásáról.
A Hup liberális lenne? :P Max annyiban, hogy le lehet hülyézni a másikat, ha az hülye, de már annyira nem az, hogy PC legyen. Szerencsére.
Nézz utána a liberális szó ételmének !!
https://wikiszotar.hu/ertelmezo-szotar/Liber%C3%A1lis
Én az elfogadásra, engedékenységre utaltam.
Azt kifogásoltam, hogy bántani, a nevével viccelődni és emiatt egészen más kontextust belekeverni nem éppen értelmes dolog.
Mi köze a PHP-nak a kérdező nevéhez ???
(Nem kell válaszolni)
Ma a liberális szó szerintem inkább szitokszó, még ha a Francia forradalom (1789) környéken ez a szó mást is jelentett, amit a szótárunk megőrzött.
Ha te neki állnál új jelszó titkosítást kitalálni, milyen szempontokat vennél figyelembe a tervezésnél, és hogyan látnád be, hogy azoknak megfelel?
Na ez a titkos..
Ez így hívják:
https://en.wikipedia.org/wiki/Security_through_obscurity
Ha te állítod, biztos ...
Akkor szar ;-)
Szar, mi ?? Amit nem ismersz az szar ... Nyilván.
Igen, nyilván. Az a security algoritmus amit nem mersz közzétenni, mert akkor már nem biztonságos, az szar. Ráadásul nem a konkrét izédről kerdeztem, hanem arról, hogy legalább kb tudod-e mire kell figyelni?
Igen, tudom.
Ne haragudj, de abból, amit itt előadtál, nem ez látszik.
De próbáljuk meg a másik oldalról? Milyen előnyei vannak egy saját titkosításnak ebben az esetben azzal szemben, hogy használsz vmi bejáratott industry standard algoritmust?
"De, ahogy írtam, lehet más titkosítás a jelszóra, akár saját elvű is, amit csak a fejlesztő kitalál."
Ismereteim szerint jelszót, soha de soha nem titkosítunk, hanem hash-elünk. Ennek oka, hogy nem cél a visszafejthetőség.
Egyszerűsítve egy nagyobb halmazból (jelszavak) készítünk egy kisebb halmazt (hash-ek)
Ebből belátható, hogy egy megszámlálhatóan végtelen elemet tartalmazó halmazból, ha leképezzük egy elemet egy véges halmazba, akkor a leképzett halmaz minden elemére megszámlálhatóan végtelen jelszó jut. Emiatt nem visszafejthető. Max találhatunk "pár" helyes megoldást a végtelen halmazból.
https://hu.wikipedia.org/wiki/Sz%C3%BCrjekci%C3%B3
A előzőekben többször írtam az MD5-hahst. Többen ezt kifogásolták.
El kéne már dönteni, hogy mi a jó !! Ha van sapka a fejemen, vagy ha nincs ??
Ez már kezd olyanná válni, mint a magyar ellenzék. Semmi sem felel meg nekik.
Jó a hash, csak nem árt sózni előtte a jelszavat, meg nem pont MD5-öt kell használni, hanem valami jobbat.
“Any book worth banning is a book worth reading.”
mit javasolsz MD5 helyett ??
Minél hosszabb amit ad, annál jobb.
Pl.: Sha256,sha512,sha1024
értem...
SHA-1024 nincs.
SHA-1 viszont van, és tekintve a témát, hátha valaki idetéved: azt se használjuk jelszóra, mert lehet benne collisiont találni
Illetve a nontrivi info, hogy az SHA-512 64 bites architectúrákon gyorsabb, mint az SHA-256 (cserébe hosszabb, szóval több hely kell neki)
És ha jönnek a 128 bitesek, elkezdhetjük használni a SHA-1024-et :)
“Any book worth banning is a book worth reading.”
Igaz. Köszi.
nyugodtan használd az md5-t arra amire manapság való: pl checksumnak :).
Hash = jó
Hash + salt = még jobb
MD5 = rossz
> Ha van sapka a fejemen, vagy ha nincs ??
Leginkább az számít, ami benne van, nem rajta.
igazából már a php-t is te álmodtad hozzá :)
Szerinted a WP miben van megírva ??
PHP + SQL
A topik író sem akar WP -t telepítgetni. (https://hup.hu/comment/2823478#comment-2823478)
Neki egy egyszerű megoldás kell. Amit javasoltam a felé hajlik ő is. Szóval erről ennyit !
Lehet megsértődni, csak felesleges. Tudom miben van megírva a wp, de csak annyit akartam mondani, hogy se a wp, se a php nem szerepelt a feltételek között, kizárólag a mysql, az is jó ég tudja miért (mondjuk meglehetőst biztos vagyok benne, hogy egy szokásos "6 why" legkésőbb második körében ki is derülne, hogy nem requirement)
Megmondm neked, miért szerepel a MySQL: azért, mert már van más okból (pl számlázó rendszer, foobar nyilvántartó rendszer) egy MySQL szerverük, és valószínűleg minimális pénzt tudnak/akarnak költeni üzemeltetésre, így nem akarnak két adatbázis szervert üzemeltetni, hanem egy meglevőt akarnak újrahasznosítani. Szóval egy ilyen pici cégnél valószínűleg ez requirement lesz, vagy meg kell győznöd, hogy a te adatbázis megoldásod nem fog plusz üzemeltetési szopás lenni a nap végén.
Blog | @hron84
via @snq-
Igen. Ez a helyzet.
Én is így olvastam ki a topik nyitó feltételeiből.
Ismereteim szerint az MySQL-kezelést általában PHP felülettel szokták megoldani weben. De lehet Java , vagy akár mi is.
Igazad van, nyilván nem láttam a fától az erdőt.
Ráutaló magatartásnak tűnt, amikor úgy választottad meg a tervezett oszlopokat, hogy semmi hash/salt jellegű utalás nem volt benne. :)
A sokadik pistikeCMS-t látom, ahol a hashelt jelszó oszlopát "password" -nek hívják. Ez már majdnem industry standard. XD
Blog | @hron84
via @snq-
Így van. ÉS ??
Nem tudom mire gondol, de kifejezőbb lenne, egy password_hash név.
+ még egy salt elférne a táblában, és már egész értékelhető
Jelszavakat soha nem tárolok plaintexben, ennek semmi értelme , haszna nem lenne. Gondolj bele !
Tudjuk, meg MD5-t sem használsz, meg semmi DIY, obfuszkált csodát sem, ezek csak valahogy véletlen kerülnek bele a hozzászólásaidba amikor a macska átszalad a billentyűzeten.
Sima szöveget írtam, nem MD5-öt.
Azt használ (MD5-hash) a HR programunk is amit kemény pénzért árulnak a szoftver piacon, nem én írtam.
A saját fejlesztésű megoldásaimban saját matematikai titkosítási elvet használok.
Te mit használsz SQL-ben jelszavak titkosítására, ha már ilyen okos vagy ??
Ó, én egyáltalán nem vagyok okos. Kriptográfiából épp csak egy kegyelem négyesem lett és a szigorlatom sem volt sokkal fényesebb. De azt legalább megtanultam, hogy mennyire vigyázni kell a témában és inkább a szakértőkre kell bízni a naív hozzáállás helyett.
De ha már így rákérdeztél én ezt az implementácót használtam ilyen feladatra.
https://commons.apache.org/proper/commons-codec/apidocs/org/apache/comm…
Szuper ...
Én meg a karakterek ascii-kódját kavarom meg matemetikai műveletekkel és azt tárolom el fordított sorrendben.
Nem egy nagy varázslat , tudom ..
:D
https://iotguru.cloud
.... de működik ..
:D
https://iotguru.cloud
A ROT13 is működik, kb pont ennyire.
van baj...
"jelszo" >> Ez adatbázis-tábla mezőnév, oszlop-név, nem a tartalom milyenségére utal.
És ez egy hiba. Lásd CleanCode.
https://www.sqlstyle.guide/
Hoooogyne, a világ pénzéért nem találunk értelmes fejlesztőket, gondolom milyen sokan fognak ide is jelentkezni. Hacsak nem... :)
Kevesebb a stressz. :)
Semmilyen keretrendszerről nem volt szó a topikban.
Neki egy telefon-címjegyzék kell, mi a fenti feltételeknek megfelel.
A saját fejlesztésként kb. 2 nap alatt megvan.
Aztán ez a PHP oldal bármely keretbe behúzható...
Ha CSAK ez kell neki, kár egy WP-t instalálgatnia , szerintem.
Ez a piacon jelenleg 150-250 ezer forint.
Ez meg közel ingyen van.
https://iotguru.cloud
1. Én elvállalnám olcsóbban is.
2. Ja ingyen van, csak ha valkaki nem ért hozzá, vagy nincs ideje ezzel bajlódni akkor már nem biztos, hogy jó megoldás.
Meg CSAK egy telefonkönyv miatt, felesleges munka, meg sallang bármely CRM telepítése.
Ja, azt látjuk...
Ehelyett nyilván sokkal jobb, ha megírja saját maga, mert van 5-10 év PHP fejlesztésből származó tapasztalata és képes olyan webes rendszert felépíteni, ami korszerű, biztonságos és könnyen frissíthető, csak valamiért a Wordpress telepítés komplex neki annyira, hogy nem látja át.
https://iotguru.cloud
És akkor még arról nem is szóltunk, hogy valószínüleg a webszerver is csak úgy ott lesz valahol az iroda sarkában. Kár belekezdeni az egészbe, mert a szervernek törhetelen üvegajtó mögött a helye, 8 oránként váltott géppisztolyos őrökkel. Ez alap ma már. Páncélszekrénnyel, benne a GDPR kinyomtatott példányaival.
https://blog.claryel.hu
1. Úgy látom csak kekeckedni tudsz .. Eddig senki nem ajánlotta fel. Én igen. Mi a godod ezzel ??
2. Ha nem ért sem a PHP-hoz, sem a Wordpress-hez akkor bízza olyanra aki ért hozzá ! De erre a feladatra overkill a WP, szerintem.
De majd eldönti...
Olvasni tudok. Amit eddig összehordtál, abból látszik, hogy te vagy a piac egyik legolcsóbb embere. Okkal.
Aki ért hozzá, az drága. Aki úgy gondolja, hogy ért hozzá, az nyilván olcsóbb, de később lesz drága.
Nem, erre a feladatra teljesen megfelelő egy WP + plugin.
https://iotguru.cloud
2.: aka mátrametál :D
pch
SB-soft online ügyviteli rendszer
Célhoz értél... A személyeskedés pont a te stílusod.
Egy szakmai tárgyú bejegyzést sikerült teljesen eltérítened rossz irányba.
Gratulálok !!
Hát akkor hajrá, írj PM-t a kérdezőnek, és adj ajánlatot. Ha jól sikerül, akkor win-win, ha nem, akkor lesz egy újabb entry a phpfejlesztesmagyarorszag-on. :)
Ha mind a szakértelem, mind a szabadidő hiányzik, akkor a saját gyártású rendszer üzemeltetése is kihívás lesz.
Tudod mit, igazad van.
Téged nem Istvánnak hívnak véletlenül?
Köszönöm! Igen, erről van szó. Alant reagáltam erre, és az eddigi hozzászólásokra is.
Szerintem ez lesz az: https://wordpress.org/plugins/contact-list/
https://iotguru.cloud
Ha jól látom, ez egy egyszerű WP plugin.https://wpdatatables.com/nvm, vótmá'
Monica tudja ezeknek egy joreszet, es tud php-mysql-t is.
Reagálva a fentiekre, és egyben megköszönve az eddigi javaslatokat, hozzászólásokat:
Nincs céges weboldal és nincs keretrendszer. A dolgozók eddig excel táblákban tároltak mindenféle szirsz@rt, jelszavakat, telefonszámokat, miegymást. A jelszavak problémája meg lett oldva, viszont a belső hálózaton szerettem volna (szeretnék) használni egy böngészőben futtatható telefonkönyvet, mert így érzem praktikusnak. Az adatok a nagyvilág felé nem publikusak.
Több felhasználó is csak ahhoz kellene, hogy ne fordulhassanak a hozzá nem értésből adódó "balesetek" az adatok módosítása során (a dolgozó a továbbiakban csak megjelenítheti, de nem írhatja azokat). Excelben volt, hogy a kedves dolgozó névsorba rakta a telefonkönyvet, de csak a név oszlopot! Hát, volt pár év mire helyrerakták...
Mint írtam, találtam egy megfelelőnek tűnő addressbook php "alkalmazást", csak gondoltam rákérdezek, hátha tud valaki jobb, kész megoldást erre az önmagában nem túl bonyolult feladatra.
A példaként felhozott oldalon lévő telefonkönyv faék egyszerűen néz ki (ez nekem nagyon tetszik is így), és tartozik mellé egy igen részletes kereső, ami szintén nagyon hasznos! Az viszont tényleg nem jutott eszembe (nem vagyok webguru, sem programozó), hogy ez egy keretrendszer valamilyen plugin-ja lehet.
"Az írass magadnak" gondolatot viszont még valóban megfontolom, bár ennél egyszerűbbnek tűnik a meglévő addressbook-ot használni... ...igazából nem akartam túl sok energiát beletenni ebbe a pici részfeladatba.
Megj.: Jelen esetben ne egy nagy cégre gondoljatok! Mindössze pár fő dolgozó, nonprofit tevékenységi kör. Viszont nagyon sok rendezvényt szerveznek -- általában gyerekeknek --, ezért sok kapcsolat információt tárolnak. Jómagam külsősként segítek be nekik karitatív jelleggel, mert már rájuk omlott az informatika.
Erre viszont lehet egy CRM praktikusabb lenne. Nezz korul, foleg nonprofit + keves userrel vannak ingyenes/olcso megoldasok is, es a folyamataitokban is sokat segithet egy ilyen.
Hmm. Megfontolom. Köszönöm!
Suite CRM. Ez a valaha volt opensource Sugar CRM folytatása. A Sugar fizetős lett. Suite -nak a demója:
https://suite8demo.suiteondemand.com/#/Login user/pw : will/will
Van magyar myelv hozzá.
Ami ebből most téged érdekelhet az a view contact:
https://suite8demo.suiteondemand.com/#/contacts/index?return_module=Contacts&return_action=DetailView
Filterrel kereshetsz.
Be tudod állítani, hogy egy felhsználó pl. csak ezt az egyetlen menüpontot lássa, semmi mást.
Az igazi tudása a demo nézegetéséből nem derül ki, akár felfogható egy "keretrendszernek" is. Tetszőleges mezőkkel egészitheted ki az űrlapokat, az űrlapokat klónozhatod, akár teljesen újakat hozhatsz létre. ezeket kombinálhatod. Illetve tudja azt amit egy CRM pl . folyamatvezérelt (folyamat alapú) :
- Új ugyfél jött, egy hét múlva kuldjünk neki ismertető emailt , kimelt ugyfél jött , találkózót megbeszélni, egy nappal előtte figyelmeztessen, ha nem jött el telefononon hívni, ha nem vezi fel, emailküldeni stb.
ellenörzés: ki az akiknek még függő, elmaradt munkájuk van - na ezt szeretik a userek.
Körlevelek, csoportok, partnerek projekthez rendelése stb, szóval amit egy CRM-nek tudnia kell a partnerek csesztetéséhez. Illetve lehet programozni is "hook"-okat, php -ben írták az egészet.
Mobilon is megy.
Excelhez szokott csapatnál nagyon nehéz az ilyesmit bevezetni, kb a "programozón" és a "nagyfönökön" kívül senki nem akarja. De lehet csak egyetlen menüpont is.
https://blog.claryel.hu
Ezeknél jellemzően a telepítési, beállítási, betanítási, tanulási ügyek egy külön, komolyabb projektet jelentenek. Ráadásul egy csomó kapcsolódó dolog ki szokott derülni, hogy hát olyanunk nincs, nem így szoktuk stb.
Igen, ez könnyen lehet, hogy az egész bőven nem fér bele a karitativ jellegbe, talán egy menupont a partnerek adatai, aztán ha akarják továbblépnek
https://blog.claryel.hu
Egy működő és pénztermelő vállalkozásnál karitatívan?
szóval lehet, hogy csak a jogosultságot kellene megváltoztatni a megosztott excel fájlon, hogy ne tudja mindenki szerkeszteni? :)
Már, ha nem felhasználókezelés nélkül megosztott nasról van szó, ahová bárki bármit módosíthat, törölhet. (ezesetben a vírusokkal, géplekódoló zsarolóprogramokkal óvatosan)
Valóban ez volt valamikor (nem volt rendszergazdájuk egy darab sem), de ez volt az első amin sürgősen változtattam. Jelenleg tartományvezérlő, tartományba léptetett munkaállomásokkal és erősen korlátozott jogosultságokkal rendelkező felhasználókkal: csak ami a munkájukhoz feltétlenül szükséges.
Nem, mert ezzel csak a hitet erősíteném bennük, hogy a mindent is meg lehet oldani "a ekcelben". Apró lépésekkel formálom őket :-)
Pedig ha van excel licensz, akkor abban meg ahogy épp most hívják az access-tben pár ember vackait pont meg lehet oldani, és még ők is érteni fogják :)
Egyébként van valami oka, hogy self hosted megoldást keresel? Tényleg nem jó valami kész szoláltatás? Ha van excel, akkor van office, abban kiscsilió vacak van, többek közt address book is.
figyu, amennyi időt ezzel a thread-el már eltöltöttél, találtál volna kész megoldásokat, ha úgy keresel pl h SIP Phonebook/directory. A Cisco CallManager alapú telefonokban nincs beépített directory, ill. sok telefon csak 100 bejegyzést kezel, ezért van hozzájuk külső (XML?) alapú app.
A másik, hogy megveszed antikváriumban az alábbi könyvet: "Tanuljuk meg a MySQL használatát 24 óra alatt - 24 EGYSZERŰ, EGYÓRÁS LECKE"
amire végére érsz megírtad a fenti programot - és megnyerted a tudást is.
Node valszin az irány sem a legjobb, hogy a "belső hálózaton fusson" egy egyedi app. :)
Ha nonprofit, akkor kell kérni ingyen SharePoint Online licencet, és ott lehet továbbra is Excelben kezelni a listát.
Mondjuk akkor már Exchange Online (a levelezés is rendben lesz) és GAL-ba szépen fel lehet vinni a külső partnereket. Külön szép, hogy Outlook-ban használható, nem kell cigánykodni az Excel-lel.
https://naszta.hu
Tudod minden rendszer úgy kezdődik, hogy kell valami egyszerű kis dolog. Aztán még egy, még egy, még egy.
A saját cégemnek ERP-t fejlesztek, de nem így terveztem. Először csak kellett egy pénztárakat kezelő szoftver, ami másról nem szólt csak, hogy kinél mennyi céges kp van. Ebben a rendszerben lehetett átadni egymásnak pénzt. Ez nem ma volt, lassan 20 éve. Ahhoz, hogy ez megvalósuljon kellett egy keretrendszer ami egy másik projektből adott volt, kezelte a usereket. Aztán jött az ötlet, milyen jó lenne, ha lenne program ami jutalékot számolna. nem volt kérdés, hogy azt is ide integrálom. Ehhez kellett termék adatbázis, de akkor már mehetne innen a webshop admin is. Ekkor a számlázás egy másik rendszeren történt, innen pedig adta magát, hogy számlázzon a rendszer. S.Í.T. A vége az lett, hogy van egy rendszer ami minden vállalati funkcióval rendelkezik, ezen kívül csak mail és nagy ritkán irodai szoftvert használnak a kollégák. Jelenleg a teljes értéklánc minden egyes pontjában, minden egyes tranzakció ezen a rendszeren megy át.
Szóval csak kellett egy egyszerű kinél-mennyi-pénz van rendszerből ez lett.
^ ez
sosincs olyan, hogy csak egy mező :)
Régebben kerestem egy olyan megoldást amivel adatbázisokhoz, vagyis a benne tárolt adatokhoz gyorsan írható felhasználói felületet hozhatok létre.
Adatbázis kezeléséhez UI írása gyorsan
https://hup.hu/node/143998
Végül nem az ott javasolt megoldásokkal lett megírva ami kellett, hanem kézzel kicsit testre szabva. De emlékeim szerint kipróbálgattam amiket javasoltak és voltak jó megoldások.
Köszönöm! Ebben is vannak jó ötletek!
Szerintem a céges telefonkönyvnek LDAP-ban a helye, Windowsos környezetben ez azt jelentené, hogy az Active Directory-ban, és outlookból rögtön látod.
Partnereket viszont valóban CRM-ben szokás kezelni, de tisztán a kontaktok miatt CRM-et bevezetni overkill
Miben van a levelezésetek? Annak nincs címjegyzék funkciója?
Egyébként, erre a funkcióra még mi is "Excelt" használunk. A Google Workspace-ben van ugyan Directory, de azt közvetlen nem lehet telefonra kiszinkronizálni, így valakinél megvan a referencia kontakt lista, és Google-kompatibils CSV-t exportálunk.
Van amire felesleges ágyúval verébre lőni.
Blog | @hron84
via @snq-
Nem tudom, de én nem szenvednék sokat ezzel. Az oldalatokra, ha valami népszerűbb CMS-t futtat, lehet telepíteni egy address book vagy phonebook plugint, de szerintem nem éri meg.
Én csak simán kitolnék egy pdf-et letölthetőre, vagy HTML-ben oldanám meg, sima szövegként. Igen, nem lehetne rendezni, de lehetne benne épp úgy keresni, aztán kész. Felesleges Excellel, SQL-lel bonyolítani, meg így oldalakra bontani. Annyit nem ér az egész, ki telefonál ma már amúgy is? Ha nem tudja kit keres, felcsapja a cég, intézmény weblapját és ír e-mailt az első megtalálható elérhetőségre, akár központi, akár valami ott dolgozóé. Ez az egész telefon, telefonkönyv téma rég elavult. Lassan már weboldala sincs a kisebb cégeknek, csak FB profil.
Esetleg van valamelyik Google-szolgáltatásnak valami címjegyzék funkciója a naptár mellett, már nem tudom melyiknek, ingyenesen azt is lehetne használni. Ilyen baromságra én tuti nem fizetnék webdevet, hogy komplett oldalt fejlesszen le adatbázissal.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Ha már, én vCardként exportálnám ki. Be lehet mindenféle levelező, kontakt alkalmazásba húzni, és úgy keresi, rendezi, cicomázza a felhasználó a kártyákat, ahogy akarja.
Blog | @hron84
via @snq-
Ja, csak a topik író nem ez akarja... Esetleg az ő szempontjait kéne szem előtt tartani .
Neki egy egyszerű webes megoldás kell, ahogy olvastam.
A topik író egy megoldást talált, amiből projektált dolgokat.
De a topik író valós üzleti igénye pusztán annyi, hogy a kollegák egymás közt a legkevesebb szopás árán meg tudják oldani a különböző kontakt adatok egymással történő szinkronizálását.
Mivel kiderült, hogy egy nonprofit cég, potenciálisan szűk költségvetéssel, ezért a legkisebb befektetés az, ha első körben vCard exportot használnak, és ha ez kevés, akkor lépnek tovább. Ráadásul a vCard exportnak megvan az a kényelme, hogy bármilyen telefonba importálható és kereshető - márpedig a telefonszámok kerültek kiemelésre, mint fontos dolgok. Egy valamilyen phone book alkalmazás may or may not fogja ezt tudni, főleg, mert a telefonok alig kompatibilisek valamivel, még a CardDAV se mindig standard.
Blog | @hron84
via @snq-
Ha valaki hajlandó egy HTML fájlt karbantartani, akkor HTML+JS alapon könnyedén megoldható, tehát nem kell adatbázis: https://datatables.net
A manual részletes mintát ad, már csak a megfelelő verziókezelés kell mellé, hogy az eredeti kérésnek megfelelően többen is szerkeszthessék. Az oszlopok ízlés szerint alakíthatóak, így lehet tervezetten egyetlen telefonszám mező is rekordonként, vagy egységesen több mindenkinek.
AL
Az adatok nyugodtan lehetnek mellette egy csv-ben, akkor nem is kell html-t karbantartani. Aztan onnan behúzza egy táblázatba.... minimalista megoldás :)
“Any book worth banning is a book worth reading.”
Mivel az eredeti megoldás csak HTML-t meg JS-t használ - azaz nincs semmi PHP vagy bármely CGI program - elég 1 statikus állomány a szerveren, szerintem az a minimális. Ha adott a dinamikus környezet, meg a szakértelem - nem teljesen világos, hogy most ez a helyzet vagy sem -, akkor pár sor programból megvalósítható, feltéve ha eltekintünk az autentikációtól, a titkosítástól, stb.
Persze az is lehet vízválasztó, hogy aki az adatokat karbantartja az megijed egy HTML szerkesztésétől, de egy Excel-lel (CSV vagy TSV) már megbirkózik. Bár ha jól emlékszem az OP pont az Excelt akarta elkerülni.
Update: be kell vallanom, követtem el már pár soros Python programot, ami CSV-ből kigenerálja azt a HTML állományt, amely már egyedül megállja a helyét. Így kerekedett egy kereshető órarend, mely akármelyik oszlopára szűrhető volt, illetve bármely kombinációra is. Legalább nem kellett állandóan elővenni az Excelt, ha arra volt valaki kíváncsi, hogy mikor találja meg az adott tanárt, illetve mikor lehet adott terembe bemenni karbantartás miatt.
AL
"Mivel az eredeti megoldás csak HTML-t meg JS-t használ"
A csv se használna mást, csak könnyebb szerkeszteni, mert szövegfájl (vagy valami más egyszerű szöveges formátum is ugyanúgy működhet). Egy request behúzza a html-be, js parsolja és feltölti vele a táblát. Csak eggyel több statikus file, nem kell dinamikus környezet hozzá a szerveren.
“Any book worth banning is a book worth reading.”
es erre valo a cimtar, nem az sql :D
Talan kevesbe agyuval verebre mint a wp, de ez? (Monica crm) / php / tudod te is futtatni ha van affinitas. De ott van a cloud verzio is
Amúgy a legegyszerűbb az Excel - HTML export :D
Szerintem később szükségem lesz nekem is ilyenre, szóval ha van specifikációd, akkor szerintem valami értelmezhető határidőn belül akár meg is írhatom.
(Viszont, hogy kinyissam a HUP-ShitStorm (tm) ládát, ez a házvezérlése belül kerül majd megvalósításra)