Belefutottam egy olyan igénybe az egyik készülő projekt kapcsán, amire nem sikerült még eddig megoldást találnom…
A lényeg: adott egy főiskolai közösségi oldal, aminél azt szeretnék a fejesek, ha csak az adott főiskola hallgatói regisztrálhatnának. Az intézmény 2 olyan adatot köt hozzá minden hallgatóhoz, ami egyedi, publikus és azonosításra alkalmas: az úgynevezett EHA kódot, valamint egy főiskolai domainnel ellátott e-mail címet.
Első körben én a mail címes játék mellett szerettem volna dönteni, mert akkor meg tudom azt csinálni, hogy az adott domainen kívül minden egyéb mail-domaint kitiltok a regisztrációs folyamat során. Viszont belefutottam egy-két dologba, ami hátráltat ilyen téren:
Nem találtam olyan bővítményt, leírást, ami működne Buddypress alapon, és ingyenes is (amíg nem muszáj, nem akarok fizetős megoldásokat, mert a drágalátos hivatali bürokrácia miatt így is több hónapos csúszásban vagyunk)
Közölte a vezetőség, hogy annyira az nem jó megoldás, mert sokan nem használják, meg amúgy is…
Tehát maradt az EHA kódos játék…és itt a kérdésem: világosítson fel valaki, hogy létezik-e arra valami varázslat, hogy egy extra adatot leellenőrizzen a Buddypress a regisztráció során? Gyakorlatban: Kis Józsika regisztrál, megadja a felhasználónevét, mail címét, jelszavát, lábméretét, a napi átlaghőmérsékletet,valamint az EHA-kódját… és amikor rábök a kis aranyos a “Mehet” gombra, akkor lecsekkolja valahogy az oldal a meglévő EHA-listából, hogy létezik-e ez a kód, és ha igen, csak akkor engedje regisztrálni… az még jobb, ha dupla regisztrációt nem engedünk, de ez már csak luxusgondolat
Napok óta ezen agyalok, úgyhogy ha van valakinek ötlete, akkor ne tartsa vissza
Hát az EHA kódok azért kellenének, vagy hogy hogyan néz ki az EHA kód, hogy bele tudd tenni. Onnan már csak, HA van EHA tovább mehetsz, ha nincs EHA bebuktad feltétellel végeztél. user_meta-val beküldöd a db-be. És ha tovább gondoljuk a dolgot, akkor az előző feltételt kiegészítjük azzal, hogy HA van EHA ÉS nem vagy benne db-ben, akkor tovább mehetsz, HA nincs, akkor bebuktad. Egy adattal kell tehát kiegészítened a regisztrációt és az megfelelően beküldeni a db-be és azt feltételhez kötni az EHA alapján. Illetve még arra lehetne ügyelni, ha hibás EHA-t ad meg és figyelmeztetni arra, mondjuk kevés karakter pl.
ápdét: http://wordpress.org…ion-codes/�� Ezt mondjuk könnyen át lehet szabni, arra amire kell. Főleg, ha van valami logika az EHA kódokban. Ha nincs az se nagy gond, mert a nagy része már készen van ezzel a dolognak.
Köszi, majd rájuk nézek délután! Az EHA-kódokról: Sok logika nincs benne, az első 3 karakter a user nevéből jön, a többi random…amúgy fix listát kapunk a kódokról…félévente
ETR kód: Az első kettő a vezetéknév első két betűje, a harmadik a keresztnév első betűje, a negyedik az évfolyam, az utolsó a kart (szakot)jelöli, a többi pedig arra szolgál, hogy ha ugyanolyan lenne az első 4 betű, akkor meg tudják különböztetni (névsorban az abc szerint hogyan követik egymást - vagyis, aki előrébb van a névsorban az AA-t kap, aki a következő az AB-t stb.).
Az érvényes EHA kódok listáját valahogyan meg kell kapnod (legalább napi frissítéssel) az intézménytől, és azt kell szerintem összehasonlítanod a belépő által megadottal. Két állapota lehet a kódnak: vagy élő, vagy nem élő (vagy tanuló/oktató, vagy nem )
Győző: akkor javítok, nem random a többi része Mint írtam, félévente megkapjuk az új EHA-kódokat, felesleges naponta. Egyszer beiratkozáskor kiosztják őket, aztán kész, nem változik. A “nem élőket” se kell vizsgálni, mert közölték, hogy aki egyszer ide járt, az egy életre jogosultságot kap mindenhez…
hgrg: az lehet, de remélem addigra én már nem fogok ide járni
Elég érdekes információ: egy tanár elmegy valahova kubikolni, de a kódja örök életű. Ha a diákot kicsapják, a kódja örök életű. Ok. Akkor tényleg felesleges a napi frissítés.
És piszkosul érdekelne a megoldás, mert nekem majd adóazonosító jelhez és TAJ számhoz kellene ilyesmi (mondjuk, ez a két számsorozat legalább valami függvénnyel leírható).
Győző, amint lesz valami infó, szólok Bár most Efrud adott egy jó tippet ezzel az invitation code dologgal, ha meg tudom úgy csinálni, hogy előre megadhatom a “kódokat”, és nem a rendszer generálja (és persze működik a Buddypressel )
A “halhatatlanságról”: lehet, hogy pl az ETRből törlődnek ilyen esetben, de jelen projektnél nincs erre szükség. Igazából én az egész EHA témát feleslegnek tartom, de a vezetőség akarja…
En azt ajanlom neked ha tenyleg csak az a feladat hogy egy adott field megjelenjen a reg urlapon+felhasznalohoz legyen kotve+kene ellenorzes
akkor
Advanced Custom Fields -> ezzel tudsz felhasznalohoz is csinalni fieldet! es elkesziteni egy egyedi fieldet sem nehez mert jol van dokumentalva es nagyon szep OOP van alatta! kb 1 ora alatt doksi olvasassal egyutt megcsinalod a fieldet es akkor annak az ellenorzesenel majd meg tudod csinalni az ellenorzest a field megjelenites stb azt megoldja a plugin
Köszi Egg, de közben az Efrud által linkelt bővítmény BP-s verziójával sikerült megoldani a dolgot Sajnos most még csak egyesével lehet feltölteni a dolgokat,a fejlesztő ígéretet tett már arra, hogy a következő verziókba beleépíti a CSV feltöltést…
(amíg nem muszáj, nem akarok fizetős megoldásokat, mert a drágalátos hivatali bürokrácia miatt így is több hónapos csúszásban vagyunk)
Bár most Efrud adott egy jó tippet ezzel az invitation code dologgal, ha meg tudom úgy csinálni, hogy előre megadhatom a “kódokat”, és nem a rendszer generálja