I'm not quite sure, it may be me: Is the permission system working at
all in the magig-removal branch?
I added something like that to my model just yesterday:
---
class Meta:
permissions = (
("can_create", "Can create"),
("can_modify", "Can modify"),
("can_view", "Can view
On Thu, 2006-04-27 at 21:21 -0700, SmileyChris wrote:
> An ACL system seems appropriate as long as all objects of one type have
> the same rights, which often isn't the case in the web environment.
>
> For example, someone was asking recently in the Django Users group how
> they could allow users
I agree that maybe an object level ACL system could also be a solution.
The main problem I see with a fine-grained ACL system is that it turns
quickly into Zope permission soup (for those that have played with
Zope).
You quickly get so many permissions per object - it gets confusing fast!
--~--
An ACL system seems appropriate as long as all objects of one type have
the same rights, which often isn't the case in the web environment.
For example, someone was asking recently in the Django Users group how
they could allow users to only edit their own posts. This was what
sparked me starting
On Fri, 2006-04-28 at 02:53 +, [EMAIL PROTECTED] wrote:
> My hope is that it won't be 'roll forwards to something we hope is
> equivalent' because the user would be using evolve with the old version
> of their schema, hopefully from their revision control. If you're using
> the exact same sche
My hope is that it won't be 'roll forwards to something we hope is
equivalent' because the user would be using evolve with the old version
of their schema, hopefully from their revision control. If you're using
the exact same schema as you were before you rolled out the upgrade
than you're rolling
Personally I'd like to see a more fine granied ACL system (ie.. object
level permissions).
actually I'll put that up as a 'SoC' project and see if I can get a
sucker^h^h^h^hstudent to do it.
--Ian
On 4/28/06, SmileyChris <[EMAIL PROTECTED]> wrote:
>
> I'm not a fan of the current permissions sy
On Thu, 2006-04-27 at 20:23 +, [EMAIL PROTECTED] wrote:
> Ok, thanks for clarifying on the comment on rollbacks.
>
> Still, I think rollbacks shouldn't be included. From the user's
> perspecitive there won't be much difference between a rollback and an
> evolve. In both cases they can write
On Thu, 2006-04-27 at 15:56 -0700, SmileyChris wrote:
> I'm not a fan of the current permissions system. It'd be neat to see
> admin permissions evolve to a *nix-like system of user/group/all,
> read/write permissions per object.
> Objects could be linked into the permissions system with a single
On Thu, 2006-04-27 at 09:19 -0700, Jason Davies wrote:
>
> > A solution that fits all needs would be to create an extra parameter for
> > these validators (the ones that take field names) that indicates that
> > only fields for this class should be considered (e.g. only things that
> > start with
I'm not a fan of the current permissions system. It'd be neat to see
admin permissions evolve to a *nix-like system of user/group/all,
read/write permissions per object.
Objects could be linked into the permissions system with a single
foreign key through to a permissions object containing the r/w
If that's the way you all feel - I'll never speak of it again ;)
--
Petar Marić
*e-mail: [EMAIL PROTECTED]
*mobile: +381 (64) 6122467
*icq: 224720322
*skype: petar_maric
*web: http://www.petarmaric.com/
--~--~-~--~~~---~--~~
You received this message because you a
On 4/27/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> A definite -1 on this from me, because it's out of Django's scope.
Agreed.
Also, for the as-yet-undetermined future when we have Dojo integration
merged, people who want WYSIWYG will be able to hang the Dojo
rich-text widget on any text fi
On 4/25/06, Petar Mariæ <[EMAIL PROTECTED]> wrote:
> So, a free global licence for a buffed-up version to one of best
> WYSIWYG XHTML editors today in exchange for a link to xhtml.com? I'm
> so +1 on this :D
A definite -1 on this from me, because it's out of Django's scope.
Besides, requiring a l
On 4/26/06, James Bennett <[EMAIL PROTECTED]> wrote:
> But it's still magic, and it means that any given tag library can be
> imported from either of two locations -- its actual conventional
> Python path, and its "magic" location in 'django.templatetags'.
>
> So... should this bit of magic stay,
The rollbacks are really only usefull (in my mind) for when you go
forward on an app, and it turns out to break something, so you
"rollback". I do think it is a bit of a fringe-case, and can be
handled by proper database backing up. However, I don't see why we
couldn't support it. Plus, I've fi
Ok, thanks for clarifying on the comment on rollbacks.
Still, I think rollbacks shouldn't be included. From the user's
perspecitive there won't be much difference between a rollback and an
evolve. In both cases they can write pre and post (or pre_rollback and
post_rollback) functions. Granted,
I've started to impliment my proposal for schema implementation and
realized that some database-data might need to be distributed along
with updates in the actual application, but there is no mechanism for
it. For instance, if an application requires some sort of seed-data,
but the requirement it
Adrian Holovaty wrote:
> Yeah, Django doesn't use SELECT * -- the field names are always
> explicitly stated in all Django ORM underlying SQL statements. I add
> fields to my models all the time and never have problems regarding
> column order.
Good deal...I will refrain from fixing them all! *gr
On 4/27/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> AFAIK Django doesn't ever use select * and I doubt it ever will. I
> have several projects that, due to upgrades, have the wrong field
> order in the tables. It's never been an issue. If anyone wants to
> figure out the sql to get the colu
> A solution that fits all needs would be to create an extra parameter for
> these validators (the ones that take field names) that indicates that
> only fields for this class should be considered (e.g. only things that
> start with model.__name__, in effect) and the dotted bits
> ("model.positio
On 4/27/06, Ken Kennedy <[EMAIL PROTECTED]> wrote:
> Anyway...this isn't good, but may or may not be REALLY bad. The Right
> Thing to do is make sure that migrated tables have exactly the same
> field order as new ones. The key question on whether or not it's really
> required to go and create te
I'm still poking away at db migration issues...this is a new one. The
auth_permission table appears to have been rearranged, field-wise, when
being installed new, vs. the ADD COLUMN DDL that's been suggested on
the wiki:
New install:
sqlite> .schema auth_permission
CREATE TABLE "auth_permission"
All,
I was doing a slightly chaotic wander through the open tickets this
evening and came across http://code.djangoproject.com/ticket/1690 --
discussing validators and fields with edit_inline set.
Initially I thought that the reporter had a good point and now I'm not
so sure that the "right" ans
24 matches
Mail list logo
