Incubating: Kopere Dashboard

Maintained by Picture of Eduardo Kraus Eduardo Kraus
Kopere Dashboard is a tool panel with reports, online users, backup, notifications and more.
1330 sites
16 fans

Users online

This is the feature I've always wanted to develop and did it on Kopere Dashboard. It shows the users online in real time, which page they are accessing, whether the focus is on the page or not, the size of the Monitor, which browser they are using and if they are accessing a smartphone and which model of it.

All this in real time.

Click here and see more about Online Users

Import Users

A simple and complete system for importing users.

It is not necessary to send with fixed columns and after import it is just to link columns of the CSV with columns of Moodle.


Benchmark is the act of performing a set of operations in order to evaluate the relative performance of an object, usually running a series of tests and tests on it.

This part is an enhancement to the report_benchmark

Click here and see more about Performace

Static pages

Static pages are pages that you can create for a wide range of purposes. You can, for example, create a FAQ with the main information for the students or for those who access your moodle not being a student.

Click here and see more about static pages


System that generates complete bank backup and MoodleData in moodle easily and quickly.


Lots of useful reports.

Next versions will be developed system to be able to create new reports.


Screenshot #0
Screenshot #1
Screenshot #2


Picture of Eduardo Kraus
Eduardo Kraus (Lead maintainer)
Please login to view contributors details and/or to contact them

Comments RSS

Show comments
  • Picture of Plugins bot
    Tue, 22 Aug 2017, 12:20 AM
    Approval issue created: CONTRIB-7019
  • Picture of Dan Marsden
    Tue, 19 Sep 2017, 5:06 PM
    Hi Eduardo,

    Thanks for sharing this with us - it looks very interesting.

    I've just a very quick look at this and noticed this line in the first file I opened:

    $menu and $text vars are not validated well - and this might present a security issue which could allow an unauthenticated user to access any file on the server.
    for example - what would happen if the $menu var contained something like '/../../../config.php/' - I'm pretty sure we could break the inclusion of the '.html' on the end somehow too.

    Some of the validation checks run in the plugins db can also be run automatically on github using the travis-ci integration.

    More information on this is here:
    this will pick up a number of other things that we would normally notice in the review process.

    Integrating with travis is optional and will not block approval in the plugins db, but it does make the review process a bit easier and usually provides a good way to ensure future compliance with coding guidelines etc.

    Thanks for your patience with the plugin review process - there are quite a few other plugins in the queue currently waiting for review before yours but hopefully this will give you some initial feedback you can work on.
  • Picture of Dan Marsden
    Wed, 20 Sep 2017, 6:23 AM
    Thanks Eduardo,

    that's slightly better but quite hard to read and review your code to ensure it is safe - it would be better if you could do the cleaning in your optional_param call just above - swapping out PARAM_TEXT for PARAM_ALPHA or another supported PARAM type that doesn't allow directory traversals. (The more restrictive you can be the better - so if PARAM_ALPHA is all you need it's best to use that.)

    I see you haven't looked at adding the travis checks yet - there are a number of other areas of your code that do not comply with our coding guidelines and will result in a failed review - many of these failures would be picked up by the local_codechecker plugin - or the travis integration checks.

    for example - direct access to $_GET/$_POST is not allowed - you should be using optional/required_param functions with appropriate cleaning.

    There still seems to be a lot of other places in your code where you take unvalidated data and pass it straight to file handling functions - here's another example:

    I would recommend that you also review this doc:

    many of your files are missing login/capability checks allowing anonymous users to perform tasks they should not be able to - combine that with your use of file handling functions this results in some very significant security vulnerabilities for anyone with your code installed on their site.

    For now we will flag this plugin as requiring more work - please use either the local_codechecker plugin or the travis integration to improve the quality of your code before we review this plugin again.

    Hopefully you will be able to spend some time fixing the quality of this plugin up - it looks really interesting and I'm sure some people would like to use it - thanks!
  • Picture of Eduardo Kraus
    Wed, 20 Sep 2017, 4:02 PM
    HTML::link Allow only [a-z,0-9-]
  • Picture of Dan Marsden
    Wed, 20 Sep 2017, 4:08 PM
    I think you are missing the point. Your code does not meet the standards required for inclusion in the Plugins directory. Please spend some more time improving the quality of your code and when you have done this let us know and we can take another look.
  • Picture of Dan Marsden
    Wed, 20 Sep 2017, 5:42 PM
    does it meet our coding guidelines? - No.
    Will leaving the code like this prevent the plugin from being approved in the plugins db? - it's not the worst of your existing code but it would really be nice to see better compliance with our standards.

    I've given you some general feedback that covers a number of areas you should improve - please spend some time doing this rather than asking individual questions here. If you need help with development/general Moodle code, feel free to ask for help in the community forums.
  • Picture of David Mudrák
    Wed, 20 Sep 2017, 7:59 PM

    Eduardo, please let me encourage you to follow the Moodle coding style as much as possible, even if it does not fit your personal style fully. There are good reasons for why we call for it. It helps to keep the Moodle code base in a reasonable consistent style, allowing other community members to review the code, spot potentially weak places and suggests improvements more easily.

    In this particular case, there are no good reasons why you should blindly trust the incoming input, consider it as a plain text (with the support for multilang syntax) and store it in the database. It only makes the whole thing fuzzy and unreliable in general. You know what parameters are allowed, whether they are optional or required and what type they are.

  • Picture of Polaris Lee
    Thu, 14 Dec 2017, 4:21 PM
    I can not see the install button.
  • Picture of arief widodo
    Fri, 29 Dec 2017, 7:11 PM
    How to install this plug in..
Please login to post comments