Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

stats extension: Historical/first statistics show as tables rather than graphs #5375

Open
Chealer opened this issue May 8, 2020 · 2 comments
Assignees

Comments

@Chealer
Copy link

Chealer commented May 8, 2020

CKAN 2.8.4

Please describe the expected behaviour

The statistics extension offers a statistics page at /stats which contains a menu at the left. The first 2 options from that menu offer historical numbers which are represented as HTML tables. The plot.js module is supposed to turn these tables into charts.

Please describe the actual behaviour

The contents of the Total Number of Datasets and Dataset Revisions per Week tabs always remains displayed as "raw", untransformed HTML tables.

What steps can be taken to reproduce the issue?

  1. See https://demo.ckan.org/stats#stats-dataset-revisions

Someone asked how the tables could be turned into graphs in ticket #5180, but after investigation, I found that displaying graphs is supposed to be the default behavior. The fact that version 2.8.3 and ulterior display tables means there was a regression. We have an instance of CKAN 2.5.1 which displays graphs, so there must have been a change between 2.5.1 and 2.8.3 which broke this. @smotornyuk has written in the other ticket that:

there may be an issue with JS that controls tabs - when the page is loaded, it strips out content for an instant in order to put it into relevant tabs - and in this particular moment data-module="plot" is activated - this may be the reason, why data-module is ignored.

However, version 2.5.1 already used Bootstrap tabs, so it remains unclear why the upgrade would change the result. This might have something to do with the upgrade from Bootstrap 2 to 3.

It may help if someone could bisect which change caused this, but it should be noted that this issue may be "resolved" by CKAN 2.9, which is scheduled to remove the problematic tables/graphs following commit e6401d1.

Our organization will be working around this with the following HTML addition to templates/ckanext/stats/index.html:

  {# TODO: Hack so tables get converted to graphs #}
  {# FIXME: Hack so the rest of the hack can call jQuery even if it is normally loaded later (CKAN offers no way to load a snippet after jQuery!) #}
  <script type="text/javascript" src="{{ h.url_for_static('/fanstatic/vendor/jquery.min.js') }}"></script>
  <script>
  jQuery(function() {
      jQuery('a[data-toggle="tab"]').on('shown.bs.tab', function () {
        uninitialized = jQuery('[data-module=plot]:visible');
        if (uninitialized.length) {
          ckan.module.initializeElement(uninitialized[0]);
        }
        });
      jQuery('li.active a[data-toggle="tab"]').trigger('shown.bs.tab');
    });
  </script>
@smotornyuk
Copy link
Member

@Chealer , we've discussed it today on dev meeting. stats extension wasn't actively used during the last few years, nor properly maintained. As I said in the linked issue, after release 2.9 I'm going to spend some time and make few improvements to this plugin. But it always better to have someone interested in the tool, than someone who just doing work because nobody else is enthusiastic about the tool.
What would you say about taking stats extension under your maintenance? It not so big or low-level, so it doesn't require deep knowledge of CKAN - all you need is a grasp of python(or js if you are going to use charts - those languages are pretty the same, so it shouldn't create any problem) and few ideas of how to do things better. Tech team doesn't mind against extracting stats into separate extension - in such a way you'll be able to use new functionality even in released CKAN versions, not only in v3.0. And you don't have to wait till i complete all the tasks that have a higher priority for me.
How does it sound?

@Chealer
Copy link
Author

Chealer commented May 19, 2020

Thank you for the offer @smotornyuk
The idea is not bad, but unfortunately I am about to leave the team developing the site I work on, and at this point I am afraid the site may not have access to a development team which can take such a responsibility for some time.

Feel free to make such a proposal again in the future if that seems appropriate, but I personally have to decline.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants