Re: [GSoC 2013] contribute to django-deployer for deploying django to PaaS easily
On Thursday, May 2, 2013 4:11:35 AM UTC-4, Andrew Godwin wrote: > > I feel like the deployment problem is one that cannot be solved in a mere > 12 weeks and I'm not sure django-deployer is the right approach to > encourage for this - it sits at the wrong level of abstraction and looks > pretty fragile, and I'd be hesitant to put any sort of official emphasis on > it without a lot of my qualms being answered. > Could you elaborate on what your qualms are? I won't claim that it's a work of art and I know there is lots of room for improvement, but please remember that django-deployer is the result of two days of work, and it already deploys Django projects to Dotcloud and Google App Engine with almost minimal effort on the part of the user. Imagine what we can do in 12 weeks! > In particular, it appears to be sitting at the lowest-common-denominator > level of the various feature sets and looks pretty immature. > The initial goal of django-deployer was to reduce the barrier to entry for someone new to Django who wants to quickly and easily get their Django project running up on one of the PaaS providers. So we started out with a minimum feature set which seems to cover the non-production deployment needs for 80-90% of Django projects. We purposely omitted support for services such as Memcached, Celery, email, cron jobs, etc. because we were trying to limit the scope at the sprint and get a basic version working first. Now that the basic version is working, we can look into adding support for these other services that you'd most likely find in a production environment. I'm not sure I could accept this without a much clearer idea of what's > going to happen and a very clear focus on what section of our user base it > will help. Deployment isn't something there can be a single solution (or > even pattern) for, and I think encouraging that could be a bad idea. > Agreed. We're not attempting to make a one-size-fits-all solution, and django-deployer will never claim to serve that purpose. But for bootstrapping your Django project so that you can minimize the amount of time it takes to try deploying your project to various PaaS providers, and for demonstrating best practices when readying your project to be deployed, I think it has a place in the Django ecosystem. I've looked at all the getting started docs from the various PaaS providers, and many of them leave a lot to be desired. Many developers that I've spoken with who've tried PaaS have thrown up their hands in frustration when things don't work as advertised. This is largely the impetus for starting the django-deployer project, to try to streamline this process for those new to PaaS and Django deployment. Nate > On Wed, May 1, 2013 at 8:20 PM, Nate Aune > > wrote: > >> Hi Russell and Florian, >> >> A bit late to the party, but hopefully there's still time for this GSoC >> proposal to be considered. I'm the maintainer of >> django-deployer<http://natea.github.io/django-deployer/>. >> It was initiated at the DjangoCon 2012 sprint and recently revisited at the >> PyCon 2013 sprint. The overarching goal of django-deployer is to make it >> easier to get Django deployed. So far the focus has been on deploying to >> PaaS providers, because they require little to no sysadmin skills, and have >> the added benefit of being free for small projects. >> >> django-deployer is the sister project PaaS Cheatsheet, a larger >> documentation project that I've started recently. PaaS >> Cheatsheet<http://www.paascheatsheet.com>is a guide for how to get a >> Django/Python deployed on various PaaS >> providers. >> >> The way django-deployer works is by asking a series of questions about >> your Django project, and then generates a generic deploy.yml file that >> captures all of your project's requirements. When you choose a particular >> PaaS provider, django-deployer then translates the requirements defined in >> the deploy.yml file and generates configuration files for that specific >> PaaS provider. >> >> I met Colin (a student in Taiwan) at the PyCon sprint, and he was >> responsible for single-handedly adding Google App Engine support to >> django-deployer. He brought considerable expertise to our sprint team, and >> shipped working code within a matter of hours. Since returning from PyCon, >> we've been working remotely together, and he has continued to be a >> dedicated contributor to the project. I have utmost confidence in his >> abilities to add even more cool features and improve code quality of the >> django-deployer tool if this project is accepted into GS
Re: [GSoC 2013] contribute to django-deployer for deploying django to PaaS easily
On Thursday, May 2, 2013 9:46:52 PM UTC-4, Jacob Kaplan-Moss wrote: > While I share some of Andrew's concerns, I do think this is still a fairly > good topic for GSoC. > Thanks for your vote of confidence! :) We'd love to get your input on how to address Andrew's concerns. We've already started looking into replacing the manage.sh script with Django management commands, so you can deploy using the familiar manage.py (which is something that I think you suggested awhile ago). I made a couple screencasts where you can see the tool in action, in it's current state of infancy: http://appsembler.com/blog/deploy-django-apps-to-google-app-engine-with-django-deployer-in-5-minutes/ http://appsembler.com/blog/deploy-django-apps-to-dotcloud-with-django-deployer-in-5-minutes/ > However, I think the only way it could happen would be if Nate wants > to mentor the project; Nate, can you mentor? Yes! As I mentioned in my last post, I'm happy to serve as a GSoC mentor. I will do my best to provide guidance to Colin as we continue to shape django-deployer to be a useful tool for the Django community. > If so, you should hook up with Andrew and make sure you apply to be a > mentor so we can have you > added before the review process. > I added my name to the wiki, and also signed up on the GSoC site here: http://www.google-melange.com/gsoc/connection/google/gsoc2013/nateaune/1 Nate On Thu, May 2, 2013 at 4:11 AM, Andrew Godwin > > wrote: > > I feel like the deployment problem is one that cannot be solved in a > mere 12 > > weeks and I'm not sure django-deployer is the right approach to > encourage > > for this - it sits at the wrong level of abstraction and looks pretty > > fragile, and I'd be hesitant to put any sort of official emphasis on it > > without a lot of my qualms being answered. In particular, it appears to > be > > sitting at the lowest-common-denominator level of the various feature > sets > > and looks pretty immature. > > > > I'm not sure I could accept this without a much clearer idea of what's > going > > to happen and a very clear focus on what section of our user base it > will > > help. Deployment isn't something there can be a single solution (or even > > pattern) for, and I think encouraging that could be a bad idea. > > > > Andrew > > > > > > On Wed, May 1, 2013 at 8:20 PM, Nate Aune > > wrote: > >> > >> Hi Russell and Florian, > >> > >> A bit late to the party, but hopefully there's still time for this GSoC > >> proposal to be considered. I'm the maintainer of django-deployer. It > was > >> initiated at the DjangoCon 2012 sprint and recently revisited at the > PyCon > >> 2013 sprint. The overarching goal of django-deployer is to make it > easier to > >> get Django deployed. So far the focus has been on deploying to PaaS > >> providers, because they require little to no sysadmin skills, and have > the > >> added benefit of being free for small projects. > >> > >> django-deployer is the sister project PaaS Cheatsheet, a larger > >> documentation project that I've started recently. PaaS Cheatsheet is a > guide > >> for how to get a Django/Python deployed on various PaaS providers. > >> > >> The way django-deployer works is by asking a series of questions about > >> your Django project, and then generates a generic deploy.yml file that > >> captures all of your project's requirements. When you choose a > particular > >> PaaS provider, django-deployer then translates the requirements defined > in > >> the deploy.yml file and generates configuration files for that specific > PaaS > >> provider. > >> > >> I met Colin (a student in Taiwan) at the PyCon sprint, and he was > >> responsible for single-handedly adding Google App Engine support to > >> django-deployer. He brought considerable expertise to our sprint team, > and > >> shipped working code within a matter of hours. Since returning from > PyCon, > >> we've been working remotely together, and he has continued to be a > dedicated > >> contributor to the project. I have utmost confidence in his abilities > to add > >> even more cool features and improve code quality of the django-deployer > tool > >> if this project is accepted into GSoC. > >> > >> English is a second language for Colin, so he may have had some > >> difficulties in defending his proposal, so please allow me to step in
Re: [GSoC 2013] contribute to django-deployer for deploying django to PaaS easily
y the commonalities among them. >* Regarding storage stuff, you say "I chose Google Cloud Storage according to the networking speed and authorization flow will be easier than using other >storage service such as S3.". Personally I don't think it's wise to choose the easier storage (network speed should be no concern here anyways), your API >should be able to allow to hook in the more complex authorization flow too, what would be a better way to test your API than using S3 :) I agree. It should be possible for the user to specify S3 as a storage for static assets. But I think Colin does have a point that if you're already going with Google App Engine, it makes sense to stick with other Google technologies for the storage of the assets. Obviously, if you're using Heroku you'd use S3 for that. >All in all this proposal imo tries to address way to much and focuses to much on Google. It would be more useful to lay the groundwork for an API instead. That >said, did you get in contact with the project authors about mentorship (eg are they interested and do have the time for it), I am pretty sure none of the core devs >uses django-deployer, so mentoring it would be a bit suboptimal. I agree that Colin's draft proposal was too focused on Google, but I think that's simply because that is what he is most familiar with. As his mentor, I would guide him to adding support for the other providers (Heroku, OpenShift, Gondor, etc.) as we have already done for Dotcloud and Stackato. Judging from all the Django deployment talks at meetups around the country, it's fairly evident that deployment is and continues to be a hot topic, one that is often a stumbling block for people new to Django. I think Django would benefit greatly from tools such as django-deployer that minimize the friction, and give people an easy path to painless deployments. Nate > > On Sunday, April 21, 2013, LittleQ@NCCU, Taiwan wrote: > >> to django-developers: >> >> Sorry, I use Google Drive for proposing, and I original tend to >> copy&paste it to here but found it will get in a mess. >> >> so I put my proposal here: >> http://goo.gl/xJyJ9 >> >> My idea is to contribute to django-deployer and make some significant >> improvements for it. >> This proposal is still editing, but I pre-post it to prevent I'm thinking >> it in the wrong way. >> >> any questions or any advise are welcome, thank you, I'm really a big >> Django fan, and I hope I can make it better. >> >> cuz seems like there's no #django-dev, so feel free to add my XMPP >> directly. >> >> it's open for messaging anytime :D >> >> >> - Colin Su >> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to django-developers+unsubscr...@googlegroups.com. >> To post to this group, send email to django-developers@googlegroups.com. >> Visit this group at >> http://groups.google.com/group/django-developers?hl=en. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Complex aggregate and expression composition.
> I took a quick look at your patch. I don't have more time now, so just
> some quick comments:
> [...]
I think the approach you have taken is correct in general. I would
> encourage to check
> if you can somewhat easily incorporate the conditional aggregate support
> (#11305)
> into the ExpressionNode based aggreagates. It does not belong into the same
> patch, but is a good sanity check if the approach taken is extensible.
>
Thanks for taking a look! Sorry it took me so long to get back to you,
I've been quite
busy lately. I finally had two hours to rub together to try your
suggestion; I set up a
branch ( https://github.com/NateBragg/django/tree/11305 ) that implements
this
behavior using (more or less) your approach.
The difference can be found here:
https://github.com/natebragg/django/compare/natebragg:14030...natebragg:11305
I also wanted to thank you on another count, as parts of your 11305 approach
served as a launching point for my work - and even gave me a good solution
for
one of the problems I listed in my original email (regarding join
promotion), that
I have since incorporated it onto the 14030 branch.
- I am a bit scared of the type coercions. The reason is that this could
> prove to be
>hopelessly complex to get right in every case. However, I do not have
> concrete
>examples where this is in fact a problem. The default should probably
> not be an exception,
>but just returning what the database happens to give you back.
>
It could be quite complex, I agree, but it doesn't have to be. I based it
off of the
preexisting concept that Aggregates needed to know about their field types,
and whether or not they were ordinal or computed aggregate types.
So, in general what I need is other folks trying this, finding problems, or
taking
issue with my proposal. It might not be quite as exciting as user.auth,
but I
think refactoring like this needs review and feedback. I'd really love to
propose
this for inclusion, so that others could benefit from this.
As it's a couple weeks old, in case you missed my original email, I've
included it below.
Thanks,
Nate
___
> From: django-developers@googlegroups.com [
> django-developers@googlegroups.com] On Behalf Of Nate Bragg [
> jonathan.br...@alum.rpi.edu]
> Sent: Wednesday, March 21, 2012 01:27
> To: django-developers@googlegroups.com
> Subject: Complex aggregate and expression composition.
>
> Hello all,
>
> Since even before I saw Alex Gaynor's presentation "I hate the Django ORM"
> (the one with the `Sum(F("end_time") - F("start_time"))` query), the
> problem
> of complex aggregates and expressions has vexed me. So, I figured I would
> try to solve it.
>
> Originally, I started this trying to pursue a solution to ticket #14030,
> but after
> I took a couple of lousy shots at it, it dawned on me that the ticket
> would be
> better resolved as a result of solving the more general case. I realized
> that
> aggregates were just a special case of expressions, and that the best
> solution
> was going to take a refactoring of Aggregate into ExpressionNode.
>
> I have uploaded my branch; it can be found here:
>
> https://github.com/NateBragg/django/tree/14030
>
> Since this is a non-trivial change, I was hoping to open the topic for
> debate
> here, and get some feedback before proposing my solution for inclusion.
>
> Some particular points of note:
> * I tried to preserve as much interface as possible; I didn't know how much
> was considered to be more public, so generally I tried to add rather than
> subtract. However, I did remove a couple things - if you see something
> missing that shouldn't be, let me know.
> * Currently, I'm getting the entire test suite passed on sqlite, oracle,
> mysql,
> postgres, and postgis. I was unable to test on oracle spatial - any help
> with that would be appreciated.
> * When fields are combined, they are coerced to a common type;
> IntegerFields are coerced to FloatFields, which are coerced into
> DecimalFields as needed. Any other kinds of combinations must be of
> the same types. Also, when coerced to a DecimalField, the precision
> is limited by the original DecimalField. If this is not correct, or other
> coercions should be added, I'd like to correct that.
> * When joins are required, they tend to be LEFT OUTER; I'd like some
> feedback on this, as I'm not 100% sure its always the best behavior.
> * As the aggregates are a little more complicated, on trivial cases there
> is a minor reduction in performance; using djangobench, I measured
> somewhere between a 3% and 8% increase in runtime.
> * I don't have enough tests - mostly for
Re: Allow changing form field properties after form creation
They don't "have" to be replaced in a subclass in the way you showed.
Perhaps it isn't perfectly DRY, but whats so bad about naming the field
explicitly? Anyhow, when it comes specifically to widgets, the Meta
class already has a 'widgets' attribute already that lets you specify that.
I would sooner have "smart" Meta class attributes to perform this
behavior declaratively than to have to do it at the __init__ level:
class Meta:
title__required = False
programs__help_text = 'Hold down Ctrl to select multiple options'
authors__required = False
confidential__widget = AdminYesNoWidget
uploader__required = False
file__widget = AdminFileWidgetWithSize
... and I don't like *that* particularly either.
Cheers,
Nate
On Thu, Apr 5, 2012 at 7:49 AM, Chris Wilson wrote:
> Hi all,
>
> I've added this as a ticket but I wanted to make sure that the core and
> forms developers have a chance to see and interact with it, so I'm posting
> it here too. You can find the ticket at: <
> https://code.djangoproject.com/ticket/18064>
>
> Currently, if I want to tweak the properties of some fields in a
> ModelForm, I have to replace them in the subclass like this:
>
> {{{
> class DocumentForm(ModelForm):
>title =
> models.Document._meta.get_field('title').formfield(required=False)
>programs =
> models.Document._meta.get_field('programs').formfield(required=False)
>authors =
> models.Document._meta.get_field('authors').formfield(required=False)
>confidential =
> models.Document._meta.get_field('confidential').formfield(widget=AdminYesNoWidget)
>uploader =
> models.Document._meta.get_field('uploader').formfield(required=False)
>file =
> models.Document._meta.get_field('file').formfield(widget=AdminFileWidgetWithSize)
> }}}
>
> This is very bulky to just change some properties. The problem is that the
> field copies some of its properties into weird places like the widget
> during initialisation:
>
> {{{
> class Field(object):
>...
>def __init__(...)
>...
>if help_text is None:
>self.help_text = u''
>else:
>self.help_text = smart_unicode(help_text)
>widget = widget or self.widget
>if isinstance(widget, type):
>widget = widget()
>
># Trigger the localization machinery if needed.
>self.localize = localize
>if self.localize:
>widget.is_localized = True
>
># Let the widget know whether it should display as required.
>widget.is_required = self.required
>
># Hook into self.widget_attrs() for any Field-specific HTML
> attributes.
>extra_attrs = self.widget_attrs(widget)
>if extra_attrs:
>widget.attrs.update(extra_attrs)
>
>self.widget = widget
> }}}
>
> If we refactored this so that all the property initialisation was done in
> setters, then we could just write:
>
> {{{
> class DocumentForm(ModelForm):
>def __init__(...)
>self['title'].required = False
>self['programs'].help_text = 'Hold down Ctrl to select multiple
> options'
>self['authors'].required = False
>self['confidential'].widget = AdminYesNoWidget
>self['uploader'].required = False
>self['file'].widget = AdminFileWidgetWithSize
> }}}
>
> Which is more concise, much clearer, and does not override things
> unnecessarily.
>
> I can write the code, but first I want to:
>
> * see if any core developers object, to avoid wasting effort
> * know how to run the Django tests and which suite(s) I should be running
> * know where to put the tests.
>
> Cheers, Chris.
> --
> Aptivate | http://www.aptivate.org | Phone: +44 1223 967 838
> Future Business, Cam City FC, Milton Rd, Cambridge, CB4 1UY, UK
>
> Aptivate is a not-for-profit company registered in England and Wales
> with company number 04980791.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Complex aggregate and expression composition.
Hello all,
Since even before I saw Alex Gaynor's presentation "I hate the Django ORM"
(the one with the `Sum(F("end_time") - F("start_time"))` query), the problem
of complex aggregates and expressions has vexed me. So, I figured I would
try to solve it.
Originally, I started this trying to pursue a solution to ticket #14030,
but after
I took a couple of lousy shots at it, it dawned on me that the ticket would
be
better resolved as a result of solving the more general case. I realized
that
aggregates were just a special case of expressions, and that the best
solution
was going to take a refactoring of Aggregate into ExpressionNode.
I have uploaded my branch; it can be found here:
https://github.com/NateBragg/django/tree/14030
Since this is a non-trivial change, I was hoping to open the topic for
debate
here, and get some feedback before proposing my solution for inclusion.
Some particular points of note:
* I tried to preserve as much interface as possible; I didn't know how much
was considered to be more public, so generally I tried to add rather than
subtract. However, I did remove a couple things - if you see something
missing that shouldn't be, let me know.
* Currently, I'm getting the entire test suite passed on sqlite, oracle,
mysql,
postgres, and postgis. I was unable to test on oracle spatial - any help
with that would be appreciated.
* When fields are combined, they are coerced to a common type;
IntegerFields are coerced to FloatFields, which are coerced into
DecimalFields as needed. Any other kinds of combinations must be of
the same types. Also, when coerced to a DecimalField, the precision
is limited by the original DecimalField. If this is not correct, or other
coercions should be added, I'd like to correct that.
* When joins are required, they tend to be LEFT OUTER; I'd like some
feedback on this, as I'm not 100% sure its always the best behavior.
* As the aggregates are a little more complicated, on trivial cases there
is a minor reduction in performance; using djangobench, I measured
somewhere between a 3% and 8% increase in runtime.
* I don't have enough tests - mostly for a lack of creativity. What kind of
composed aggregates and expressions would you like to see? I'll add
tests for them.
Thank you all, and sorry for the above being a short book.
-- Nate Bragg
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Tips required to run django tests configurazion for all databases
On Sat, Mar 17, 2012 at 5:33 AM, Simone Federici wrote: > oracle and postgresql have the similar performance during the tests, > > but mysql... there is some tricks to go faster the mysql suite test case? > I recently encountered this as well; for me, it was because I was using MyISAM as the backend - switching to InnoDB saw about an 8x speedup, to become comparable to postgres (it took over four hours to run under MyISAM, for reference). Which backend are you using? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Sporadic proxy deletion failures on mysql
Hello all, When running regressiontests.delete_regress.tests.ProxyDeleteTest and regressiontests.delete_regress.tests.ProxyOfProxyDeleteTest on mysql, sporadic IntegrityErrors would occur. This was caused by the proxy model's base model not having the proxy model as a dependency, and the sporadic nature was entirely the result of dictionary ordering going into Collector.sort() - sometimes it would be in an order that honored the constraints, sometimes it wouldn't. This was introduced, I believe, in revision 17664. I have only observed it on mysql, but it is hypothetically a universal issue. My proposed solution is simply to ensure that the proxy model's base class gets included as a dependency. I have created a ticket, https://code.djangoproject.com/ticket/17918 , and set the severity to "Release blocker", as well as supplied a patch that resolved the issue for me. If this issue is not a release blocker, or my patch is insufficient, please let me know. Regards, Nate -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Triage and Reviewing
After contributing the solution to a small problem (#17492), I was inspired to look for other tickets that I would be able to help on, either by triaging un-reviewed tickets (#17537, #17561, #17573), supplying new patches (#14030*, #16735, #17186), or reviewing patches (#11305, #16955, #17541) *rebased out of the patch to #11305 I would very much appreciate if someone would be willing to take a look at those tickets, and give me constructive feedback. If I can be more helpful by doing something different, I want to know. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Advanced Permissions
Hello. My name is Nate. Myself and my friend Marco would like to upgrade django permissions. We would like to brainstorm here first to make sure that we design something that fits with django. If there are any other discussions about upgrading django permissions, kindly point me to them. We have already some of the permissions threads on django-dev, but we thought that it would be best to make a new thread for our proposal. We are aware of the fact that django 1.2 added some hooks for row- level permissions, but this proposal covers an even broader scope. # The Proposal # In a nutshell, we would like to add a PermissionManager to django. It will be similar in concept to the 'objects' queryset Manager that already exists on models. Each model will have a default PermissionManager attached. People can override this PermissionManager with their own PermissionManager to change the permissions for a particular model. The default PermissionManager works like the current permissions system: it checks all of the Backends to see if the user has the given permission. (This, in turn, checks the records of auth.Permission by default.) The simplest use case of the PermissionManager is overriding it to add new permissions, equivalent to setting the Meta.permissions attribute. For example: class Poll(models.Model): permissions = PermissionManagerWith(vote='Can Vote') ... Note that PermissionManagerWith would be a factory function to create a new PermissionManager class with a vote permission. More on this later. Unlike the current system, PermissionManagers make a distinction between two types of permissions: object-level (row-level) and model- level permissions. Model-level permissions are similar to the current permissions that django has, while object-level permissions add more fine-grained control. ## Model Level Permissions ## Each PermissionManager has an 'allows_PERM' classmethod for each model- level permission. For example, a PermissionManager with the model- level permissions 'add', 'remove', and 'edit' will have the functions 'allows_add', 'allows_remove', and 'allows_edit'. These functions take a User object as a parameter and return a boolean as to whether or not the user has the given permission. So, for instance, a user could do the following: if not Poll.permissions.allows_vote(user): raise PermissionError By default, this will check all of the authentication Backends to see if the user has the given permission. Users could, of course, extend PermissionManager and override this behavior to use other methods of checking the permissions. Note, however, that these functions are defined on a Class level. Users overriding these functions can not do any computation concerning a model instance, only a model class. This does not allow people to do things like restrict edits to only models that the editor created. For that, you need object-level permissions. ## Object Level Permissions ## Each PermissionManager has a 'PERM_list' classmethod for each object- level permission. For example, a PermissionManager with the object- level permissions of 'remove' and 'edit' will have the functions 'remove_list' and 'edit_list'. These functions take a User object as a parameter and returns a queryset of all the objects for which the user has the specified permissions. So, for instance, you might see something like this in contrib.admin: queryset = Book.permissions.edit_list(user) By default, this is either all of the objects or none of the objects, depending upon the authentication backends. However, this is what is overridden to get more fine-grained permission control. For example, consider the following: class BookPermissionManager(PermissionManager): def edit_list(self, user): return super(BookPermissionManager, self).edit_list(user).filter(author=user) class Book(models.Model): author = models.ForeignKey(User) permissions = BookPermissionManager ... This is an example of using PermissionManagers to only allow users to edit books that they themselves authored. Note that this proposed permissions system does not require that we add any tracking or meta- data to the database. If users would like to base permissions on the meta-data of objects, then they need to store such meta-data themselves. This permissions system will by default use only the existing auth.Permission system for permissions. For symmetry and ease of use, each PermissionManager instance has an 'allows_PERM' method for each object-level permission. The default implementation of allows_PERM is this: def allows_PERM(user): return self.model in self.PERM_list(user) and it is strongly recommended that allows_PERM not be overridden for object-level permissions, because changes in allows_PERM will not be reflected in PERM_list. ### Adding Permis
Re: Enhanced URL Resolver Match
If I'm not mistaken, this sort of lazy url reversing could make it possible to reverse URLs in settings, which has effect upon issues such as the following: http://groups.google.com/group/django-developers/browse_thread/thread/fa3661888716f940 Is that correct? On Jul 11, 11:02 am, Nowell Strite wrote: > Sounds great Russ. I have created a ticket for this > issue:http://code.djangoproject.com/ticket/13922 > > Once you do a tear-down, and if things look good, let me know and I'll > start taking a stab at documentation. > > Thanks! > Nowell > > On Jul 10, 4:35 am, Russell Keith-Magee > wrote: > > > > > On Fri, Jul 9, 2010 at 1:50 PM, Nowell Strite wrote: > > > When Django 1.1 was released URLs gained the ability to be nested with > > > namespaces by adding "app_name" and "namespace" attributes to the > > > include(...) functions within urls.py. The reverse(...) function was > > > updated to allow you to specify namespace and current_app when > > > resolving URLs, however, we never brought the resolve(...) function up > > > to speed to include the relevant namespace and app_name data of the > > > resolved URL. I have taken an initial stab with code and tests (minus > > > documentation, until this feature is completed and agreed upon by the > > > community). > > > > In order to achieve this I have graduated the result of the > > > resolve(...) method to be a ResolverMatch class as opposed to the old > > > tuple(func, args, kwargs). I have also implemented this feature to > > > provides backwards compatibility for the old "func, args, kwargs = > > > resolve(...)" so this feature should hopefully be completely backwards > > > compatible. The new ResolverMatch class provides access to all > > > attributes of the resolved URL match such as (url_name, app_name, > > > namespace, func, args, kwargs). > > > > Please take a look and let me know what you think of the direction and > > > implementation: > > > >http://github.com/nowells/django/compare/master...resolver-match > > > I'll need to do a detailed teardown before I commit, but on a first > > inspection, this looks pretty good to me. > > > If there isn't a ticket for this already, could you please open one > > and include a reference to your github branch (and/or upload the > > patch). Once there are some docs, I'm happy for this to be RFC for > > 1.3. > > > Yours, > > Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Upcoming changes to the Django admin
On Sun, Feb 25, 2007 at 12:51:56AM -0600, Jacob Kaplan-Moss wrote:
> Finally, the URLconf. For the default case (a single admin)::
>
> ('^admin/', include(admin.site.urls()))
>
> And for multiple admins::
>
> ('^admin/', include(admin.site.urls()))
> ('^admin2/', include(second_admin_site.urls()))
Is there going to be any facility for defining additional admin views
besides the current add, change, and delete?
Nate
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: specifying newforms-admin options
On Sun, Jan 21, 2007 at 12:24:54PM -0600, Adrian Holovaty wrote:
> On 1/20/07, Honza Kr?l <[EMAIL PROTECTED]> wrote:
> > why not create a function to do that for you..
> > urls.py is after all a python module, so you could just introduce a function
> >
> > urlpatterns = admin_urls_for_model(
> > MyModel,
> > field_list=[ 'field' ],
> > exclude_actions=[ admin.EDIT ],
> > perms_required={
> > admin.EDIT : 'can_change_MyModel',
> > admin.LIST : 'something_else'
> > }
> > )
>
> I must not have explained this correctly. In the newforms-admin
> branch, all of those options are specified in a class, ModelAdmin. The
> goal here is to figure out how those classes interact with the
> URLconf. There's no need to pass dictionaries around -- all of that
> configuration is in the class.
>
> Something like this is what I had in mind:
>
> """
> from myapp.models import PollAdmin, ChoiceAdmin
>
> urlpatterns = patterns('',
> (r'^admin/', include('django.contrib.admin.urls'), {'models':
> (PollAdmin, ChoiceAdmin)})
> )
> """
>
> The problem here is that each time you add an admin interface to a
> model, you have to remember to add it to your URLconf. Maybe there can
> be a helper function that looks for all Admin classes, as long as you
> save them in a file called admin.py within the app, but that's kind of
> magic.
What if we made the admin app scan all installed applications in its
urls.py file for admin classes in models or admin modules?
Currently we have this in django.contrib.admin.urls:
# Model-specific admin pages.
('^([^/]+)/([^/]+)/(?:(.+)/)?$',
'django.contrib.admin.views.main.model_admin_view'),
This pulls us out of urlconf into a view to decide what the real view
is. Instead we could continue adding to urlpatterns for any admin
classes we find.
# This is pseudo-python
def find_admin_urlpatterns:
for app in settings.INSTALLED_APPS:
if app.admin:
urlpatterns += app.admin.urlpatterns
else:
for model in app.models:
if model.Admin:
urlpatterns += model.Admin.urlpatterns
With this method we could support the old style of Admin class in
models and whatever new way we want for extending the ModelAdmin class
using admin.py in each app.
Nate
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Why does the admin app tie directly to models?
On Thu, Jan 25, 2007 at 06:21:21PM -0600, Adrian Holovaty wrote:
> On 1/24/07, Nate Straz <[EMAIL PROTECTED]> wrote:
> > What if the admin app was really an admin framework inside Django? It
> > could provide a base admin sub-app that applications could extend. That
> > would allow apps to easily add new views to the admin app.
>
> I think you'd find the newforms-admin branch very interesting:
>
> http://code.djangoproject.com/wiki/NewformsAdminBranch
Yup, I've been following the branch to some extent. This part:
96 class ModelAdmin(object):
...
117 def __call__(self, request, url):
...
130 # Delegate to the appropriate method, based on the URL.
131 if url is None:
132 return self.changelist_view(request)
133 elif url.endswith('add'):
134 return self.add_view(request)
135 elif url.endswith('history'):
136 return self.history_view(request, unquote(url[:-8]))
just screams to me that it should use urlconf.
Nate
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Why does the admin app tie directly to models?
On Tue, Jan 23, 2007 at 11:47:08PM -0600, Jacob Kaplan-Moss wrote:
> On 1/23/07 9:16 PM, Nate Straz wrote:
> > Why does the admin app tie directly to models? Why not applications?
>
> Because sometimes you want certain models within in app *not* to be
> admin-editable.
Okay, there's a clue that sometimes customization is needed. I'll
continue expanding on my idea.
What if the admin app was really an admin framework inside Django? It
could provide a base admin sub-app that applications could extend. That
would allow apps to easily add new views to the admin app.
I think it would plug into the urls.py in django.contrib.admin like
this:
('^([^/]+)/(?:(.+)/)?$', 'django.contrib.admin.views.main.app_admin')
def app_admin(request, app_label, rest_of_url):
# import admin urlpatterns from app
# continue resolving url with new patterns
Inside app/admin.py:
from django.contrib.admin import AdminApp
from app.models import Foo, Bar
myadminapp = AdminApp(models = (Foo, Bar))
urlpatterns = myadminapp.patterns()
How does that sound for a new direction?
Nate
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Why does the admin app tie directly to models?
Why does the admin app tie directly to models? Why not applications? Nate --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: App portability
On Fri, Sep 08, 2006 at 03:18:22AM +0200, Daniel Poelzleithner wrote: > in myapps/views.py: > from .models import Somemodel > > which will import from myapps/models.py Somemodel > > from ..otherapp.models import Othermodel > > imports from myapps/../otherapp/models.py -> otherapps/models.py > > This is exactly what we need for our apps to be portable :) Wow, I never knew about that syntax. I checked the Language Reference all the way back to the 1.5 release and it is in every release. I'm surprised I've never seen that syntax used before. Thank you for pointing that out. Nate --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
