Custom Query (1173 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:

Results (295 - 297 of 1173)

← 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 →
Ticket Resolution Summary Owner Reporter
#174 FIXED Use of "Submit" in site copy is sterile and not as friendly and welcoming as it could be Jef van Schendel Karen Rustad
Description 
All over the site, we have exhortations to users to "Submit media",
"Submit an item", or even "Submit yer media!".

First of all, the inconsistency (all of these links go the same
place!) is silly. Let's have a standard usage in site copy, and if
variance is needed, we can justify that later.

Second, I've never liked "submit" in web copy. At best, it's rather
formal programmer-ese. At worst, it carries a whiff of
authoritarian control ("YOU WILL SUBMIT"). Neither of these matches
the tone of the site.

What do we think of, say "Add [yer] media"? Or even "Add pictures"
-- we may as well be specific, we don't support anything else yet
:P
#914 wontfix Use named ForeignKeys in migrations Elrond
Description

db/migrations.py has this: 

from mediagoblin.db.models import (MediaEntry, Collection, MediaComment, User,
        Privilege)

This is a big NO! Those are the current variansts of those tables. Not the versions needed in any old migration. Those current tables could have changed in a completely unexpected way and break old migrations.

If there are migration docs, please add a note about this.

The current main use of the above imports is code like this: 

creator = Column(Integer, ForeignKey(User.id), nullable=False)

This can be easily fixed: 

creator = Column(Integer, ForeignKey('core__users.id'), nullable=False)

When this is done, please take a look at add_new_notification_tables(): 

    user_table = inspect_table(metadata, 'core__users')
    mediaentry_table = inspect_table(metadata, 'core__media_entries')
    mediacomment_table = inspect_table(metadata, 'core__media_comments')

This code might be useless.

After fixing all of this, please make sure the migrations still work.

#312 FIXED Use mongokit's "Dot Notation" Christopher Allan Webber Elrond
Description 
mongokit supports accessing fields not only as ``doc['field']`` but
also as ``doc.field``.


-  This might look more pythonic.
-  This will ease a possible transition to sqlalchemy (as this it
   the sqlalchemy way)
-  Docs:
   http://namlook.github.com/mongokit/tutorial.html#dot-notation Main
   questions:
-  Switch it on now or in the sql-migration branch?
-  If switching it on now, should all accesses be converted to the
   new syntax?
← 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 →
Batch Modify
Note: See TracBatchModify for help on using batch modify.
Note: See TracQuery for help on using queries.