Mysql alapokon működő telefonkönyvet keresek

Segédprogramok

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!

  • 2328 megtekintés

( levideo | 2022. 08. 26., p – 12:13 )

Szerkesztve: 2022. 08. 26., p – 12:17

Írj magadnak vagy írass egy programozóval  egyet PHP + MySQL  alapon, olyan funkciókkal, ami neked pont kell !!

( arpi_esp v | 2022. 08. 26., p – 13:13 )

Szerkesztve: 2022. 08. 26., p – 13:25

kerdezd meg toluk, mit hasznalnak

header alapjan

WordPress 5.9.3

gondolom 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.

Tetszőleges php framework-el megíratod, embert találsz hozzá bármikor.

Á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.

Ha a "security breach jegyzőkönyv"-ben a wp plugin-ra mutogathatsz az miben jobb?

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

Árban kb. mit saccolsz, mennyiért csinálja ezt meg neked egy bármikor talált ember?

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ő.

Ezeket javítják gyorsan és automatikusan frissül a plugin.

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 :).

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ő..

Oké, a bullshit után: árban kb. mit saccolsz, mennyiért csinálja ezt meg neked egy bármikor talált ember?

Már ha a karbantartó valóban rendszeresen frissíti (ez a wp plugin repository nagyon kis százaléka).

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

A legolcsóbb ha valami kis csapat bevállalja két nagyobb meló közé.

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á.

Már ha a karbantartó valóban rendszeresen frissíti

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á. :)

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á. :)

Í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.

  1. Az MD5 nem titkosítás, hanem hash
  2. Az MD5-öt lassan 10 éve tartja a szakma nagyjából konszenzusosan deprecatednek.

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".

zászló, zászló, szív

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..

1920. augusztus 01. a Magyarországi Tanácsköztársaság vége.

1918. március 21. – 1920. augusztus 01. Magyarországi Szocialista Szövetséges Tanácsköztársaság.

Nagyon nagy történelmi bűn, hogy létrejöhetett Magyarországon, 1918-ban a tanácsköztársaság.

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

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

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

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 ??

1920. augusztus 01. a Magyarországi Tanácsköztársaság vége.

1918. március 21. – 1920. augusztus 01. Magyarországi Szocialista Szövetséges Tanácsköztársaság.

Nagyon nagy történelmi bűn, hogy létrejöhetett Magyarországon, 1918-ban a tanácsköztársaság.

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...

Mert ha excel táblában tárolunk telefonszámot az nem az?

De, az. Csak egy fokkal könnyebb

  • ráfogni, hogy ez ad-hoc, mint amikor direkt van egy célfejlesztés (mondjuk szerintem akkor is bukó, de van esély kisebb büntire)
  •  betenni egy sharepointba, ahol van normális jogosultságkezelés

Vagy ne tároljunk telefonszámokat, e-mail címeket saját használatra?

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:

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. :-)

É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 ..

És mennyiért találsz olyan PHP fejlesztőt, akinek minimum egy kisdoktorija van kriptográfiából?

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 ...

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?

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

É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.

Ez elég diszrkiminatív, sőt sértő.   Ennyit a HUP liberális felfogásáról.

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)

"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

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)

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

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

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

Igen. Ez a helyzet.

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…

De ha már így rákérdeztél én ezt az implementácót használtam ilyen feladatra.

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 ..

Tetszőleges php framework-el megíratod, embert találsz hozzá bármikor.

Hoooogyne, a világ pénzéért nem találunk értelmes fejlesztőket, gondolom milyen sokan fognak ide is jelentkezni. Hacsak nem... :)

Ha a "security breach jegyzőkönyv"-ben a wp plugin-ra mutogathatsz az miben jobb?

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.

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.

1. Én elvállalnám olcsóbban is.

Ja, azt látjuk...

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.

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

Úgy látom csak kekeckedni tudsz

Olvasni tudok. Amit eddig összehordtál, abból látszik, hogy te vagy a piac egyik legolcsóbb embere. Okkal.

Ha nem ért sem a PHP-hoz, sem a Wordpress-hez akkor bízza olyanra aki ért hozzá ! 

Aki ért hozzá, az drága. Aki úgy gondolja, hogy ért hozzá, az nyilván olcsóbb, de később lesz drága.

 De erre a feladatra overkill a WP, szerintem.  

Nem, erre a feladatra teljesen megfelelő egy WP + plugin.

https://iotguru.cloud

1. Én elvállalnám olcsóbban is.

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. :)

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.

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.

( PeterX | 2022. 08. 27., szo – 08:22 )

Szerkesztve: 2022. 08. 27., szo – 08:47

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.

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

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)

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.

szóval lehet, hogy csak a jogosultságot kellene megváltoztatni a megosztott excel fájlon, hogy ne tudja mindenki szerkeszteni? :)

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.

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.

( igiboy | 2022. 08. 27., szo – 14:41 )

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.

( Aadaam v | 2022. 08. 27., szo – 15:28 )

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

( hrgy84 | 2022. 08. 27., szo – 17:40 )

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

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

( Raynes v | 2022. 08. 27., szo – 21:46 )

Szerkesztve: 2022. 08. 27., szo – 21:47

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.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

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

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

( AszaltSzilva | 2022. 08. 29., h – 19:44 )

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

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.”

( golgota | 2022. 08. 29., h – 20:35 )

es erre valo a cimtar, nem az sql :D

( mbael | 2022. 08. 30., k – 22:43 )

Szerkesztve: 2022. 08. 30., k – 22:53

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

( szabog75 | 2022. 09. 02., p – 10:00 )

Amúgy a legegyszerűbb az Excel - HTML export :D

( hyperborg | 2022. 09. 08., cs – 09:54 )

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)