Riassumendo, se ho ben capito, vorresti:
- aggiungere una voce di menu in admin
- fare in modo che cliccandola apra un contenuto custom
- aggiungere dei controlli fissi fatti dal plugin che eseguono delle verifiche sui dati.
Partendo dall'idea che l'ultimo punto è ok, per i primi due consiglierei di creare un modulo docebo a cui, nel caso, far richiamare delle parti di php già pronte.
Modulo se lavori su una 3.6.0, sulla 4 i moduli sono ancora supportati per retrocompatibilità ma tutto è stato riconcepito in un ottica di MVC, la cui struttura è diversa da quella dei moduli.
Procediamo per step, un modulo admin di docebo ha bisogno 4 cose per funzionare, poniamo di volerlo posisionare sotto Principale > Configurazioni.
1. creiamo una riga in core_menu_under con idMenu pari all'id menu che vuogliamo in core_menu e indichiamo tutti i parametri.
INSERT INTO `core_menu_under` (
`idUnder`,
`idMenu`,
`module_name`, // nome del modulo, deve corrispondere alla cartella che verrà creata in 2
`default_name`, // nome da far comparire nel menu, è una chiave di lingua
`default_op`, // op di partenza del modulo
`associated_token`, // token per la costruzione del permesso da verificare per decidere se far apparire o meno la voce di menu, solitamente è view
`of_platform`, // poco usato, serve per mdouli cross platform, null è la norma
`sequence`, // sequenza in cui mostrarlo
`class_file`, // nome del file descrittore del modulo in doceboCore/class.module/
`class_name`, // nome della classe del descrittore del modulo in doceboCore/class.module/
`mvc_path` // questo c'è solo per la 4 e sostituisce, per gli mvc, buona parte dei parametri precedenti
) VALUES
(NULL, 3, 'configuration', '_CONFIGURATION', 'show', 'view', NULL, 1, 'class.configuration.php', 'Module_Configuration', '');
2. creiamo una cartella in doceboCore/modules/ con il nome che vogliamo date al nostro modulo e un file php all'interno con lo stesso nome
3. creiamo la classe descrtittore del modulo in doceboCore/class.module/ seguendo l'esempio degli altri file che troviamo nella cartella, qui definiamo come chiamare la funzione di dispatch, si può aprtire da un altro file rinominando solo il necessario per velocità.
4. aggiungiamo alla RACL il nuovo permesso per permettere ai superadmin di vedere il modulo e lo assegniamo al ruolo dei superadmin
La parte difficile finora dovrebbe essere la 4, dato che richiede di conoscere le dinamiche della racl di docebo, procedendo per step si deve.
4.1 creare un id in core_st
INSERT INTO core_st (idst) VALUES(NULL);
4.2 creare un permesso in core_role corrispondente al nostro modulo, per quelli del core è
INSERT INTO core_role (idst, roleid) VALUES (LAST_INSERT_ID(), '/framework/admin/nomemodulo/view');
4.3 ora che il permesso è pronto va assegnato al giusto ruolo, reperibile in core_group, tramite la tabella core_role_members
recuperiamo l'id di /framework/level/godadmin
SELECT idst FROM core_group WHERE groupid = '/framework/level/godadmin'
e inseriamo in core_role_members
INSERT INTO core_role_members (`idst`, `idstMember`) VALUES ( idst del ruolo inserito in 4.2 e creato in 4.1, idst recuperato al 4.3 );
A questo punto, dal successivo login avremo la nostra voce di menu e il link al realtivo modulo.
Come è strutturato il file dentro doceboCore/modules/nomemodulo/ ?
Fondamentalmente c'è una funzione di dispatch che distingue cosa fare in base al parametro op, il resto è a discrezione del modulo.
Ad esempio si può guardare coem funziona la funzione : adminManagerDispatch( $op );
Bada però che la 3.6.0.4 ha delle verifiche per il CSRF percui se usi delle form in post dovresti aggiungere il parametro per la verifica della provenienza della richiesta "authentic_request", se usi i metofi della classe Form di docebo viene aggiunto in automatico, cosi come viene aggiunto in automatico alel chiamate ajax, se fai in altro modo devi pensarci tu ad aggiungerlo.
La verifica dei permessi interna al modulo si fa con la funzione checkPerm('view');
La 4 ha tutto un paradigma diverso per quanto riguarda il model view controller (MVC) che non interessa per ora, ma sarà riportato nel wiki developer, inoltre ha un driver principale per quanto riguarda l'0esecuzione delle query che è lo step intermedio prima del multi-dbms on ORM e AR previsto per la 4.1
Oltretutto prevedere anche una parte di layout tramite file di template e dei widget per la gestione degli elementi ripetibili, percui cambiano un pò di cose.
Spero di essere stato esaustivo.
Ciao