@ngld:
I kept reading advanced doc for Symfony. Going back to the drawing board with the whole Nebula security implementation (again, but this time not juste teams. The whole security !).
I really have to stop thinking of Nebula as a "small" project. I have made some implementation choices (security, but not only that part, also some database management) because I read some things (namely Symfony default ACL, and Symfony paginator) would be overkill for a "small" project. Now I figure it's not, because we actually need features like administration granularity...
Our talk about Nebula admin helped a lot !
1) I'm going to drop our custom security voters (I always planned to rewrite this part anyway, because it lead to some terrible variable naming in some of the html templates), replace it with standard ACL, and enable an early version of admin access to mods. Creating the admin panel will be much easier once it's done.
2) Going back to
http://www.hard-light.net/forums/index.php?topic=86364.msg1768398#msg1768398 , I'm keeping the special "attributes" class I was writing to store data about a relation between a modder and a team, but instead of writing a custom ACL, I will use the standard ACL system so Nebula will have a single big authorization system.
(at first, I thought this would add complexity, but when I drop the voters, it will get much more simple)
Dropping custom security voter classes is also important because Symfony devs will make deep changes starting with Sf 2.6 that may completely break our security system. ACL won't change any time soon.
Less custom, more standard code will also make my code more readable to any other Symfony dev, in case someone wants to contribute.
EDIT : Good news ! It's working (already rewritten the "mod owning" part... Still have to do the branches and builds...).
Bad news : database reset coming (we can keep mods created with the old voter system, but their owners will be unable to make changes).
EDIT 2 : Since I'm changing a lot of things in the db, I'll simplify a few more things to play better with the new security system:
- No more FSMod, Team objects ! Team + Owner interface (the "repository") + FSMod will become a unified object, some kind of "work group".
- Users will own the work groups in a standard many-to-many relation, permissions will be managed through the ACL system.
- Aggregated fields (mod, branch, build counters) will be handled with more efficiency through the work groups.
---> For users, it means they won't have to worry about team management : they create a mod, and if they need to give rights on this mod to other users, they can do it through the mod admin page. Every mod will retain a "team" page, showing the current authorized members.
---> For me, that means : better top level templates and better top level controllers (no need to check if a mod is owned by a user or by a team), less duplicated code (no need to handle mod owning in team objects), easier checks when an object (user, mod) is created...
It's actually close to making teamwork a "default" on Nebula.
These changes will have no impact on the lower structure (build content).
EDIT 3 : This refactoring will go even deeper, with a better build validator abstraction !
Currently, I use a service to query knossos-server api from Controllers. The Controllers then 1) read the answer, 2) compare with the database, and 3) take appropriate action.
After the new changes, the "read the answer" and "compare with the database" steps will be included in the service, so the Controllers will only need to send the right page depending on the aggregated answer.
This will lower the risk of redirection bugs in Nebula build validation pages (in other words, I will be able to understand my own redirection code, which is currently barely the case, because it's a nested conditions hell).
