Sziasztok!
(másfél év múlva megszűnik a támogatás a yii 1.1 esetében)
Bár itt jön az 1.1-es kérdésem 
, hogy egy meglévő honlaphoz feltudom rakni könnyedén a legújabb yii frissítéseket?
A 2.0-ból még nincs publikus béta, de az már most látszik, hogy eléggé sokmindenben különbözni fog az 1.1-től. Ha mindenképpen upgrade-elni szeretnél, akkor valószínűleg újra kell majd írni az alkalmazásaid kódjának nagyobb részét (ahogy pl. a Symfony2 és a Zend Framework 2 esetében is). Kérdés, hogy miért tennéd? Attól, hogy megszűnik a támogatás az 1.x-hez, a weboldalaid még gyönyörűen tovább fognak működni, akár évekig, és mivel a Yii 1.1 egy kiforrott és stabil keretrendszer, kicsi a valószínűsége annak, hogy olyan súlyos hibába vagy hiányosságba szaladsz bele, ami elkerülhetetlenné teszi az upgrade-et. Ha mégis felbukkan ilyen probléma - mondjuk egy kritikus biztonsági hiba - akkor minden valószínűség szerint lesz hozzá javítás a másfél év letelte után is.
Aránylag könnyen megy, legalábbis az 1.1.x branchen belül. A feljlesztők eléggé odafigyelnek a visszamenőleges kompatibilitásra, nem szokott probléma lenni.
sziasztok!
van egy adatbázisom, benne kapcsolótáblák. ezekhez nincs primary key mező. így viszont a crud generator nem enged modelt generálni hozzá. a kapcsolótáblákban pedig nincs szükségem primary key-re. ötlet, hogy lehetne megoldani ezt? (lehetőleg primary key hozzáadás nélkül)
Miért van szükséged model osztályokra a kapcsolótáblákhoz? Ha ezek tényleg csak kapcsolótáblák (vagyis az összekapcsolt táblákra mutató idegen kulcsokon kívül semmilyen más adatot nem tartalmaznak) akkor fölösleges modelt generálni hozzájuk.
máskülönben hogy tudnék beszúrni azokba a táblákba?
Én ezt általában a tábla által összekapcsolt modelleken keresztül oldom meg:
class MyModel extends CActiveRecord
{
//...
public function addMyRelatedModel(MyRelatedModel $model)
{
// Ide jön az SQL parancs, ami létrehozza a kapcsolótáblában a szükséges rekordot
}
}
Alternatívaként érdemes lehet ezt megnézni: with-related-behavior
Sziasztok!
A migrációs utasítás hogyan működik? Van ez a kiegészítő, szeretném feltelepíteni: http://www.yiiframework.com/extension/yii-user
De a migrációs lépésnél elbukom…
Terminál parancsnál megadom:
./yiic migrate --modules/user/migrations=user.migrations
Error: Unknown action: --modules/user/migrations=user.migrations
És így nem igazán tudom, hogy miért, mi itt a gond. Igazából nem is értem, hogy mi az a user.migrations. Hát na, még csak most ismerkedem a yii-vel De amúgy az feltűnt, hogy – féle lehetőség nincs a súgóban, hanem action-t vár a migrate parancs után.
Van valakinek valamilyen megoldása?
Próbáld így:
yiic migrate --migrationPath=user.migrations
Ne helyettesítsd be a "migrationPath" helyére a tényleges elérési utat!
Az user.migrations egy path alias, ami alapértelmezésben a protected/modules/user/migrations könyvtárra mutat.
Köszönöm a választ. Aztán végül van egy egyszerűbb mód is. A migrations fájlba másolni ami kell, és csak egy ./yiic migrate parancsot nyomni.
De köszönöm mégegyszer a hozzászólásodat!
Ez vajon miért dob nekem vissza mindig üres objektumot?
$pelda = Model::model()->find(array(
'condition'=>'uid='.$id,
'select'=>'SUM(valami) AS ertek'
));
Nincs benne az érték, de ha mást is oda írok mellé, akkor az megjelenik. Ha csak a valamit kérdezem le az is jó. Az érdekes, hogy még a SUM nélkül sem jó az "alias".
Szerk.: A legérdekesebb, hogy az sql logban pedig szépen ott az ertek. Ergó a lekérdezés jó, csak valami miatt a pelda változó nem jelenít meg nekem semmit sem. 
Valaki csinált már role access-t?
Sql-es megoldáson gondolkozok.
Létrehozni egy privileges táblát, ahol le lennék írva a csoportok user/admin/superadmin/editor/author stb…
Lenne egy másik tábla ahol pedig az action-ök lennének és hozzájuk a leírás, de mivel még nem foglalkoztam ezzel a role dologgal, így eléggé homályos nekem. Elolvastam pedig már a wiki-t ezzel kapcsolatban.
CDbAuthManager
A framework/web/auth könyvtárban megtalálod a szükséges SQL fájlokat minden támogatott RDBMShez.
A guideban szerintem elég jól le van írva. Elolvasva lehet, hogy bonyolultnak tűnik, de ha hozzáfogsz lépésről-lépésre megcsinálni, rájösz, hogy egyszerűen megy.
Igen, néztem már mindegyiket. De szerintem túl van ott bonyolítva. Vagy lehet, hogy csak én érzem ezt így.
Én ennél egyszerűbbre gondoltam. Holnap nekiesek még egyszer.
csak tipp, próbáld meg így: ‘select’ => ‘t.*,SUM(valami) AS ertek’, gyanús, hogy a model-nek a te verziódban nincs PK-je…
Így sem lett jó. 
$bonusz = Kiemeles_user::model()->find(array(
'condition' => 'uid='.$id,
'select' => 't.*, SUM(bonusz) as osszeg'
));
var_dump($bonusz); exit;
Itt van a var_dump kimenete.
RABC-al kapcsolatban. Megnéztem a yii cookbookban. Ott már valamivel világosabb volt a dolog.
Ott létrehoztak még egy controllert neki, amivel az adatok fel lettek töltve az adatbázisba (gondolom én, hogy csak feltöltötte).
Egy dolog nem világos nekem még, hogy ezt miért így oldották meg.
$auth->assign('reader','readerA');
$auth->assign('author','authorB');
$auth->assign('editor','editorC');
$auth->assign('admin','adminD');
Itt ugye nevek vannak rendelve a csoportokhoz. Nem értem, hogy miért nem user_id-k.
Szerintem csinálok egy új osztályt és az auth-ból származtatom, majd átírom magamnak egy kicsit hogy jó legyen.
Én abból indultam ki, hogy csinálok egy táblát a jogoknak:
id | csoport
1 | admins
2 | users
3 | moderators
Majd minden regisztrált user-t alapból a 2-es csoportba rakok, a users táblában meglenne neki a helye és én az assign helyére inkább user id-t vennék fel. Majd meglátom mi lesz a vége. Remélem nem valami bughalmaz.
Ok, egyre jobban körvonalazódik a dolog. 
Már csak azt nem értem, hogy a pk-k miért varchar-ok és nem int-ek.
Így elég nehéz összekapcsolni őket. Illetve mi van, akkor ha egy user jogkörét megakarom változtatni? Frissítenem kell az összes hozzá tartozó bejegyzést az adott táblában (AuthAssignment)?
Minden setre szerintem lehetne még mit alakítani rajta.
Oké, van osszeg nevű property-je a Kiemeles_user class-nak? Ha nincs akkor azért nem találod az összeget, az attribútumokat a table schema alapján szedi elő, márpedig, ha sum-os, akkor az nincs benne.
Amúgy kicsit sántít a dolog, ezzel a módszerrel egy model-t kapsz, tehát nincs értelme a sum-nak, ha csak az összeg kell, akkor nem kell AR, vagy leglábbis nem ilyen módon.
Az "AuthItem", "AuthItemChild" és "AuthAssignment" táblákat a CDbAuthManager kezeli. Közvetlenül sem írnod sem olvasnod nem kell ezeket, ennélfogva a szerkezetük sem igazán érdekes számodra.
Nincs ott semmi osszeg. Az érdekes, hogy pl más AR lekérdezésben pl az ifnull(valami, 100) as sorrend simán működik.
Szóval, elvileg itt is kellene a sum-nak mennie. Na, mindegy. Nem erőlködök vele.
De pont, hogy érdekes lenne számomra. Össze szeretném kapcsolni a user táblával és minden új user-t egy adott csoportba tenni. Vagy pl a csoportok jogait állítgatni, esetleg a child-eket. Szóval, valahogy ezeket nekem meg kellene adni. Lehet én olvasom a wikit, meg a cookbook felületesen, de ilyenekre egyik sem tér ki.
Szerk.:
Most, hogy van egy kis szabadidőm a saját oldalamat is átírnám yii-re.
Én valami ilyesmi táblákra gondoltam és mondom akkor beleveszem már az RBAC-t is.
3201
Ha a user táblából akarsz több sort összegezni, akkor arra a user model nem lesz jó (a model-re alapvetően úgy gondolj, mint egy db-sor reprezentációja, persze ennél jóval több is), ha egy related model sorait szeretnéd, akkor pedig a criterianak meg kell mondani, hogy melyik related model-t akarod hozzáadni a query-hez.
Mod:
Ezt mind megteheted az AuthManager-en keresztül, ‘kézzel’ nem érdemes babrálni vele, hiszen minden alapvető művelet implementálva van, ami csak kellhet.