Opened 12 years ago

Closed 9 years ago

#525 closed enhancement (duplicate)

allow to register to let comment on my cat pics

Reported by: spaetz Owned by:
Priority: minor Milestone:
Component: programming Keywords:
Cc: Stephen Compall Parent Tickets:


Currently account creation is an all or nothing. If you allow to create accounts, people can upload stuff. I want to limit uploading to a selected circle of priviledged ones (lets call them family) and let other comment on the nice cat pictures we upload (let them call friends). Currently that is not possible. They can not comment as account creation is prohibited, as server space is limited.

You get the point. :). Until commenting via OpenID is implemented, I'd love to enable account creation, but not uploading. essentially that boils down to 3 user levels (commenter, uploader, admin), I guess. Do I make sense?
P.S. I don't have a cat, but kids which boils down to the same problem, just with less hair on the floor.

Change History (11)

comment:1 by spaetz, 12 years ago

Summary: allow to register to let comment on jy cat picsallow to register to let comment on my cat pics

comment:2 by Simon Fondrie-Teitler, 11 years ago

Component: infrastructureprogramming

I'm moving this to Component:programming.

comment:3 by Stephen Compall, 11 years ago

Cc: Stephen Compall added

comment:4 by Emily O'Leary, 11 years ago

Owner: set to Emily O'Leary
Status: newaccepted

I will look into this. :) Potentially on my train ride back from LibrePlanet. Who knows?

I'm thinking the way that I would want to approach it would be to do one of the following things:

  1. Make all users commentors by default and they have to have an admin bump them up to uploader.
  2. The admin could send out "keys" with which people could create or upgrade their account to uploader.
  3. Implement a web-of-trust where you allow existing uploaders to invite a small number of people to be uploaders (and you vary this based on how long they've been there, etc). I'm fond of this one, but probably just because it is more difficult.

I will also look into OpenID support, relating to #39.

comment:5 by Emily O'Leary, 11 years ago

As an aside to this, which I am also working on, I opened ticket #673 which allows for anonymous commenting and comment moderation. So far I have the former finished.

I will also work on this to add user-level support for this ticket. The new, less work intensive idea, is to have the following user levels:

Admins, Uploaders, and Commentors.

We could also add a fourth one: moderator. They would be the same as an uploader with the same power that I am adding to admin which is:

Each user starts out as a Commentor.
They require approval from the admin/moderator (who will have a list and potentially some notification of some sort (e-mail, etc, all optional) before they can upload. But as long as they are verified they should be able to comment as a user.

comment:6 by Christopher Allan Webber, 11 years ago

We have admins. I believe uploaders vs commentors are implicit in the structure of "who uploaded it" vs "who commented on it". We could certainly use "less than admin but more than normal user" stuff in the future... I think it's not something to hyper-worry about at the moment but something we should be thinking out.

comment:7 by Jessica Tallon, 11 years ago

I think a better way of doing this would be something along the lines of a unix group system. Where you would have groups such as

  • Admin
  • Moderator
  • Uploader
  • Commenter

etc... (which also means adding to the system later would be trivial)

You would start by adding the model of Group, and modification to User looking something like:

class Group(Base):
    id   = Column(Integer, primary_key=True)
    name = Column(Unicode, nullable=False, unique=True)

class User(Base, UserMixin):
    # current stuff
    groups = Relationship(Group, 
                  backref=backref("all_groups", lazy="dynamic", cascade="all, delete-orphan")

We then check to see what group they're in, it would get rid of is_admin on the model and make a very extendible future-proof system. When someone wants to upload (or view the upload page) we can just do a query to see if they're in the 'Uploaders' group. We may want to just make a function which has the prototype of:

def in_group(username, group):
    """ example call:
            in_group('Jessica', 'Uploaders') # or maybe the User object
    # code to do the lookup and return boolean if they are

NB: the code in here isn't tested it's just mocked up to show my idea

Last edited 11 years ago by Jessica Tallon (previous) (diff)

comment:8 by Christopher Allan Webber, 11 years ago

Heya Tsesika;

I think you're probably right about the group permissions stuff.

The only thing I'm not sure about otherwise permissions stuff is how this will work in with stuff like LDAP and etc... I really just don't know.

(Also: I think that permissions stuff is starting to spin off onto its own ticket?)

comment:9 by Christopher Allan Webber, 11 years ago

Owner: Emily O'Leary removed

LotusEcho: if you're actively working on this please reclaim! I'm not sure of the status of it though and given our new workflow I'm removing ownership for now :)

comment:10 by Emily O'Leary, 11 years ago

This is tangentially related to #673 and #39, which I am actively working on and could address this issue but not directly. If we moved this more towards a "Group Permissions" ticket then it is not In Progress on my end yet.

comment:11 by spaetz, 9 years ago

Resolution: duplicate
Status: acceptedclosed
Note: See TracTickets for help on using tickets.