Custom Query (1173 matches)
Results (172 - 174 of 1173)
Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|
#677 | wontfix | Allow more characters in username | ||
Description |
Currently usernames can only be [a-z0-9] I think they should also support utf-8 characters. |
|||
#678 | fixed | Group Permissions | ||
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:
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) | ||
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:
As far as I can tell, installing fixtures will happen in a couple of ways:
So in theory, the above two can be handled both by (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.) |