Jeżeli chcemy zaimplementować funkcjonalnośc IPB, to dobrze byłoby przemyśleć system zezwoleń dla użytkowników i grup.
Najlepiej chyba byłoby zmienić relacje group - user na habtm i dodać jakąś tabelę przechowującą prawa dla danych użytkowników/grup. A tabela z uprawnieniami zawierałaby po prostu nazwy kontrolerów i akcji, do których dostęp jest zezwolony (tudzież zabroniony - trzeba będzie pomyśleć co będzie korzystniej ustawić).
Co o tym myślicie?
Hmm… W ipb jest to rozwiazane dosyc ciekawie i prosto, tzn mowie tutaj konkretnie o 1.3 nie wiem jakie ma mozliwosci 2.1 
w zasadzie sie nie interesowalem nawet ale przedewszystkim najwazniejsze sa uprawnienia dla forow, nie widze sensu tworzenia tutaj dodatkowej do tego tabeli, dla informacji ktora maska prawa gdzie ma dostep te dane powinny sie znajdowac juz konkretnie w tabeli fora czyli can_read, can_post, can_start, can_upload, can_see_attachment i w tych kolumnach przechowywane byly by konkretne id masek praw dla forow latwe to bedzie w edycji z poziomu forum oraz z poziomu maski 
Mysle ze nie ma sensu odkrywac tutaj tego na nowo… to jest sposob sprawdzony i lubiany w ipb pozatym daje proste i duze mozliwosci w nakladaniu sie kilku masek no i uwalnia od tworzenia zlozonych relacj pomeidzy tabelami masks <-> forums
Teraz jesli chodzi o przydzielanie praw do konkretnyh controlerow oraz ich akcji to ja osobiscie bylbym za tym aby stworzyc tabele … tylko nie wiem jak ja nazwac jeszcze ktora by posiadala nastepujace kolumny:
id(int), privelegs_name(varchar[128]), privelegs(text)
kolumna privelegs byla by tutaj najwazniejsza to ona posiadala by prawa do konkretnych kontrolerow,akcji mozna to zrobic w nastepujacy sposob:
hash { nazwa_contrwollera => ([nazwy_akcji_do_ktorych_user_ma_dostep,…,…,…] lub [*] jesli user posiada dostep do wszyskich akcji z danego kontrolera } Tylko teraz zastanawaim sie czy wogole dla takiego forum jest potrzebny tak rozbudowany system praw do controllers/actions. W zasadzie moze sie okazac to zbyt… problematyczne i latwije po prostu by bylo zrobic to znow tak jak jest to zrobione w ipb… tabela grupa posiada kolumny g_nazwa_akcji typu bool i true/false jesli ma sie do konkretnej ackji dostep owiele latwiejesze w implementacji i przedewszystkim zarzadzaniu Moze poraz kolejny nie warto wymyslac czegos zupelnie od nowa ?
Ogolnie jestem stanowczo za tym aby po prostu korzystac z pomyslow ipb sa sprawdzone i beda jeszcze latwiejsze w implementacji w rubym niz w php 
nie mowie juz o ilosci kodu poswieconego na nie
Moja styczność z ipb jest praktycznie zerowa. Mógłbyś troszeczkę jaśniej (najlepiej na przykładzie) wyjaśnić jak to jest z tymi prawami dla for?
Hmm… moge sprobowac
CREATE TABLE 30forums (
id smallint(5) NOT NULL default ‘0’,
[…]
start_perms varchar(255) NOT NULL default ‘’,
reply_perms varchar(255) NOT NULL default ‘’,
read_perms varchar(255) NOT NULL default ‘’,
upload_perms varchar(255) default NULL,
[uwazam ze jeszcze powinno dojsc view_upload_perms w celu dawania ograniczen na konkretne fora kto ma prawo widziec upload a kto nie w ten sposob np mozna latwo ograniczyc kto moze widziec zalaczniki (guest? inna grupa) a kto nie :]
[…]
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
Wszystkie te kolumny zawieraja id perm_mask odzielone przecinkami (najprostrza i chyba najlepsza serializacja jaka jest, jestem przeciwnikiem upychania gdzie sie da has_many 96 tysiecy postow dla ipb i strona glowna laduje sie w 0.12 s i tylko 10 zapytan ogolnie
Jedyne dane jakie sa potrzebne dla perm_mask to:
CREATE TABLE 30forum_perms (
perm_id int(10) NOT NULL auto_increment,
perm_name varchar(250) NOT NULL default ‘’,
PRIMARY KEY (perm_id)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
uzywa sie ich tylko podczas konfiguracji w panelu administracyjnym.
Jesli chodzi o sprawdzanie tych praw to odbywa sie dwojako… przedewszystkim uzytkownik moze miec nadpisane prawa grupy czyli mozna ustawic dla konkretnego uzytkownika kilka roznych perm_mask beda one zapisane w org_perm_id po id odzielone przecinkami. Jednak org_perm_id jest ustawione na 0 wtedy uzytkownik korzysta z perm_mask przypisanych do jego aktualnej grupy, oczywiscie grupa moze miec kilka rodzajow perm mask no i tutaj znow sie one na siebei nalozal
Jesli chodzi o dostep do konkretnych funkcji na forum… np dodawanie ankiet, odpowiadanie na swoje topici i rozne inne dziwne rzeczy to dane na ten temat sa przechowywane w kolumnie konkretnej grupy. Ogolnie jestem obiema rekoma i nogami za tym aby wlasnie taki system zaimplementowac w YABB. Dlaczego ?
- Jest naprwde latwy w zarzadzaniu dla end-user’a
- Nie wymaga duzej ilosci niepotrzebnych zapytan do bazy, wystarczy porabc i tak potrzebne dane na temat grupy i perm mask a potem porownywac je z przegladanymi forami
- Jesli chcemy dodac jakas nieoficjalna funckjonalnosc, np mozliwosc przegladania badzm nie przez konkretna grupe kto aktualnie jest online i co robi, mozemy to w bardzo latwy sposob dodac z poziomu wlsnie tabeli grup… A jesli chcemy dodac np mozliwosc definiowania kto ma miec prawo klikac w linki na tym forum, badz ogladac wlasnie zalaczniki lub jeszcze inne dziwne rzeczy tez nie bedzie to trudne w implementacji.
Rozbijanie sie na elastyczne zarzadzanie prawami poprzez Controller/Action bedzie imho zbyt trudne w zarzadzaniu dla endusera i moze sprawic troche problemow w implementacji, wkoncu nie wszystkie funckje chcielibysmy ograniczac prawda ?