Maniac wrote:
>
> Robert Wittams wrote:
>
>> This is fixed in the new-admin branch. I've forgotten how this actually
>> worked in the admin before (as you say, it looks for the wrong member),
>> but it works for all ForeignKey fields ( in both admin and user views)
>> in that branch.
>>
>>
> R
Robert Wittams wrote:
This is fixed in the new-admin branch. I've forgotten how this actually
worked in the admin before (as you say, it looks for the wrong member),
but it works for all ForeignKey fields ( in both admin and user views)
in that branch.
Robert, is there any estimated time whe
Matt wrote:
> I know where the problem is, and have a work-around but it isn't all
> that pretty. The problem is here:
>
> class FormWrapper:
> ...
> def __getitem__(self, key):
> for field in self.manipulator.fields:
> if field.field_name == key:
> if
Jason Huggins wrote:
> 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 acce
The handy timesince filter, django.utils.timesince.timesince(d), uses
30 days to represent all months. This leads to funny results when
dealing with large timespans. For example, my daughter was born on
March 9th of this year and timesince says she is 7 months old today,
instead of on the 9th.
I know where the problem is, and have a work-around but it isn't all
that pretty. The problem is here:
class FormWrapper:
...
def __getitem__(self, key):
for field in self.manipulator.fields:
if field.field_name == key:
if hasattr(field, 'requires_data
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
> > I don't agree with this sentiment.
>
> You want ACLs, I don't. This isn't actually a sentiment, but a bald
> statement of positions. Why not have a system that allows them but does
> not force them into every situation?
I don't have a problem with that at all. If you don't want to use ACLs
"Jason Huggins" <[EMAIL PROTECTED]> wrote in
message news:[EMAIL PROTECTED]
>
> 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 that I need to figure out, and I'm kind of stuck
> on h
Jason Huggins wrote:
>
> 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.
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
Le Mercredi 5 Octobre 2005 14:49, Robert Wittams a écrit :
> Laurent RAHUEL wrote:
> > The question is not : Do I want to use ACL's ?
> > but : Do django need a better permissions managment ?
> >
> > You can do wathever you want if you're root on your server but you
> > certainly don't wan't any u
I think y'ure missing my point. My APP doesn't need any permissions
framework, the only access to it is via ssh. I am the only user on the
box, it's not exposed on the web, it's purely command line, so why do
I need ACLs ANY auth framework? ANY proposed auth framework should be
completely optional
Hi,
>I'm found while writing current application that this pattern is very
>common (almost a 2/3 of my models are using some type of localized
>name/description fields) and it will be great that i18n/model
>framework supports that without any additional code.
I agree that this is a rather common
Another helper function which I use often to get language dependent
objects from database. I think that's this case is common enough to
put support for that in the framework (see below).
code
from django.utils.translation import get_language
from django.core.exceptions import Obje
Laurent RAHUEL wrote:
> The question is not : Do I want to use ACL's ?
> but : Do django need a better permissions managment ?
>
> You can do wathever you want if you're root on your server but you certainly
> don't wan't any user to be able to do the same.
>
We can certainly agree on that. Dj
Laurent RAHUEL wrote:
> Le Mercredi 5 Octobre 2005 13:01, Robert Wittams a écrit :
>
>>Joshua D. Drake wrote:
>>
Moreover, if you don't need a lot of permissions checking, then you just
need a few basic ACL rules to do the job.
>>>
>>>I know I am new here but a basic ACL is pretty common
Laurent RAHUEL wrote:
> I would be glad to answer your question but since I left my parents I
> stopped answering to orders. I really dislike the way you're talking to
> everyone. I'm sorry not to be a Guru as you seem to be.
>
> Regards,
>
> Laurent
>
>
Well, sorry if I annoyed you, but bein
The question is not : Do I want to use ACL's ?
but : Do django need a better permissions managment ?
You can do wathever you want if you're root on your server but you certainly
don't wan't any user to be able to do the same.
Regards,
Laurent
Le Mercredi 5 Octobre 2005 13:57, Paul Bowsher a
I agree with Robert. I don't need ANY authorisation for one of my
apps, as it's purely run on the command line so you'd need to ssh in
anyway. Why should I have ACLs forced upon me? Putting this in each
model is by far the sanest and fairest way of doing it.
On 10/5/05, Laurent RAHUEL <[EMAIL PRO
I would be glad to answer your question but since I left my parents I
stopped answering to orders. I really dislike the way you're talking to
everyone. I'm sorry not to be a Guru as you seem to be.
Regards,
Laurent
Le Mercredi 5 Octobre 2005 13:01, Robert Wittams a écrit :
> Joshua D. Drake wrote:
> >>Moreover, if you don't need a lot of permissions checking, then you just
> >> need a few basic ACL rules to do the job.
> >
> > I know I am new here but a basic ACL is pretty common place in any kind
> > of adv
Joshua D. Drake wrote:
>>Moreover, if you don't need a lot of permissions checking, then you just need
>>a few basic ACL rules to do the job.
>>
>
> I know I am new here but a basic ACL is pretty common place in any kind
> of advanced development.
Hm, this sounds strangely like "advanced devel
>
> I'm not really convinced by your arguments because :
>
> - You may be allowed to add a CD to your collection, but not mine.
> - You may be allowed to add a CD to some categories of my collection
> - You may be allowed to add a transaction to my account1 but not to my
> account2 whenever you
Laurent RAHUEL wrote:
> Hi,
>
> Le Mercredi 5 Octobre 2005 09:30, hugo a écrit :
>
>>No, I think what would be needed is a simple framework that makes
>>permission calculation easier, but that still should be activated by
>>the model and the views. Preferreable by the model, because then the
>>a
Hi,
Le Mercredi 5 Octobre 2005 09:30, hugo a écrit :
> No, I think what would be needed is a simple framework that makes
> permission calculation easier, but that still should be activated by
> the model and the views. Preferreable by the model, because then the
> automatic admin can take advanta
Hi,
> 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 end up with a bunch of
> different implementations
Sorry, but that's a strawman. Django _has_ take
27 matches
Mail list logo
