Custom Query (1173 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (172 - 174 of 1173)

Ticket Resolution Summary Owner Reporter
#677 wontfix Allow more characters in username Jessica Tallon
Description

Currently usernames can only be [a-z0-9] I think they should also support utf-8 characters.

#678 fixed Group Permissions Jessica Tallon
Description

So this should be like the Unix groups system, groups can be made which have the ability to do certain things (e.g. be an admin, upload media, etc...) It will be a many to many relationship (A user can be in many groups and a group can have many users). I would suggest a model looking similar to

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"
                                  )
                          )

It would be handing having a method we can use (probably be in mediagoblin/tools/ ?) somethign like

def in_group(User, group):
    """
    This would check if the user was in the group
    An Example call would be:
        in_group(<user_object>, 'admin')
    """
    # <code which returns True if they're in the group and False if they're not>

Then we would also have to add where file uploads occur if they're in the specified group. Where they try to access the admin panel (or even show the links for it) if they're in the admin group, etc...

I think it is very important that we keep the current permissions prior to the addition of group permissions as the default, so:

  • A registered user can upload by default
  • Only people specifically added to the admin group are admins

There would also have to be some extra code added in in regards to migration from one version of GMG to another and for new installs (in the dbupload tool presumably). And finally this obviously needs to be well covered by unit tests.

#679 fixed Database "fixtures" (but not the testing kind) Christopher Allan Webber
Description

(Note: this is *not* the best name, because it could be confused with unit testing fixtures... I don't know if there's a better name that does not have that overlap.)

We're using a relational database, and this means there may be expectations that certain rows are installed in tables. This could be for several reasons:

  • we might have a table that contains different license options; by default, we would want to prepopulate with some good ones
  • we might store permissions in the database with certain roles, such as in #678. But in order to check if someone is in the admin group, that group would need to already exist!
  • maybe we could stop storing media type information on media models as a string! Instead, we could have media types like images, video, etc, on a table. But that also means that every time we install a media type it needs to set up a fixture in the application for itself.

As far as I can tell, installing fixtures will happen in a couple of ways:

  • The first time that mediagoblin core or an extension such as a plugin/media type is installed, it will need to set up some common fixtures. We need new tooling for this!
  • Later, new fixtures may be added or changed. This is easy; we do not need a new tooling for this, we can use our existing migrations infrastructure.

So in theory, the above two can be handled both by ./bin/gmg dbupdate... we just need to add new tooling for the former.

(There's one more possibile tool we could add to this: a convenience method that queries for a certain row, and if it doesn't see it, creates it. That's not super necessary though.)

Batch Modify
Note: See TracBatchModify for help on using batch modify.
Note: See TracQuery for help on using queries.