Merge branch 'master' of https://github.com/okfn/ckan

ckan/controllers/group.py

@@ -34,7 +34,7 @@ def _form_to_db_schema(self, group_type=None):
     def _db_to_form_schema(self, group_type=None):
         '''This is an interface to manipulate data from the database
         into a format suitable for the form (optional)'''
-        return lookup_group_plugin(group_type).form_to_db_schema()
+        return lookup_group_plugin(group_type).db_to_form_schema()
 
     def _setup_template_variables(self, context, data_dict, group_type=None):
         return lookup_group_plugin(group_type).\
@@ -100,7 +100,7 @@ def read(self, id):
         group_type = self._get_group_type(id.split('@')[0])
         context = {'model': model, 'session': model.Session,
                    'user': c.user or c.author,
-                   'schema': self._form_to_db_schema(group_type=group_type),
+                   'schema': self._db_to_form_schema(group_type=group_type),
                    'for_view': True, 'extras_as_string': True}
         data_dict = {'id': id}
         # unicode format (decoded from utf8)

ckan/controllers/storage.py

@@ -269,6 +269,9 @@ def get_metadata(self, label):
                             label=label,
                             qualified=False
                             )
+            if url.startswith('/'):
+                url = config.get('ckan.site_url','').rstrip('/') + '/' + url
+
         if not self.ofs.exists(bucket, label):
             abort(404)
         metadata = self.ofs.get_metadata(bucket, label)

ckan/lib/plugins.py

@@ -349,9 +349,6 @@ def history_template(self):
     def group_form(self):
         return 'group/new_group_form.html'
 
-    def form_to_db_schema(self):
-        return logic.schema.group_form_schema()
-
     def form_to_db_schema_options(self, options):
         ''' This allows us to select different schemas for different
         purpose eg via the web interface or via the api or creation vs
@@ -366,11 +363,20 @@ def form_to_db_schema_options(self, options):
 
         if options.get('api'):
             if options.get('type') == 'create':
-                return logic.schema.default_group_schema()
+                return self.form_to_db_schema_api_create()
             else:
-                return logic.schema.default_update_group_schema()
+                return self.form_to_db_schema_api_update()
         else:
-            return logic.schema.group_form_schema()
+            return self.form_to_db_schema()
+
+    def form_to_db_schema_api_create(self):
+        return logic.schema.default_group_schema()
+
+    def form_to_db_schema_api_update(self):
+        return logic.schema.default_update_group_schema()
+
+    def form_to_db_schema(self):
+        return logic.schema.group_form_schema()
 
     def db_to_form_schema(self):
         '''This is an interface to manipulate data from the database

ckan/logic/action/create.py

@@ -512,6 +512,14 @@ def group_create(context, data_dict):
     except AttributeError:
         schema = group_plugin.form_to_db_schema()
 
+    if 'api_version' not in context:
+        # old plugins do not support passing the schema so we need
+        # to ensure they still work
+        try:
+            group_plugin.check_data_dict(data_dict, schema)
+        except TypeError:
+            group_plugin.check_data_dict(data_dict)
+
     data, errors = _validate(data_dict, schema, context)
     log.debug('group_create validate_errs=%r user=%s group=%s data_dict=%r',
               errors, context.get('user'), data_dict.get('name'), data_dict)

ckan/logic/action/get.py

@@ -2049,7 +2049,7 @@ def _follower_list(context, data_dict, FollowerClass):
     users = [user for user in users if user is not None]
 
     # Dictize the list of User objects.
-    return [model_dictize.user_dictize(user,context) for user in users]
+    return model_dictize.user_list_dictize(users, context)
 
 def user_follower_list(context, data_dict):
     '''Return the list of users that are following the given user.
@@ -2192,7 +2192,7 @@ def user_followee_list(context, data_dict):
     users = [user for user in users if user is not None]
 
     # Dictize the list of User objects.
-    return [model_dictize.user_dictize(user, context) for user in users]
+    return model_dictize.user_list_dictize(users, context)
 
 def dataset_followee_list(context, data_dict):
     '''Return the list of datasets that are followed by the given user.

ckan/logic/action/update.py

@@ -415,6 +415,14 @@ def group_update(context, data_dict):
 
     _check_access('group_update', context, data_dict)
 
+    if 'api_version' not in context:
+        # old plugins do not support passing the schema so we need
+        # to ensure they still work
+        try:
+            group_plugin.check_data_dict(data_dict, schema)
+        except TypeError:
+            group_plugin.check_data_dict(data_dict)
+
     data, errors = _validate(data_dict, schema, context)
     log.debug('group_update validate_errs=%r user=%s group=%s data_dict=%r',
               errors, context.get('user'),

ckan/public/scripts/templates.js

@@ -152,7 +152,7 @@ CKAN.Templates.resourceDetails = ' \
 CKAN.Templates.resourceExtra = ' \
   <div class="dynamic-extra"> \
   <button class="btn btn-danger remove-resource-extra">X</button>\
-  <input type="text" placeholder="Key" class="extra-key" value="${key}" /> \
-  <input type="text" placeholder="Value" class="extra-value" value="${value}" /> \
+  <input type="text" placeholder="'+CKAN.Strings.key+'" class="extra-key" value="${key}" /> \
+  <input type="text" placeholder="'+CKAN.Strings.value+'" class="extra-value" value="${value}" /> \
   </div> \
   ';

ckan/templates/js_strings.html

@@ -63,6 +63,8 @@
       unknown = _('Unknown'),
       extraFields = _('Extra Fields'),
       addExtraField = _('Add Extra Field'),
+      key = _('Key'),
+      value = _('Value'),
       deleteResource = _('Delete Resource'),
       youCanUseMarkdown = _('You can use %aMarkdown formatting%b here.'),
       datesAreInISO = _('Dates are in %aISO Format%b — eg. %c2012-12-25%d or %c2010-05-31T14:30%d.'),

ckan/templates/related/add-related.html

@@ -16,7 +16,7 @@ <h3 class="heading">Add item</h3>
       <div class="control-group">
         <input id="related-dataset" type="hidden" name="dataset_id" value="${c.pkg.id}"/>
         <label for="related-title">Title <span class="required">(required)</span></label>
-        <input id="related-title" name="title" class="span6" placeholder="Please add the title for the item"/>
+        <input id="related-title" name="title" class="span6" placeholder='${_("Please add the title for the item")}'/>
       </div>
       <div class="control-group">
         <label for="related-type">Type of item</label>
@@ -32,15 +32,15 @@ <h3 class="heading">Add item</h3>
       </div>
       <div class="control-group">
         <label for="related-description">Description</label>
-        <textarea id="related-description" name="description" class="input-xlarge span6" rows="4" placeholder="Please describe the item"></textarea>
+        <textarea id="related-description" name="description" class="input-xlarge span6" rows="4" placeholder='${_("Please describe the item")}'></textarea>
       </div>
       <div class="control-group">
         <label for="related-url">URL <span class="required">(required)</span></label>
-        <input id="related-url" name="url" type="url" class="span6" placeholder="Please add a url"/>
+        <input id="related-url" name="url" type="url" class="span6" placeholder='${_("Please add a url")}'/>
       </div>
       <div class="control-group">
         <label for="related-image-url">Image URL</label>
-        <input id="related-image-url" name="image_url" type="url" class="span6" placeholder="Please add a link to the image"/>
+        <input id="related-image-url" name="image_url" type="url" class="span6" placeholder='${_("Please add a link to the image")}'/>
       </div>
       <div>
         <button type="submit" class="btn btn-primary">Submit</button>

doc/install-from-source.rst

@@ -221,3 +221,86 @@ they all pass. See :doc:`test`.
 
 You can now proceed to :doc:`post-installation` which covers creating a CKAN
 sysadmin account and deploying CKAN with Apache.
+
+Upgrading a source install
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Before upgrading your version of CKAN you should check that any custom
+templates or extensions you're using work with the new version of CKAN. For
+example, you could install the new version of CKAN in a new virtual environment
+and use that to test your templates and extensions.
+
+You should also read the `CKAN Changelog <https://github.com/okfn/ckan/blob/master/CHANGELOG.txt>`_
+to see if there are any extra notes to be aware of when upgrading to the new
+version.
+
+1. Backup your CKAN database using the ``ckan db dump`` command, for example::
+
+    paster --plugin=ckan db dump --config=/path/to/your/ckan.ini my_ckan_database.pg_dump
+
+   This will create a file called ``my_ckan_database.pg_dump``, if something
+   goes wrong with the CKAN upgrade you can use this file to restore the
+   database to its pre-upgrade state. See :ref:`dumping and loading` for
+   details of the `ckan db dump` and `ckan db load` commands.
+
+2. Checkout the new CKAN version from git, for example::
+
+    cd pyenv/src/ckan
+    git fetch
+    git checkout release-v1.8.1
+
+   If you have any CKAN extensions installed from source, you may need to
+   checkout newer versions of the extensions at this point as well. Refer to
+   the documentation for each extension.
+
+3. Update CKAN's dependencies. Make sure that your CKAN virtual environment
+   is active, then run this command::
+
+     pip install --upgrade -r /path/to/your/pyenv/ckan/ckan/pip-requirements.txt
+
+4. If you are upgrading to a new major version of CKAN (for example if you are
+   upgrading to CKAN 1.7, 1.8 or 1.9, etc.), update your CKAN database's schema
+   using the ``ckan db upgrade`` command.
+
+    .. warning ::
+
+        To avoid problems during the database upgrade, comment out any
+        plugins that you have enabled on your ini file. You can uncomment
+        them back when the upgrade finishes.
+
+   For example::
+
+    paster --plugin=ckan db upgrade --config=/path/to/your/ckan.ini
+
+   If you are just upgrading to a minor version of CKAN (for example upgrading
+   from version 1.8 to 1.8.1) then it should not be necessary to upgrade your
+   database.
+
+   See :ref:`upgrade migration` for details of the ``ckan db upgrade`` command.
+
+5. If CKAN's Solr schema version has changed between the CKAN versions you're
+   upgrading from and to, then you need to update your solr schema symlink
+   (Check the CHANGELOG to see if it necessary to update the schema, otherwise
+   you can skip this step).
+
+   When :ref:`setting up solr` you created a symlink
+   ``/etc/solr/conf/schema.xml`` linking to a CKAN Solr schema file such as
+   ``/path/to/your/pyenv/ckan/ckan/config/solr/schema-1.4.xml``. This symlink
+   should be updated to point to the latest schema file in
+   ``/path/to/your/pyenv/ckan/ckan/config/solr/``, if it doesn't already.
+
+   After updating the symlink, you must rebuild your search index by running
+   the ``ckan search-index rebuild`` command, for example::
+
+    paster --plugin=ckan search-index rebuild --config=/path/to/your/ckan.ini
+
+   See :ref:`rebuild search index` for details of the
+   ``ckan search-index rebuild`` command.
+
+6. Finally, restart your web server. For example if you have deployed CKAN
+   using the Apache web server on Ubuntu linux, run this command::
+
+    sudo service apache2 restart
+
+7. You're done! You should now be able to visit your CKAN website in your web
+   browser and see that it's now running the new version of CKAN.

doc/paster.rst

@@ -184,6 +184,8 @@ You can delete everything in the CKAN database, including the tables, to start f
 
 The next logical step from this point is to do a "db init" step before starting CKAN again.
 
+.. _dumping and loading:
+
 Dumping and Loading databases to/from a file
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -202,6 +204,8 @@ To load it in again, you first have to clean the database of existing data (be c
 
 The pg_dump file notes which PostgreSQL user 'owns' the data on the server. Because the PostgreSQL user (by default) is identified as the current Linux user, and this is setup to be ``ckanINSTANCE`` where ``INSTANCE`` is the name of the CKAN instance. This means if you want to restore the pg_dump as another CKAN instance name (often needed if you move it to another server) then you will need to change the database owner - see :doc:`howto-editing-database-ownership`.
 
+.. _upgrade migration:
+
 Upgrade migration
 ~~~~~~~~~~~~~~~~~
 
@@ -248,6 +252,7 @@ This important command gives you fine-grained control over CKAN permissions, by
 
 The ``roles`` command has its own section: see :doc:`authorization`.
 
+.. _rebuild search index:
 
 search-index: Rebuild search index
 ----------------------------------

doc/solr-setup.rst

@@ -1,3 +1,5 @@
+.. _setting up solr:
+
 ===============
 Setting up Solr
 ===============