Merge branch 'master' of github.com:okfn/ckan into 847-new-theming-docs

Conflicts:
	doc/conf.py

CONTRIBUTING.rst

@@ -1,240 +1,4 @@
-.. External links in this file are done manually instead of using Sphinx stuff
-   like :doc:, :ref:, toctree etc.  because GitHub also renders this file as
-   reStructuredText when it shows its "guidelines for contributing" link when
-   you make a new issue or pull request, and Sphinx things like toctree don't
-   work there. See: https://github.com/blog/1184-contributing-guidelines
+For contributing CKAN (whether code, bug reports, translations, documentation,
+etc.) see our contributing guidelines:
 
-====================
-Contributing to CKAN
-====================
-
-.. _CKAN repo on GitHub: https://github.com/okfn/ckan
-.. _CKAN issue tracker: https://github.com/okfn/ckan/issues
-.. _docs.ckan.org: http://docs.ckan.org
-
-CKAN is free open source software and code contributions are welcome, whether
-they're bug reports, source code, documentation or translations. The sections
-below will walk you through our processes for making different kinds of
-contributions to CKAN.
-
-.. contents::
-   :local:
-   :depth: 1
-
-
-----------------
-Reporting issues
-----------------
-
-If you've found a bug in CKAN, open a new issue on CKAN's `GitHub Issues`_ (try
-searching first to see if there's already an issue for your bug).
-
-.. _GitHub Issues: https://github.com/okfn/ckan/issues
-
-
-----------------
-Translating CKAN
-----------------
-
-For contributing translations to CKAN, see
-`Translating CKAN <http://docs.ckan.org/en/latest/i18n.html>`_.
-
-.. toctree::
-   :hidden:
-
-   i18n
-
-.. _coding standards:
-
-----------------
-Coding standards
-----------------
-
-When writing code for CKAN, try to respect our coding standards:
-
-.. toctree::
-   :hidden:
-
-   ckan-coding-standards
-   python-coding-standards
-   html-coding-standards
-   css-coding-standards
-   javascript-coding-standards
-   testing-coding-standards
-   upgrading-dependencies
-
-* `CKAN coding standards <http://docs.ckan.org/en/latest/ckan-coding-standards.html>`_
-* `Python coding standards <http://docs.ckan.org/en/latest/python-coding-standards.html>`_
-* `HTML coding standards <http://docs.ckan.org/en/latest/html-coding-standards.html>`_
-* `CSS coding standards <http://docs.ckan.org/en/latest/css-coding-standards.html>`_
-* `JavaScript coding standards <http://docs.ckan.org/en/latest/javascript-coding-standards.html>`_
-* `Testing coding standards <http://docs.ckan.org/en/latest/testing-coding-standards.html>`_
-* `Upgrading CKAN's dependencies <http://docs.ckan.org/en/latest/upgrading-dependencies.html>`_
-
-
----------------
-Commit messages
----------------
-
-Generally, follow the `commit guidelines from the Pro Git book`_:
-
-- Try to make each commit a logically separate, digestible changeset.
-
-- The first line of the commit message should concisely summarise the
-  changeset.
-
-- Optionally, follow with a blank line and then a more detailed explanation of
-  the changeset.
-
-- Use the imperative present tense as if you were giving commands to the
-  codebase to change its behaviour, e.g. *Add tests for...*, *make xyzzy do
-  frotz...*, this helps to make the commit message easy to read.
-
-.. _commit guidelines from the Pro Git book: http://git-scm.com/book/en/Distributed-Git-Contributing-to-a-Project#Commit-Guidelines
-
-If your commit has an issue in the `CKAN issue tracker`_ put the issue number
-at the start of the first line of the commit message like this: ``[#123]``.
-This makes the CKAN release manager's job much easier!
-
-Here's an example of a good CKAN commit message::
-
- [#2505] Update source install instructions
-
- Following feedback from markw (see #2406).
-
-
-
-
--------------------------------
-Frontend development guidelines
--------------------------------
-
-.. toctree::
-   :hidden:
-
-   frontend-development
-   templating
-   resources
-   template-tutorial
-   template-blocks
-   javascript-module-tutorial
-
-* `Frontend Development <http://docs.ckan.org/en/latest/frontend-development.html>`_
-* `Templating <http://docs.ckan.org/en/latest/templating.html>`_
-* `Resources <http://docs.ckan.org/en/latest/resources.html>`_
-* `Template Tutorial <http://docs.ckan.org/en/latest/template-tutorial.html>`_
-* `Template Blocks <http://docs.ckan.org/en/latest/template-blocks.html>`_
-* `JavaScript Module Tutorial <http://docs.ckan.org/en/latest/javascript-module-tutorial.html>`_
-
-
----------------------
-Writing documentation
----------------------
-
-The quickest and easiest way to contribute documentation to CKAN is to sign up
-for a free GitHub account and simply edit the `CKAN Wiki <https://github.com/okfn/ckan/wiki>`_.
-Docs started on the wiki can make it onto `docs.ckan.org`_ later.
-
-**Tip**: Use the reStructuredText markup format when creating a wiki page,
-since reStructuredText is the format that docs.ckan.org uses, this will make
-moving the documentation from the wiki into docs.ckan.org later easier.
-
-For how to contribute to the offical CKAN documentation at docs.ckan.org, see
-the `documentation guidelines <http://docs.ckan.org/en/latest/documentation-guidelines.html>`_.
-
-.. toctree::
-   :hidden:
-
-   documentation-guidelines
-
-
-.. _making a pull request:
-
----------------------
-Making a pull request
----------------------
-
-Once you've written some CKAN code or documentation, you can submit it for
-review and merge into the central CKAN git repository by making a pull request.
-This section will walk you through the steps for making a pull request.
-
-
-#. Create a git branch
-
-   Each logically separate piece of work (e.g. a new feature, a bug fix, a new
-   docs page, or a set of improvements to a docs page) should be developed on
-   its own branch forked from the master branch.
-
-   The name of the branch should include the issue number (if this work has an
-   issue in the `CKAN issue tracker`_), and a brief one-line synopsis of the work,
-   for example::
-
-    2298-add-sort-by-controls-to-search-page
-
-
-#. Fork CKAN on GitHub
-
-   Sign up for a free account on GitHub and
-   `fork CKAN <https://help.github.com/articles/fork-a-repo>`_, so that you
-   have somewhere to publish your work.
-
-   Add your CKAN fork to your local CKAN git repo as a git remote. Replace
-   ``USERNAME`` with  your GitHub username::
-
-       git remote add my_fork https://github.com/USERNAME/ckan
-
-
-#. Commit and push your changes
-
-   Commit your changes on your feature branch, and push your branch to GitHub.
-   For example, make sure you're currently on your feature branch then run
-   these commands::
-
-     git add doc/my_new_feature.rst
-     git commit -m "Add docs for my new feature"
-     git push my_fork my_branch
-
-   When writing your git commit messages, try to follow the `Commit Messages`_
-   guidelines.
-
-
-#. Send a pull request
-
-   Once your work on a branch is complete and is ready to be merged into the
-   master branch, `create a pull request on GitHub`_.  A member of the CKAN
-   team will review your work and provide feedback on the pull request page.
-   The reviewer may ask you to make some changes. Once your pull request has
-   passed the review, the reviewer will merge your code into the master branch
-   and it will become part of CKAN!
-
-   When submitting a pull request:
-
-   - Your branch should contain one logically separate piece of work, and not
-     any unrelated changes.
-
-   - You should have good commit messages, see `Commit Messages`_.
-
-   - Your branch should contain new or changed tests for any new or changed
-     code, and all the CKAN tests should pass on your branch, see
-     `Testing CKAN <http://docs.ckan.org/en/latest/test.html>`_.
-
-   - Your branch should contain new or updated documentation for any new or
-     updated code, see `Writing Documentation`_.
-
-   - Your branch should be up to date with the master branch of the central
-     CKAN repo, so pull the central master branch into your feature branch
-     before submitting your pull request.
-
-     For long-running feature branches, it's a good idea to pull master into
-     the feature branch periodically so that the two branches don't diverge too
-     much.
-
-.. _create a pull request on GitHub: https://help.github.com/articles/creating-a-pull-request
-
-
-Merging a pull request
-======================
-
-If you're reviewing a pull request for CKAN, when merging a branch into master:
-
-- Use the ``--no-ff`` option in the ``git merge`` command,
+http://docs.ckan.org/en/latest/contributing

ckan/controllers/related.py

@@ -40,7 +40,7 @@ def dashboard(self):
             base.abort(400, ('"page" parameter must be an integer'))
 
         # Update ordering in the context
-        query = logic.get_action('related_list')(context, data_dict)
+        related_list = logic.get_action('related_list')(context, data_dict)
 
         def search_url(params):
             url = h.url_for(controller='related', action='dashboard')
@@ -55,10 +55,10 @@ def pager_url(q=None, page=None):
             return search_url(params)
 
         c.page = h.Page(
-            collection=query.all(),
+            collection=related_list,
             page=page,
             url=pager_url,
-            item_count=query.count(),
+            item_count=len(related_list),
             items_per_page=9
         )
 

ckan/lib/dictization/model_dictize.py

@@ -91,7 +91,7 @@ def related_list_dictize(related_list, context):
         related_dict = related_dictize(res, context)
         result_list.append(related_dict)
 
-    return sorted(result_list, key=lambda x: x["created"], reverse=True)
+    return result_list
 
 
 def extras_dict_dictize(extras_dict, context):
@@ -355,8 +355,6 @@ def group_dictize(group, context):
     result_dict['extras'] = extras_dict_dictize(
         group._extras, context)
 
-    context['with_capacity'] = True
-
     include_datasets = context.get('include_datasets', True)
 
     q = {
@@ -384,6 +382,7 @@ def group_dictize(group, context):
 
     result_dict['package_count'] = search_results['count']
 
+    context['with_capacity'] = True
     result_dict['tags'] = tag_list_dictize(
         _get_members(context, group, 'tags'),
         context)
@@ -531,7 +530,7 @@ def user_dictize(user, context):
         result_dict['apikey'] = apikey
         result_dict['email'] = email
 
-    ## this should not really really be needed but tests r it
+    ## this should not really really be needed but tests need it
     if new_authz.is_sysadmin(requester):
         result_dict['apikey'] = apikey
         result_dict['email'] = email
@@ -708,17 +707,3 @@ def user_following_group_dictize(follower, context):
 
     base_columns = set(['id', 'resource_id', 'title', 'description',
                         'view_type', 'order', 'config'])
-
-def resource_view_dictize(resource_view, context):
-    dictized = d.table_dictize(resource_view, context)
-    dictized.pop('order')
-    config = dictized.pop('config', {})
-    dictized.update(config)
-    return dictized
-
-def resource_view_list_dictize(resource_views, context):
-    resource_view_dicts = []
-    for view in resource_views:
-        resource_view_dicts.append(resource_view_dictize(view, context))
-    return resource_view_dicts
-

ckan/logic/action/get.py

@@ -214,8 +214,6 @@ def related_show(context, data_dict=None):
 def related_list(context, data_dict=None):
     '''Return a dataset's related items.
 
-    Either the ``id`` or the ``dataset`` parameter must be given.
-
     :param id: id or name of the dataset (optional)
     :type id: string
     :param dataset: dataset dictionary of the dataset (optional)
@@ -264,10 +262,11 @@ def related_list(context, data_dict=None):
 
         if data_dict.get('featured', False):
             related_list = related_list.filter(model.Related.featured == 1)
+        related_items = related_list.all()
     else:
         relateds = model.Related.get_for_dataset(dataset, status='active')
         related_items = (r.related for r in relateds)
-        related_list = model_dictize.related_list_dictize( related_items, context)
+    related_list = model_dictize.related_list_dictize( related_items, context)
     return related_list
 
 

ckan/new_tests/logic/action/test_get.py

@@ -147,6 +147,47 @@ def test_organization_show_private_packages_not_returned(self):
         assert org_dict['packages'][0]['name'] == 'dataset_1'
         assert org_dict['package_count'] == 1
 
+    def test_user_get(self):
+
+        user = factories.User()
+
+        ## auth_ignored
+        got_user = helpers.call_action('user_show', id=user['id'])
+
+        assert 'password' not in got_user
+        assert 'reset_key' not in got_user
+        assert 'apikey' not in got_user
+        assert 'email' not in got_user
+
+        got_user = helpers.call_action('user_show',
+                                       context={'keep_email': True},
+                                       id=user['id'])
+
+        assert got_user['email'] == user['email']
+        assert 'apikey' not in got_user
+        assert 'password' not in got_user
+        assert 'reset_key' not in got_user
+
+        got_user = helpers.call_action('user_show',
+                                       context={'keep_apikey': True},
+                                       id=user['id'])
+
+        assert 'email' not in got_user
+        assert got_user['apikey'] == user['apikey']
+        assert 'password' not in got_user
+        assert 'reset_key' not in got_user
+
+        sysadmin = factories.User(sysadmin=True)
+
+        got_user = helpers.call_action('user_show',
+                                       context={'user': sysadmin['name']},
+                                       id=user['id'])
+
+        assert got_user['email'] == user['email']
+        assert got_user['apikey'] == user['apikey']
+        assert 'password' not in got_user
+        assert 'reset_key' not in got_user
+
 
 class TestBadLimitQueryParameters(object):
     '''test class for #1258 non-int query parameters cause 500 errors