Mentat

• Admin - definuje manažery skupin nebo přiřazuje uživatele do skupin
• Manager - přiřazuje uživatele do své konkrétní skupiny
• User - smí pokládat dotazy, ukládat/mazat svoje dotazy

• kdo je manažerem (buď uloženo ve skupině nebo v objektu uživatele)
• kdo jsou uživatelé (buď uloženo ve skupině nebo v objektu uživatele)
• případná další data (statické uložené dotazy?)

(User může být ve více skupinách, Manager může být managerem více skupin, skupina může mít více manažerů.)

• uživatelský (uživatel smí mazat)
• skupinový (uživatel nesmí mazat)
• uživatelem přidaný skupinový (smí mazat uživatel? admin skupiny?)

V budoucnu - Mek by rád využil objekty skupin na vlastní role (pro rozesílání) a vlastní data (abuse kontakt)

Zvazoval jsem obe varianty, rozdelovat informace do dalsich kolekci, jako je priklad nize.
Vyhoda by byla, ze by se jednalo vzdy o jeden dotaz (nacti mi vsechny query, kde
je owner toto id (id muze byt od skupiny nebo od uzivatele). Jeden dotaz by nacetl
vse, ale bohuzel je neudrzitelna integrita a horsi overovani opravneni mazani.
Podobne to je s udrzenim integrity i u ostatnich kolekci.

query: {
        name: 'test',
        simple: 'test',
        owner: ['52eb3799b939173272e21e48', '38eb3799b939173272e21e48'],
}

user: {
        username: 'orkac@cesnet.cz',
        name: 'Radomir Orkac',
        role: ['admin'],
        group: ['35eb3799b939173272e21e48', '33eb3799b939173272e21e48'],
}

group: {
        name: 'abuse',
        manager: ['13eb3799b939173272e21e48', '10eb3799b939173272e21e48'],
}

V jednoduchosti je krasa a podle me by mohl nize uvedeny navrh postihovat zatim veskere (Pavlem sepsane) pozadavky.

user: {
        username: 'orkac@cesnet.cz',
        name: 'Radomir Orkac',
        role: ['admin', 'dalsirole1', 'dalsirole2'],
        query: [{
                name: 'test1',
                simple: 'test1',
        }]
        cidr: ['158.196.158.0/24'],
}

user: {
        username: 'kacha@cesnet.cz',
        name: 'Pavel Kacha',
        role: ['manager', 'dalsirole1'],
        query: [{
                name: 'test2',
                simple: 'test2',
        }]
        cidr: [],
}

Atribut manager je ciste jen pro spravu skupiny. Manager musi byt soucasti user, aby mohl cerpat vyhody/prava skupiny
group: {
        name: 'abuse',
        manager: ['13eb3799b939173272e21e48'],
        user: ['13eb3799b939173272e21e48', '33eb3799b939173272e21e48'],
        query: [{
                name: 'test2',
                simple: 'test2',
        }]
}

• Taky si myslím, že druhá varianta je jednodušší, a koneckonců box s uloženými query budeme stejně generovat nejspíš nějak ve stylu "jeden nadpis, teď vypiš všechna skupinová query, druhý nadpis, teď vypiš všechna uživatelská query", takže to budou dva dotazy, jeden na query ve skupině (ta ti tam teď chybí), jeden na query uživatele.
  Pokud dovolíme editaci skupinových query (třeba manažerem skupiny), budou na to ale editační rutiny muset dávat bacha (s jakým objektem pracují).

• Chápu to dobře, že když chce user přidávat/ubírat členy skupiny, musí mít roli 'manager', a současně musí group.manager odkazovat na jeho id? Je pak obecná v user.role, že je manager, k něčemu? Nestačí jen group.manager? Když chceš pracovat se skupinou, víš se kterou a stačí se podívat, zda v group.manager tvoje id je.

• user.role manager by mohla být užitečná jen pro catalystí acl, pokud bys podle toho chtěl řídit vstupy na stránku, editující skupinu - pak ale potřebuješ dělení i podle skupiny, nejen podle managera, a musely by nejspíš existovat role nějak ve stylu 'manager_cesnet_certs', 'manager_vsb', atd. aby byly catalystí ACK tak jak jsem je na VC pobral schopné to pochopit.
  Resp. jde vůbec nějak (třeba i jinak) pomocí catalystích ACL udělat to, že uživatel může
  editovat jednu skupinu a ne druhou? Nebo je potřeba to dělat v kódu po
  vlastní ose?

users

{ 
   "_id" : { "$oid" : "52e67c38e66db1b965000000"},
   "name" : "Pavel Kacha",
   "organization" : "CESNET",
   "roles" : [ "admin" , "delete"],
   "status" : 0,
   "username" : "ph@cesnet.cz" 
}
{ 
   "_id" : { "$oid" : "52e76ef4d413756d36000000"},
   "name" : "Jan Mach" , "organization" : "CESNET",
   "roles" : [ "admin" , "edit"],
   "status" : 0,
   "username" : "mach@cesnet.cz" 
}
{ 
   "_id" : { "$oid" : "52e67bf9e66db1b565000000"},
   "name" : "Radomir Orkac",
   "organization" : "Vysoka skola banska - Technicka univerzita Ostrava",
   "query" : [ { "$oid" : "52f290fd73006dd63b000000"},{ "$oid" : "52f291ca73006dd33b000000"}],
   "roles" : [ "admin" , "delete"],
   "status" : 0,
   "username" : "orkac@cesnet.cz" 
}

groups:

{ 
   "_id" : { "$oid" : "52f2a25ccf0be76e3c000000"},
   "name" : "abuse" ,
   "query" : [ 
      { "simple" : "test2" , "name" : "test2"},
      { "simple" : "test3" , "name" : "test3"}],
   "users" : [ "52e67bf9e66db1b565000000" , "52e67c38e66db1b965000000"]
}

Pridani query:

$result = $COLLECTION_G->update(
    {"name" => "abuse"},
    {
        '$push' => {
            'query' => {
                "name" => "test3",
                "simple" => "test3" 
            }
        }
    }
);

Odebrani query:

$result = $COLLECTION_G->update(
    {"name" => "abuse"},
    {
        '$unset' => {"query.1" => 1}
    }
);

$result = $COLLECTION_G->update(
    {"name" => "abuse"},
    {
        '$pull' => {"query" => undef}
    }
);

Nefungujici prace s ACL:

#__PACKAGE__->allow_access_if_any( "/alerts/deleteQuery", qw/admin/ );
#__PACKAGE__->allow_access_if( "/alerts/deleteQuery", qw/admin/ );

Fungujici prace s ACL:

__PACKAGE__->allow_access_if( "/alerts/deleteQuery", sub {
    my ( $c, $action ) = @_;
    unless ( $c->check_user_roles(qw/delete/)) {
        die "permission denied";
    }
});

• při vytvoření má uživatel _id = username, skupina _id = name, tím se vyřeší problém možné změny eppn, ale bude to pořád lidsky čitelné. Pokud se ukáže, že bezvýznamový identifikátor je rozumnější, nahradíme.
• prozatím nemáme globálního manažera (manažera manažerů), admin stačí, v budoucnu tohle možná pořeší Perun
• uložené dotazy - uživatelské u uživatele, skupinové u skupiny
• v user.groups je seznam skupin, kterých je uživatel členem
• v group.managers je seznam správců skupiny
• ACL v konfiguračním souboru

Mel jsem do dneska odevzdat "nejaky" kod.
Snazil jsem se makat chvili v patek, ale jinak jsem delal opravdu hodne o vikendu.

Na mentat.vsb.cz je kod aktivni, jinak je ale v devel vetvi pushnut.

Asi se Vam to nebude zdat, ze jsem toho udelal moc, ale malo toho nebylo.

Za zminku stoji:
- odstranena kolekce queries,
- vytvorena nova kolekce users,
- do kolekce users se jiz ukladaji a mazou uzivatelske dotazy,
- jsou dve globalni role - admin/user
- pro pristup do hawata musi mit uzivatel roli user, jinak je odpalkovan na stranku, kde je informovan o nutnosti aktivace/validace uctu (pokud zaznam v konfiguraci neexistuje, neni povinnost mit roli pro pristup do hawata):

    "acl": {
        "base_role": "user",
...

- url acl jsou pripravena tak, ze pokud definujeme v konfiguraci nasledujici, pak je nutne mit danou roli. Nemaji-li uzivatel, je presmerovan na stranku "permission denied".

        "acl_url": {
            #"/dashboard": "admin" 
            #"/alerts": "admin" 
            #"/alerts/deleteQuery": "admin" 
            #"/alerts/getAlertsData": "admin" 
        }

- udelal jsem obrovskou cistku v kodu jednotlivych kontroleru, ale to neni hmatatelne, takze to jen zminuji.

Snad "nejaky" kod staci:(

S Mekem se domluvim, jak budeme udrzovat aktualni databaze - kolekce users, groups (zatim nenexistuje) na produkci a v testovacim prostredi.

R.

base_role a pravé strany v acl_url.* můžou být pole (jako ["admin", "user"]), nebo se očekávají singlevalues?

Tenhle "nějaký" kód začíná vypadat slibně. Počítám tedy s úterkem.

• práva
  • admin - může pouze definovat managery, ne usery, nemůže čerpat práva skupiny
  • manager - může pouze definovat usery ve své skupině, nikoli čerpat práva skupiny
  • user - může čerpat práva skupiny
• odstraňovat referenci po smazání (člověka ze skupiny, skupiny apod.)
• neukazovat křížek, kde nemám právo mazat
• pro každou skupinu box
• hláška "query přidáno do skupiny" - flash zpráva do stashe, standardní featura catalystu
  • zkontrolovat, zda nejsou takové další hlášky
• jméno query unikátní v rámci boxu (skupiny nebo uživatele) přes simple i advanced; nejlépe použít rovnou _id; nedovolit duplicitní jméno s hláškou (flash zpráva)
• zrušíme user.username a group.name, stačí user._id a group._id

Popis práce s flash messages:

V souboru www/hawat/root/lib/site/layout jsou definovány kontejnery pro zobrazování flash zpráv. Pro jejich použití stačí v libovolném controlleru přidat do stashe požadovanou zprávu a catalyst to už sám vykreslí:

$c->stash(data => $data,
          msg_info => "Info message",
          msg_success => "Success message",
          msg_warning => "Warning message",
          msg_error => "Error message",
    );

Alternativně lze nastavit hodnotu přímo v libovolné šabloně:

[% msg_info = "Info message" %]
[% msg_success = "Success message" %]
[% msg_warning = "Warning message" %]
[% msg_error = "Error message" %]

Styly DIVů jsou zatím jen nastřelené a také je možné zobrazit pouze jednu zprávu daného typu, přiřazení jiné zprávy dále v kódu původní přepíše, ale to podle mě zatím nevadí.