Hi I am new to odoo and linux ubuntu 16.04 LTS, I had set up the ubuntu desktop on an oracle vm virtualbox, I have also installed the necessary repository and apt for odoo11, postgresql, python3 and pycharm.
My odoo11 is already working fine and I am able to install and run existing applications, however I have tried to generate a scaffold to develop a module of my own, and I have followed guides and documentations.
My odoo.conf has these options
[options]
; This is the password that allows database operations:
; admin_passwd = admin
db_host = False
db_port = False
db_user = odoo
db_password = False
logfile = /var/log/odoo/odoo-server.log
addons_path = /opt/odoo/odoo/addons,/home/mtsoftware/Documents/projects/tutorial/addons
while my manifest.py has these option
# -*- coding: utf-8 -*-
{
'name': "myfirstModel",
'summary': """
Short (1 phrase/line) summary of the module's purpose, used as
subtitle on modules listing or apps.openerp.com""",
'description': """
Long description of module's purpose
""",
'author': "My Company",
'website': "http://www.yourcompany.com",
# Categories can be used to filter modules in modules listing
# Check https://github.com/odoo/odoo/blob/master/odoo/addons/base/module/module_data.xml
# for the full list
'category': 'Uncategorized',
'version': '0.1',
# any module necessary for this one to work correctly
'depends': ['base'],
# always loaded
'data': [
# 'security/ir.model.access.csv',
'views/customer.xml',
],
# only loaded in demonstration mode
'demo': [
'demo/demo.xml',
],
}
Upon trying to search for "myfirstModel" in my module list # odoo11 application page, it returns a "No module found!"
Any one can help me?
Related
I am trying to update a yaml file in place with values that are rendered from a shell script. The fields I am trying to update is upassword and schema. My yaml is slightly different from regular yaml
Here is how my Yaml looks like:
# values.conf
[first]
# First user
server_host = xxx.com
server_port = 1432
schema = get
uname = CN=svc-xxx-090
upassword =
[auth]
# default to /etc/.passwd in packaged installations and ./passwds in
# tarball installations.
#passwd_file =
passwd_db = pass.db
enabled=True
I need this yaml to be updated to:
# values.conf
[first]
# First user
server_host = xxx.com
server_port = 1432
schema = put
uname = CN=svc-xxx-090
upassword = 5668guuh6y%&_jhv86#
[auth]
# default to /etc/.passwd in packaged installations and ./passwds in
# tarball installations.
#passwd_file =
passwd_db = pass.db
enabled=True
I have regular yamls that I am using and able to update them without any issues but this yaml drives me crazy. Any help regarding this will be greatly appreciated. Thanks!
I am looking at making changes to an existing project hosted on github and readthedocs. However the generated HTML looks to be built by Sphinx without a conf.py.
$ ls
appendixA.rst chapter11.rst chapter17.rst chapter4.rst html
appendixB.rst chapter12.rst chapter18.rst chapter5.rst images
appendixC.rst chapter13.rst chapter19.rst chapter6.rst index.rst
attribution.rst chapter14.rst chapter2.rst chapter7.rst sandbox
chapter1.rst chapter15.rst chapter20.rst chapter8.rst src
chapter10.rst chapter16.rst chapter3.rst chapter9.rst toc.txt
Note particularly that index.rst exists but conf.py does not. find also shows it is not hiding somewhere else in the project. The generated site on readthedocs works and is consistent with the latest, including some problems seen in the github project, eg Chapter 1 is not indexed properly due to being listed under another name in index.rst.
I am new to Sphinx and readthedocs. In my new local build environment, sphinx doesn't like it at all:
> sphinx-build -b html . html/
Application error:
config directory doesn't contain a conf.py file (.)
That's consistent with the documentation, but not the readthedocs website behaviour. I'm guessing that readthedocs has some fallback behaviour for these cases, probably by generating a simple conf.py from other configuration it holds. However, it makes it hard to reproduce when making changes locally, especially for a project I don't own. If this is the case, I can't find any documentation on this feature. If I am not missing something simple (entirely possible), is there any?
My next step will be to write a new conf.py, and get it to conform to the existing behaviour on a local site. This would be easier if I understood the existing behaviour.
The actual project in question is the Jython book:
https://jython.readthedocs.io/en/latest/
https://github.com/jython/book
Had no luck finding related issues or questions on google, stackoverflow, readthedocs doco or issues. The readthedocs code at https://github.com/rtfd/readthedocs.org/blob/master/readthedocs/projects/models.py seems to have a check for conf.py, too.
Huh, that's interesting that you don't have a conf.py but the docs still built successfully on Date: 2017-10-24T19:18:40.379930Z. I'm just as dumbfounded as you.
Anyway, you can find the conf.py that RTD ends up using under the project's build's raw log file. That might save you some grief. Note that the versions are about 1.5 years old, so you would need to pin versions to try to reproduce it exactly.
cat conf.py
# -*- coding: utf-8 -*-
from recommonmark.parser import CommonMarkParser
extensions = []
templates_path = ['/home/docs/checkouts/readthedocs.org/readthedocs/templates/sphinx', 'templates', '_templates', '.templates']
source_suffix = ['.rst', '.md']
source_parsers = {
'.md': CommonMarkParser,
}
master_doc = 'index'
project = u'jython'
copyright = u'2016'
version = 'latest'
release = 'latest'
exclude_patterns = ['_build']
pygments_style = 'sphinx'
htmlhelp_basename = 'jython'
html_theme = 'sphinx_rtd_theme'
file_insertion_enabled = False
latex_documents = [
('index', 'jython.tex', u'jython Documentation',
u'', 'manual'),
]
###########################################################################
# auto-created readthedocs.org specific configuration #
###########################################################################
#
# The following code was added during an automated build on readthedocs.org
# It is auto created and injected for every build. The result is based on the
# conf.py.tmpl file found in the readthedocs.org codebase:
# https://github.com/rtfd/readthedocs.org/blob/master/readthedocs/doc_builder/templates/doc_builder/conf.py.tmpl
#
import sys
import os.path
from six import string_types
from sphinx import version_info
# Get suffix for proper linking to GitHub
# This is deprecated in Sphinx 1.3+,
# as each page can have its own suffix
if globals().get('source_suffix', False):
if isinstance(source_suffix, string_types):
SUFFIX = source_suffix
else:
SUFFIX = source_suffix[0]
else:
SUFFIX = '.rst'
# Add RTD Static Path. Add to the end because it overwrites previous files.
if not 'html_static_path' in globals():
html_static_path = []
if os.path.exists('_static'):
html_static_path.append('_static')
html_static_path.append('/home/docs/checkouts/readthedocs.org/readthedocs/templates/sphinx/_static')
# Add RTD Theme only if they aren't overriding it already
using_rtd_theme = False
if 'html_theme' in globals():
if html_theme in ['default']:
# Allow people to bail with a hack of having an html_style
if not 'html_style' in globals():
import sphinx_rtd_theme
html_theme = 'sphinx_rtd_theme'
html_style = None
html_theme_options = {}
if 'html_theme_path' in globals():
html_theme_path.append(sphinx_rtd_theme.get_html_theme_path())
else:
html_theme_path = [sphinx_rtd_theme.get_html_theme_path()]
using_rtd_theme = True
else:
import sphinx_rtd_theme
html_theme = 'sphinx_rtd_theme'
html_style = None
html_theme_options = {}
if 'html_theme_path' in globals():
html_theme_path.append(sphinx_rtd_theme.get_html_theme_path())
else:
html_theme_path = [sphinx_rtd_theme.get_html_theme_path()]
using_rtd_theme = True
if globals().get('websupport2_base_url', False):
websupport2_base_url = 'https://readthedocs.org/websupport'
if 'http' not in settings.MEDIA_URL:
websupport2_static_url = 'https://media.readthedocs.org/static/'
else:
websupport2_static_url = 'https://media.readthedocs.org//static'
#Add project information to the template context.
context = {
'using_theme': using_rtd_theme,
'html_theme': html_theme,
'current_version': "latest",
'MEDIA_URL': "https://media.readthedocs.org/",
'PRODUCTION_DOMAIN': "readthedocs.org",
'versions': [
("latest", "/en/latest/"),
],
'downloads': [
("pdf", "//readthedocs.org/projects/jython/downloads/pdf/latest/"),
("htmlzip", "//readthedocs.org/projects/jython/downloads/htmlzip/latest/"),
("epub", "//readthedocs.org/projects/jython/downloads/epub/latest/"),
],
'subprojects': [
],
'slug': 'jython',
'name': u'jython',
'rtd_language': u'en',
'canonical_url': 'http://jython.readthedocs.io/en/latest/',
'analytics_code': 'None',
'single_version': False,
'conf_py_path': '/./',
'api_host': 'https://readthedocs.org',
'github_user': 'jython',
'github_repo': 'book',
'github_version': 'master',
'display_github': True,
'bitbucket_user': 'None',
'bitbucket_repo': 'None',
'bitbucket_version': 'master',
'display_bitbucket': False,
'READTHEDOCS': True,
'using_theme': (html_theme == "default"),
'new_theme': (html_theme == "sphinx_rtd_theme"),
'source_suffix': SUFFIX,
'user_analytics_code': '',
'global_analytics_code': 'UA-17997319-1',
'commit': 'cf5cf6de',
}
if 'html_context' in globals():
html_context.update(context)
else:
html_context = context
# Add custom RTD extension
if 'extensions' in globals():
extensions.append("readthedocs_ext.readthedocs")
else:
extensions = ["readthedocs_ext.readthedocs"]
I'm writing a wrapper cookbook for nexus3 wherein I override the default attributes like so in the attributes/default.rb file of my cookbook
# Nexus Options
node.default['nexus3']['properties_variables'] = { port: '8383', host: '0.0.0.0', args: '${jetty.etc}/jetty.xml,${jetty.etc}/jetty-http.xml,${jetty.etc}/jetty-requestlog.xml', context_path: '/nexus/' }
node.default['nexus3']['api']['host'] = 'http://localhost:8383'
node.default['nexus3']['api']['username'] = 'admin'
node.default['nexus3']['api']['password'] = 'Ch5f#A4min'
While Chef does install nexus3 with the override properties, property values for the nexus3_api fail to take effect during cookbook run, as I see in the logs
==> provisioner: * execute[wait for http://localhost:8081/service/siesta/rest/v1/script to respond] action run
==> provisioner: [2018-06-11T05:58:17+00:00] INFO: Processing execute[wait for http://localhost:8081/service/siesta/rest/v1/script to respond] action run (/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.2.0/lib/chef/resource.rb line 1285)
==> provisioner: [2018-06-11T05:58:17+00:00] INFO: Processing execute[wait for http://localhost:8081/service/siesta/rest/v1/script to respond] action run (/opt/chef/embedded/lib/ruby/gems/2.5.0/gems/chef-14.2.0/lib/chef/resource.rb line 1285)
I'm running this cookbook through vagrant chef provision and my Vagrant file is as follows
# -*- mode: ruby -*-
# vi: set ft=ruby :
# All Vagrant configuration is done below. The "2" in Vagrant.configure
# configures the configuration version (we support older styles for
# backwards compatibility). Please don't change it unless you know what
# you're doing.
Vagrant.configure("2") do |config|
config.vm.define "provisioner" do |provisioner|
provisioner.vm.box = "ubuntu/xenial64"
provisioner.vm.box_version = "20180509.0.0"
provisioner.vm.box_check_update = false
provisioner.omnibus.chef_version = :latest
provisioner.vm.network "forwarded_port", guest: 8080, host: 8282
provisioner.vm.network "forwarded_port", guest: 8383, host: 8383
provisioner.vm.provider :virtualbox do |vbox|
vbox.name = "pipeline-jumpstart-chef"
vbox.memory = 2048
vbox.cpus = 2
end
provisioner.vm.provision "chef_solo" do |chef|
chef.node_name = "chef-provisioned"
chef.cookbooks_path = "../../cookbooks"
chef.verbose_logging = true
chef.add_recipe "pipeline-jumpstart-chef"
end
end
end
here's the source for cookbook on which I'm building wrapper
You mention your are overriding the attributes but your code indicates you are setting those attributes to the default level. You should review the Attribute Precedence in Chef to understand what default means exactly. In addition, inside the attributes file you don't need to prefix with node just use default::
default['nexus3']['properties_variables'] = { port: '8383', host: '0.0.0.0', args: '${jetty.etc}/jetty.xml,${jetty.etc}/jetty-http.xml,${jetty.etc}/jetty-requestlog.xml', context_path: '/nexus/' }
default['nexus3']['api']['host'] = 'http://localhost:8383'
default['nexus3']['api']['username'] = 'admin'
default['nexus3']['api']['password'] = 'Ch5f#A4min'
The node.default syntax is used inline, inside a recipe to set attributes. If you review the precedence chart you'll notice inline and default attributes are one level higher.
If you want to use override you can do this for each attribute:
override['nexus3']['properties_variables'] = { port: '8383', host: '0.0.0.0', args: '${jetty.etc}/jetty.xml,${jetty.etc}/jetty-http.xml,${jetty.etc}/jetty-requestlog.xml', context_path: '/nexus/' }
override['nexus3']['api']['host'] = 'http://localhost:8383'
override['nexus3']['api']['username'] = 'admin'
override['nexus3']['api']['password'] = 'Ch5f#A4min'
However, unless it's absolutely necessary to set these attributes in the wrapper cookbook you are likely better off setting this as a default attribute at a higher precedence, such as a role. See the quote below from the same document' Attribute Types section about override attributes:
An override attribute is automatically reset at the start of every
chef-client run and has a higher attribute precedence than default,
force_default, and normal attributes. An override attribute is most
often specified in a recipe, but can be specified in an attribute
file, for a role, and/or for an environment. A cookbook should be
authored so that it uses override attributes only when required.
If you simply set these as default inside your wrapper cookbook's attributes/default.rb file then both the source cookbook and your wrapper are trying to set the same attribute at the same level. This is likely going to lead to unexpected behavior or simply not work.
I am developing an application with PhP and client asked me to set up a vagrant machine and install every needed extensions and modules, so that with just one Vagrant up command the client will have the same environment as I have,
I firstly installed a vagrant machine from one of the boxes lsit
vagrant box add ubuntu1 http://goo.gl/KwQSa2
Then I run these commands:
vagrant init ubuntu1
vagrant up
in the directory that I made this file there is only a vagranrfile
The Question:
I need to know if I make any changes to my server for example, installing php or mysql how it is going to saved in the setting so that if I just give this file to my client he will be able to have an identical machine to mine with everything installed?
I mean there will be any changes to vagrantfile or I made some mistake and I had to install a machine with puppet?
thanks in advance
No, the vagrant file is not going to change as you install things in the VM.
If you want your client to have the same machine as you, you'll have to avoid installing softwares through the VM's shell. You should only use the provisioner, for everything, even mysql tables, apache virtual hosts etc..
And don't use vagrant box add ubuntu1 http://goo.gl/KwQSa2, add the box's url to the vagrantfile with:
config.vm.box_url = "http://goo.gl/KwQSa2"
Example puppet provisioning for a mysql/php server:
group { 'puppet':
ensure => 'present',
}
#
# Apache configuration
#
class { 'apache' :
default_mods => false,
default_confd_files => false,
mpm_module => 'prefork',
default_vhost => false,
sendfile => 'Off'
}
class { 'apache::mod::php' : } # mod_php
class { 'apache::mod::rewrite' : } # mod_rewrite
# VHost configuration
apache::vhost { 'dev.XXX.fr' :
port => '80',
docroot => '/var/sites/myXXX/web',
access_log => true,
access_log_file => 'XXX_access.log',
error_log => true,
error_log_file => 'XXX_error.log',
aliases => [{alias => '/myXXX', path => '/var/sites/toto/web'}],
directories => [{path => '/var/sites/myXXX/web', 'allow_override' => ['FileInfo', 'Indexes']}, {path => '/var/sites/toto/web', 'allow_override' => ['FileInfo', 'Indexes']}]
}
#
# Mysql configuration
#
class { '::mysql::server' :
root_password => 'XXX',
databases => {
'XXX' => {
ensure => 'present',
charset => 'utf8'
}
},
users => {
'XXX#localhost' => {
ensure => 'present',
password_hash => 'XXX' # XXXmdp
}
},
grants => {
'XXX#localhost/XXX' => {
ensure => 'present',
options => ['GRANT'],
privileges => ['SELECT', 'INSERT', 'UPDATE', 'DELETE', 'CREATE'],
table => 'XXX.*',
user => 'XXX#localhost'
}
}
}
class { '::mysql::client' : }
package { 'php5-mysql' :
require => [Class['apache::mod::php'], Class['::mysql::server']],
ensure => 'present'
}
You will need the following modules:
apache
concat
mysql
stdlib
The puppet config above is just for the example, I highly encourage you to read there documentation which is really well done: http://docs.puppetlabs.com/learning/introduction.html
Honestly, puppet is a great tool, take the time to learn it.
One more thing, avoid using the shell provisionner, the commands are executed everytime you run "vagrant provision", puppet only executes changes. (I only use the shell provisionner for apt-get update and apt-get upgrade)
Vagrantfile is a recipe which tells Vagrant how to set up your machine. In a way, it serves as an installation automation tool (and of course does much more as well). If you do any changes to the machine after it was created, Vagrant would not know about that.
What I do is I create Vagrantfile and inside of it I specify a shell script which Vagrant will execute only once, after machine boots the first time.
VAGRANTFILE_API_VERSION = "2"
$bootstrap = <<SCRIPT
# Installing all dependencies and other required software.
# Add "-y" switch to make sure installation is fully automatic.
apt-get install -y python-software-properties
# Any other stuff I might want to do (like edit conf files)
...
SCRIPT
Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
config.vm.box = "precise64"
config.vm.provision "shell", inline: $bootstrap
end
See the doc for config.vm.provision.
I do this inline for convienience, so all configuration is still kept in only one file.
Of course any configuration which is supported directly by Vagrant, is better kept out of this $bootstrap script.
I am using the following command on WinXP and getting an error, but works fine on MacOS and Linux, thank you very very much for any help.
C:\Documents and Settings\Administrator\Sites\team_track>manage.py syncdb --settings=local_settings
Creating tables ...
Creating table auth_permission
Creating table auth_group_permissions
Creating table auth_group
Creating table auth_user_user_permissions
Creating table auth_user_groups
Creating table auth_user
Creating table auth_message
Creating table django_content_type
Creating table django_session
Creating table django_site
Creating table django_admin_log
Creating table app_player
Creating table app_team_players
Creating table app_team
Creating table app_game
Creating table app_gameparticipant
You just installed Django's auth system, which means you don't have any superusers defined.
Would you like to create one now? (yes/no): yes
Username (Leave blank to use 'administrator'):
E-mail address: kam#kam.com
Password:
Password (again):
Superuser created successfully.
Installing custom SQL ...
Traceback (most recent call last):
File "C:\Documents and Settings\Administrator\Sites\team_track\manage.py", line 19, in <module>
execute_manager(team_tracker.settings)
File "c:\Python27\lib\site-packages\django\core\management\__init__.py", line 438, in execute_mana
ger
utility.execute()
File "c:\Python27\lib\site-packages\django\core\management\__init__.py", line 379, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "c:\Python27\lib\site-packages\django\core\management\base.py", line 191, in run_from_argv
self.execute(*args, **options.__dict__)
File "c:\Python27\lib\site-packages\django\core\management\base.py", line 220, in execute
output = self.handle(*args, **options)
File "c:\Python27\lib\site-packages\django\core\management\base.py", line 351, in handle
return self.handle_noargs(**options)
File "c:\Python27\lib\site-packages\django\core\management\commands\syncdb.py", line 121, in handl
e_noargs
custom_sql = custom_sql_for_model(model, self.style, connection)
File "c:\Python27\lib\site-packages\django\core\management\sql.py", line 166, in custom_sql_for_mo
del
backend_name = connection.settings_dict['ENGINE'].split('.')[-1]
AttributeError: 'tuple' object has no attribute 'split'
Here is what my manage.py looks like:
#!/usr/bin/env python
import sys
import os.path
from django.core.management import execute_manager
try:
import team_tracker.settings # Assumed to be in the same directory.
except ImportError:
import sys
sys.stderr.write("Error: Can't find the file 'settings.py' in the directory containing %r. It appears you've customized things.\nYou'll have to run django-admin.py, passing it your settings module.\n(If the file settings.py does indeed exist, it's causing an ImportError somehow.)\n" % __file__)
sys.exit(1)
if __name__ == "__main__":
execute_manager(team_tracker.settings)
And my local_settings.py resides in root dir:
from team_tracker.settings import *
DEBUG = True
#DATABASE_ENGINE = 'sqlite3'
#DATABASE_NAME = 'caktus_website.db'
DATABASE_ENGINE = 'sqlite3', # Add 'postgresql_psycopg2', 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
DATABASE_NAME = 'team_track.db' # Or path to database file if using sqlite3.
And finally my team_tracker/settings.py is here:
# Django settings for team_tracker project.
import os.path
DEBUG = True
TEMPLATE_DEBUG = DEBUG
ADMINS = (
# ('Your Name', 'your_email#example.com'),
)
SITE_ROOT = os.path.realpath(os.path.dirname(__file__))
MANAGERS = ADMINS
#DATABASES = {
# 'default': {
# 'ENGINE': 'django.db.backends.sqlite3', # Add 'postgresql_psycopg2', 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
# 'NAME': 'team_track.db', # Or path to database file if using sqlite3.
# 'USER': '', # Not used with sqlite3.
# 'PASSWORD': '', # Not used with sqlite3.
# 'HOST': '', # Set to empty string for localhost. Not used with sqlite3.
# 'PORT': '', # Set to empty string for default. Not used with sqlite3.
# }
#}
# Local time zone for this installation. Choices can be found here:
# http://en.wikipedia.org/wiki/List_of_tz_zones_by_name
# although not all choices may be available on all operating systems.
# On Unix systems, a value of None will cause Django to use the same
# timezone as the operating system.
# If running in a Windows environment this must be set to the same as your
# system time zone.
TIME_ZONE = 'America/Chicago'
# Language code for this installation. All choices can be found here:
# http://www.i18nguy.com/unicode/language-identifiers.html
LANGUAGE_CODE = 'en-us'
SITE_ID = 1
# If you set this to False, Django will make some optimizations so as not
# to load the internationalization machinery.
USE_I18N = True
# If you set this to False, Django will not format dates, numbers and
# calendars according to the current locale
USE_L10N = True
# Absolute filesystem path to the directory that will hold user-uploaded files.
# Example: "/home/media/media.lawrence.com/media/"
MEDIA_ROOT = '/Users/kamilski81/Sites/team_tracker/media/'#os.path.join(SITE_ROOT, 'appmedia')
# URL that handles the media served from MEDIA_ROOT. Make sure to use a
# trailing slash.
# Examples: "http://media.lawrence.com/media/", "http://example.com/media/"
MEDIA_URL = '/media/'
# Absolute path to the directory static files should be collected to.
# Don't put anything in this directory yourself; store your static files
# in apps' "static/" subdirectories and in STATICFILES_DIRS.
# Example: "/home/media/media.lawrence.com/static/"
STATIC_ROOT = '/Users/kamilski81/Sites/team_tracker/static/'
# URL prefix for static files.
# Example: "http://media.lawrence.com/static/"
STATIC_URL = '/static/'
# URL prefix for admin static files -- CSS, JavaScript and images.
# Make sure to use a trailing slash.
# Examples: "http://foo.com/static/admin/", "/static/admin/".
ADMIN_MEDIA_PREFIX = '/static/admin/'
# Additional locations of static files
STATICFILES_DIRS = (
# Put strings here, like "/home/html/static" or "C:/www/django/static".
# Always use forward slashes, even on Windows.
# Don't forget to use absolute paths, not relative paths.
)
# List of finder classes that know how to find static files in
# various locations.
STATICFILES_FINDERS = (
'django.contrib.staticfiles.finders.FileSystemFinder',
'django.contrib.staticfiles.finders.AppDirectoriesFinder',
# 'django.contrib.staticfiles.finders.DefaultStorageFinder',
)
# Make this unique, and don't share it with anybody.
SECRET_KEY = 'v8#s)7gw-^#zp&6**g7rz$uj!#3v4a36so_uw!_#0pa$h4)b-s'
# List of callables that know how to import templates from various sources.
TEMPLATE_LOADERS = (
'django.template.loaders.filesystem.Loader',
'django.template.loaders.app_directories.Loader',
# 'django.template.loaders.eggs.Loader',
)
MIDDLEWARE_CLASSES = (
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
# #kamtodo: find out how to truly use this and the best way if we have many forms
# 'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
)
ROOT_URLCONF = 'urls'
TEMPLATE_DIRS = (
# Put strings here, like "/home/html/django_templates" or "C:/www/django/templates".
# Always use forward slashes, even on Windows.
# Don't forget to use absolute paths, not relative paths.
os.path.join(SITE_ROOT, 'templates').replace('\\','/'),
)
INSTALLED_APPS = (
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'django.contrib.messages',
'django.contrib.staticfiles',
# Uncomment the next line to enable the admin:
'django.contrib.admin',
# Uncomment the next line to enable admin documentation:
'django.contrib.admindocs',
'app',
)
# A sample logging configuration. The only tangible logging
# performed by this configuration is to send an email to
# the site admins on every HTTP 500 error.
# See http://docs.djangoproject.com/en/dev/topics/logging for
# more details on how to customize your logging configuration.
LOGGING = {
'version': 1,
'disable_existing_loggers': False,
'handlers': {
'mail_admins': {
'level': 'ERROR',
'class': 'django.utils.log.AdminEmailHandler'
}
},
'loggers': {
'django.request': {
'handlers': ['mail_admins'],
'level': 'ERROR',
'propagate': True,
},
}
}
In local_settings.py:
DATABASE_ENGINE = 'sqlite3',
The comma here makes DATABASE_ENGINE a tuple with one element instead of a string. Remove it and it should work.