Adrian Holovaty wrote:
> On 8/10/06, Jason Huggins <[EMAIL PROTECTED]> wrote:
> > At this point, I'll leave it to the project admins to decide how to
> > procede. But a new "django-announce" Google group sounds like the
> > logicial next step.
>
&g
Jyrki Pulliainen wrote:
> On 8/10/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >
> > For notification what about a low-volume django-announce group /
> > mailing list specifically for disclosures and point version upgrades?
> > This gives something for vendors etc to subscribe to and follow
James Bennett wrote:
> > 3) Is there any sort of policy or promise on how many versions back
> > Django devs are willing to go back and support?
>
> The documentation page Malcolm linked states that patches will be
> developed for the current release and the two releases previous to it.
> That see
Jeremy Dunck wrote:
> True, but Rails had lots of buzz and has -lots- of prod systems. Of
> the 2 people I talked to with prod rails systems, neither had heard of
> this 3 hours after the posting. I only knew because of luck on
> prog.reddit.
Same here, programming.reddit.com is my most hit sit
Malcolm Tredinnick wrote:
> See
> http://www.djangoproject.com/documentation/contributing/#reporting-security-issues
Sorry I didn't read that first before posting here. Though I did a Trac
search for "security" and that page didn't come up in the first few
search results...
Though, looking at th
I'm really feeling for our Rails Core friends... they're getting
blasted right now for not having a complete policy for releasing and
communicating urgent security flaws. I'm not poking fun, this is pretty
serious stuff.
Read here for some of the comments they're getting today via
Reddit.com:
"Ma
peter_k wrote:
> hi jason, i am willing to help but i am not a python expert (yet). that
> being said, if you'd explain how this backend works (especially the
> oracle-related tweaks) we could work on it together.
>
> thanks,
> peter
Peter, I posted some of my explanations to the Django dev lis
peter_k wrote:
> I tried to hack this (http://code.djangoproject.com/ticket/87) older
> oracle backend patch into MR (0.92), but no avail so far. Is there
> someone out there who tried it or has a working version?
Hiya,
I'm the author of the oracle patch. I apologize that I haven't updated
the p
Hey Geoff,
I truly believe we're at a "tipping point" (sorry-- cliched I know, but
it's true) of a time where all the wealth and experience from Zope3
will start to filter down into the other frameworks. Or at the very
least, I'll be stealing some the PAU/PAS stuff when it comes time to
"do LDAP
I, too, hope that Django gets some more modularity for authentication
(LDAP and friends). I recently blogged about how to hack in LDAP
password checking (google for the link). But I emphasize it is a "hack"
and not the official way to go about it, since it's not a complete
"swap out" of the auth m
Adrian Holovaty wrote:
> Would you be comfortable doing this on the magic-removal branch? I ask
> because that branch has *several* backwards-incompatible changes (see
> http://code.djangoproject.com/wiki/RemovingTheMagic), and I wouldn't
> yet call it stable. On the other hand, it's what will bec
I spent some quality time bringing my Oracle patch for Djagno
up-to-date with the most recent svn version stamp as of Monday evening.
I still have some issues with it, though, specifically logging into the
admin app. I think it is a problem somewhere in the session middleware
and how it's dealing
[EMAIL PROTECTED] wrote:
> ... transaction support, its the biggest thing stopping me from using
> django for production work.
Me, too. I'd like to use Django for a time and expense app, but it's a
no go without some kind of answer for bootstrapping transactions into
my code.
-jason
Robert Wittams wrote:
> The reports probably have an "owner" foreign key to the auth.User class,
> right? Then this is the owner. This would be exposed by an additional
> method.
Would this be trickier if I want to allow a particular user or a group
to have access?
> 6) needs a little refinement
Robert Wittams wrote:
> Kindly explain how these cases are harder to manage in the model than
> with an ACL system. Hint: they are easier.
Okay, I'm hearing lots of arguments and assertions without proof (from
anyone). Let's try to tone down the emotion here. I simply have a
business requirement
Joshua D. Drake wrote:
> > Maybe django core doesn't need ACL's, maybe django users will need ACL's
>
> I don't think it is a maybe for django users/developers. If Django wants
> to take off it is going to need some type of ACL otherwise people are
> just going to develop their own and you will en
One big thing I'm missing in Django is the concept of object
"ownership"... Here's my use case:
Lets say I have 3 users:
1) Superuser - that's me... I can create or edit anything
2) Bob - He only has permission to create, edit, or delete expense
reports that he owns. (He can "own" something he cre
Yo, Kapil! How's it going! :-) Glad to see ya here.
Kapil Thangavelu wrote:
> i've been playing with django the last week or so, and have grown to like it
> quite a bit. unfortunately one thing that gives me the willies is django's
> behavior as regarding transaction management, or lack there of.
Adrian Holovaty wrote:
> >>> loc.get_state_display()
>
> This would be a great addition, but I feel like the function name
> ("get_state_display") could be improved. What could we use instead of
> "display"?
How about
>>> loc.get_state_description()
or
>> loc.get_state_descr()
In the apps I wr
Simon Willison wrote:
> 2. Finely grained permissions (others have mentioned this) - the
> ability to restrict which users and/or groups can modify individual
> content items, i.e. database rows.
I added my thoughts on how to implement fine grained permissions here:
http://groups.google.com/grou
Jason Huggins wrote:
> Here's how the above use-cases would be defined in my table:
Sorry, I didn't realize the formatting of my sample table only loooks
good with a fixed-width font.
> check_permissions(principal=request.user,
> permission='add_timesheet',
&g
/plope.com/Members/chrism/decsec_proposal).
Even though my proposal is Django specific, it would be awesome (and
I'd prefer) if Python had a general purpose "acl" library like phpGACL
or an implementation of "decsec" that can be used by any and all Python
web frameworks. Working on a Django-specific 'fine grained permission'
scheme is the next logical step for me... but I think CherryPy could
also use an acl schema like this. Making an acl scheme applicable for
CherryPy and Django would be great, but will take more communication
and coordination with the greater Python developer community. It's a
delicate balance between "solving all the world's problems" and "doing
what's easiest, even if that means coding to a framework, instead of a
Python standard library"
Django-all-the-way-ly-yours,
Jason Huggins
Has anyone else thought about how SOAP or XML-RPC would work with
Django's Manipulators?
Okay... here's the "back story" to the question...
I have a "pre-alpha" web services layer (currently it's just for
XML-RPC, but I'd like to add SOAP, and even -- gasp-- the Atom
protocol). It's composed of
Jacob Kaplan-Moss wrote:
> Set "raw_id_admin=True" option on a ForeignKey.
Potentially, dumb question... but is this kind of functionality
available "for free" in non-admin views or templates?... or is it only
in the admin interface?
-Jason
Adrian Holovaty wrote:
> You're looking for "raw_id_admin=True". Have fun!
Adrian and Jacob, thank you! By the way, perhaps the explanation in the
docs for raw_id_admin should be expanded to mention this alternative
search utility. (Or provide an example in a tutorial.) :-)
Also, I realized afte
This question is mostly for Adrian, but if anyone else knows the
answer, please let me know!
At the ChiPy presentation of Django in July month I remember seeing
something I don't see any documentation for:
In the Admin interface, if a drop down list of choices had too many
entries, you provi
Hey, just a heads up... I uploaded the files (and diff log) required
for Django Oracle support. (http://code.djangoproject.com/ticket/87)
The files are only sitting there attached to the ticket and have not
been integrated with the repository, yet. But if you're itching to try
Django on Oracle,
1) I would like to see django-admin.py methods 'startapp' and
'startproject' renamed to 'createapp' and 'createproject'. "start"
implies 'starting the server'... too similar to 'runserver', I think.
2) Provide a standard convention for where people should put their
tests (unit, functional, and ma
28 matches
Mail list logo
