ssh somealias
в ~/.ssh/config
прописывается:
Host somealias
HostName 11.111.11.111
User root
Еще удобно сгенерировать ключ
ssh somealias
в ~/.ssh/config
прописывается:
Host somealias
HostName 11.111.11.111
User root
As of Django 1.2, a readonly_field has been available to models in the admin. This is very helpful for making data visible in the admin while preventing it from being edited.
readonly_fields=[’created’,’modified’,’preformed_by’,’ipaddress’,’featured’]
Using the get_readonly_fields() method of the ModelAdmin, one can change readonly fields dynamically. The method gives access both to the request and to the Admin Model instance.
def get_readonly_fields(self, request, obj = None):
if obj:
if not (request.user.is_staff or request.user.is_superuser):
return [‘featured’,] + self.readonly_fields
return self.readonly_fields
else:
return self.readonly_fields
By default, every Django Admin model has a delete_selected admin action available which allows admins to delete multiple objects in the change_list admin view. If you wish to remove this default option and disable all the admin actions for a given Django Model in the Admin, something like this may be appropriate. This will remove the “Actions” dropdown completely from the model’s change list.
admin_actions = None
An alternative to disabling all the admin actions for a Model would be to override the get_actions() method on the ModelAdmin. This will allow you to customize the “Actions” list based on the request or other factors.
http://stackoverflow.com/questions/1565812/the-default-delete-selected-admin-action-in-django
def get_actions(self, request):
actions = super(PostAdmin, self).get_actions(request)
try:
del actions[‘delete_selected’]
except KeyError:
pass
return actions
The has_delete_permission() ModelAdmin method allows you to customize how permissions are assigned for a given model in the admin. Instead of using Django’s default permission system, you can change the permissions programmatically. Note that this function does not change how permissions work on admin actions such as the delete_selected action discussed above.
def has_delete_permission(self, request, obj=None):
return_value = False
user = request.user
if user.is_authenticated() and user.is_staff:
return_value = True
return return_value
The has_add_permission() allows the same type of customization of permissions for adding objects.
def has_add_permission(self, request):
return_value = False
user = request.user
if user.is_authenticated() and user.is_superuser:
return_value = True
return return_value
The save_model() method allows you to customize actions that take place on the model only when it’s saved in the admin. In this example, we override the save_model() so that we may save to the model of the current admin user and her IP address.
def save_model(self, request, obj, form, change):
obj.preformed_by = request.user
obj.ip_address = utils.get_client_ip(request)
obj.save()
When dealing with ManyToMany fields, the default admin widget is a multiple-select box which allows a user to control-select a list of multiple items. This select box is kind of awkward; a better option may be to use the Filter Horizontal widget which provides a more advanced box.
filter_horizontal = ('category',)
For performance reasons, it may not be a good idea to use the Django default widget or the filter_horizontal widget for ManyToMany relations where a lot of related results. For example, a filter_horizontal Admin widget may take a long time to load if used to display a related tags field if there are thousands of possible related Tags. In that case, the raw_id_fields Admin option may be more appropriate, as it will only display the ID field and unicode representation of the related object. This option also provides a link to a popup dialog that allows an admin to populate the id field by browsing for an object interactively.
raw_id_fields = ("tags",)
The Django Admin offers some flexibility in how the fields on the detail pages are displayed. Fieldsets are used to group Admin fields into sections and even together on the same line. This can be done dynamically by overriding the __init__() on the ModelAdmin.
fieldsets = []
def __init__(self, model, admin_site):
# Define some field groupings
post_fields = ['title', 'type', 'featured']
meta_fields = ['created', 'modified',]
client_fields = ['preformed_by', 'ipaddress']
message_fields = ['message',]
# make a big list of all the fields that we are customizing
ex_fields = post_fields + meta_fields + client_fields + message_fields
all_fields = fields_for_model(model)
base_fields = [tuple(post_fields), tuple(meta_fields), tuple(message_fields)]
# all the rest of the fields that we don’t specifically customize
rest_fields = list(set(all_fields) - set(ex_fields))
# Group fields into Sections
self.fieldsets.append(('Post Info', { 'fields': tuple(base_fields), }))
self.fieldsets.append(('Client Info', { 'fields': tuple(client_fields), }))
# Display the rest of the non-customized fields at the bottom
if rest_fields:
self.fieldsets.append(('Other', { 'fields': tuple(rest_fields), }))
# set the fieldset - needs to be a tuple
self.fieldsets = tuple(self.fieldsets)
super(PostAdmin, self).__init__(model, admin_site)
admin.site.register(models.Post, PostAdmin)
Sometimes it’s nice to be able to customize the admin page for the Django user. This can be done by un-registering the default ModelAdmin class and re-registering your customized version. This code should be placed in any one of your Django App’s admins.py files. In this example, we add a custom Inline class to the User Admin, as well as modify the list_display and list_filter fields for the User Admin.
from django.contrib.auth.admin import UserAdmin
from django.contrib.auth.models import User
class PostInline(admin.TabularInline):
model = models.Post
extra = 0
readonly_fields = ['created', 'modified', 'preformed_by', 'ip_address']
exclude = ['tags','category',]
class CustomUserAdmin(UserAdmin):
list_display = UserAdmin.list_display + ('date_joined','last_login')
list_filter = UserAdmin.list_filter + ('is_active',)
inlines = [PostInline,]
admin.site.unregister(User)
admin.site.register(User, CustomUserAdmin)
The form that an Admin model uses can be customized as well. For example, you can place extra validation on the Admin form to ensure that the admin users enter data correctly.
class PostAdminForm(forms.ModelForm):
class Meta:
model = models.Post
def clean(self):
cleaned_data = self.cleaned_data
message = cleaned_data.get("message", False)
if len(message) < 20:
raise forms.ValidationError("Message must be 20+ chars long.")
return cleaned_data
Set the form by adding it to the PostAdmin ModelAdmin.
class PostAdmin(admin.ModelAdmin):
...
...
form = PostAdminForm
...
One convenient admin customization is to override the default “Django Administration” title that appears at the top of the admin interface. This can be done via an admin template override.
Let’s say our settings.py has our TEMPLATE_DIRS set as follows, where PROJECT_PATH is the UNIX filesystem path to the Django Project.
import os
PROJECT_PATH = os.path.realpath(os.path.dirname(__file__))
TEMPLATE_DIRS = (
os.path.join(PROJECT_PATH, 'templates'),
)
We could create a file called base_site.html located in PROJECT_PATH/templates/admin/ which contains the following Django template code. This overrides the default title for the Django admin.
{# Located in PROJECT_PATH/templates/admin/base_site.html #}
{% extends "admin/base.html" %}
{% load i18n %}
{% block title %}{{ title }} | {% trans 'ChicagoDjango Demo Project Admin' %}{% endblock %}
{% block branding %}
<h1 id="site-name">{% trans 'ChicagoDjango Demo Project Administration' %}</h1>{% endblock %}
{% block nav-global %}{% endblock %}
Sometimes you may want to add extra “sections” to the Django admin on a given Object Change page (change_form.html). This can be done with an admin template override and template inheritance. In order to override the default admin template for the Object Change view, you need to place a file named change_form.html in the following directory within your Django module directory, where your_module_name and your_model_name refers to the lower-case names of your Django module and Django model respectively: templates/admin/<your_module_name>/<your_model_name>/.
Notice in the code below that this custom template overrides admin/change_form.html. Also, this custom template defines a block called {% block after_field_sets %} which adds a template block at the bottom of the page. You can reference the object being edited as a context variable called “original”.
</your_model_name>/<your_module_name>
{# Located in MODULE_PATH/templates/admin/a/post/change_form.html #}
{% extends "admin/change_form.html" %}
{% block extrahead %}{{ block.super }}
<style>
.item { padding: 10px; border-bottom:1px solid #EEEEEE; height: 25px }
.heading { font-weight: bold; font-size: 14px; color: #666666; }
</style>
{% endblock %}
{% block after_field_sets %}{{ block.super }}
<div class="module aligned">
<div class="item">Post: {{ original.title }}</div>
</div>
<div class="module aligned">
<div class="item heading">Post Categories</div>
{% for category in original.category.all %}
<div class="item">
<span class="item_name">{{ category.name }}</span>
<span class="item_edit"><a href="{% url admin:a_postcategory_change category.id %}" target="_blank">Edit</a></span>
</div>
{% empty %}
<div class="item">No Categories</div>{% endfor %}
</div>
{% endblock %}
When it comes to customizing the Django admin, this is just the tip of the iceberg. Please feel free to share any admin customizations that you find interesting via a comment. Also, feel free to fork the Github repository and suggest updates or additional techniques.
Original http://www.chicagodjango.com/blog/django-admin-snippets/
ab -n 1000 -c 10 "http://127.0.0.1:8000/"
# -n number of requests to perform for the benchmarking session. The default is to just perform a single request which usually leads to non-representative benchmarking results.
# -c number of multiple requests to perform at a time. Default is one request at a time.
Just a simple trick to make Terminal open new tabs or windows with the last virtualenv you’ve activated. It does not actually do any wonders, but may be helpful for some. (You’ll need to have virtualenvwrapper installed for this to work.)
Run these commands in your console, they will edit necessary files:
echo 'basename "$VIRTUAL_ENV" > ~/.last_venv' >> $VIRTUALENVWRAPPER_HOOK_DIR/postactivate
echo 'rm ~/.last_venv' >> $VIRTUALENVWRAPPER_HOOK_DIR/postdeactivate
Then open your `~/.bashrc` or `~/.profile` or whatever your shell uses and append:
if [ -e ~/.last_venv ]; then
workon `cat ~/.last_venv`
fi
>>> dir('s')
>>> help('s'.rfind)
>>> a={1, 2, 3}
>>> b={2, 3, 4}
>>> a & b
set([2, 3])
>>> a | b
set([1, 2, 3, 4])
>>> a - b
set([1])
# Конкантенация
>>> "a" 'b'
'ab'
# Третий предел
>>> s="asdfghjklqwerty"
>>> s[::3]
'afjqr'
# Удалять можно сразу срез
l = [0, 1, 2, 3, 4, 5, 6]
>>> del l[2:]
или
>>> del l[::2]
# Генерация словаря
>>> v = [1, 2, 3]
>>> k = ['a', 'b', 'c']
>>> dict(zip(k,v))
{'a': 1, 'b': 2, 'c': 3}
>>> dict.fromkeys(k)
{'a': None, 'b': None, 'c': None}
>>> dict.fromkeys(k, 0)
{'a': None, 'b': 0, 'c': 0}
>>> dict(a = 1, b = 2)
{'a': 1, 'b': 2}
>>> {'a': 1, 'b': 2, 'c': 3}.items()
[('a', 1), ('c', 3), ('b', 2)]