On Tuesday, March 5, 2013 2:00:14 PM UTC+2, Javier Domingo wrote: > > So, IMHO following Leho's opinion, the best implementation would be > converting trac in a django app, that allows the plugin-ing into it, > without modifying it. > > In that way, a client would just create a new django project, activate > the trac app, and download/install the plugins as other django apps > that would interact with the original one using the ExtensionPoints. > > Now, the only problem it comes to my mind is: How to manage > permissions? If you realize, a lot of people (if not nearly everyone) > is using the AccountManagerPlugin. So going Django would mean using > its permission system, along with their authentication system, which > can be totally customized (I love the way trac handles authn) > > I think that going django would mean a complete remake of trac, but > would simplify a lot trac deployment (in for example appengine), and > would allow users to integrate it completely with their python web > pages. >
That's a pretty good wrap-up. Yes, everybody's favorite, the good old user model question comes up now :) #2456 https://docs.djangoproject.com/en/1.5/releases/1.5/#configurable-user-model is something that caught my eye in last month's Django's release notes. I so far think it's a feasible idea to replicate the permission system, so it would appear the same. Perhaps some customizable ACL system already exists for Django. AFAICT, whatever the implementation, on surface all reasonable permission systems end up looking pretty similar i.e. some kind of a list of named capabilities. -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/trac-dev?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
