This is the code repository for the lea.online teacher dashboard application.

We use Meteor for our application to fetch and display data in near realtime. To install Meteor run the install script:

curl https://install.meteor.com/ | sh

Please note, that Windows is supported by Meteor but not officially supported by this repo. If you get everything running on Windows (dev, tests, build / deployment) feel free to update the documentation accordingly for Windows users.

The lea.online system (which this app is part of) uses a dedicated OAuth2 server for authenticating users and authorizing access across applications. If you have not installed this repo from the main development repository (recommended), you need to install the accounts server manually:

https://github.com/leaonline/leaonline-accounts
cd ./leaonline-accounts
./run.sh

For the teacher app you need to clone this repo and run the ./run.sh script:

git clone [email protected]:leaonline/leaonline-teacher.git
cd ./leaonline-teacher
./install.sh
./run.sh

Finally, open your browser at http://localhost:5555 to load the client app. You can login with one of the initially created accounts to continue to the teacher dashboard.

Every contribution is appreciated and we treat every issue and pull request with care. Please note, that we follow a certain workflow for contributions.

1. Create issue

   There should always be an issue, describing a bug or a feature request before contributing code. Pull requests without issues will be on hold until an issue is created and passed step 2. Issues that did not go through step 2 will get the needs approval label.

2. Issue approved / rejected

   The core team will discuss the issue and approves or rejects it. Approved issues get the pr welcome label assigned and will also contain a comment of approval / denial to inform all issue members.

3. Open pull request

   You should always create a pull request to the develop branch, unless there is a strong reason to merge into another specific branch. Note that master is disabled for non-core members.

   It is possible to reference multiple issues with a single PR as long as it's made clear, which issues are solved by which parts of the PR. Try to avoid to solve multiple issues with a single commit.

   Pull requests that have merge conflicts, failed the linter, failed the tests or miss tests for new features / bigger changes will not get into review phase. They will also be tagged with the fixes required label.

   Work-in-progress pull requests are encouraged and you should tag them with the work in progress label to show others that this PR is still incomplete.

4. Review

   There will be always reviewes for a PR from externals. Reviews should reject the pull request, in case of any changes required. However, there may the case of neglectable changes ("nice to have"), which may not affect the approval of the pull request. In such a case, an issue should be opened and referenced in the comment, while the pull request can be approved.

5. Merge

   The PR is merged into the develop branch and the issue is closed. The core team will usually increase the version of the project in a separate commit.

The folder structure follows the recommended structure from the Meteor guide. If you are not familiar with it, please consult the Meteor guide, first.

• client
• imports
  • api
    • blazebootstrap
    • i18n
    • routing
    • utils
  • factories
  • startup
    • client
      • scss - custom styles / theme
    • server
  • ui
    • components
      • icon
      • loading
      • onloaded
      • proxy
    • layout
      • nav
        • bottom
        • side
          • scss
        • top
    • pages
      • class
      • login
      • logout
      • myclasses
      • notfound
      • user
    • utils
• public
  • icons
• resources - Static resources
  • i18n - Translation files
• server
• tests
  • api
    • routing

In order to build / update the folder structure please edit the respective README.md file in the folder you want to describe. The description is wrapped inside comments to indicate that this part is printed to the tree.

Example:

# foldername

This will not be printed but still be part of the README.

<!-- optional markdown-notes-tree directory description starts here -->

This will be printed as description next to the folder name

<!-- optional markdown-notes-tree directory description ends here -->

This will not be printed but still be part of the README.

And run the respective build script npm run build:folder-tree. After that, please validate the markdown using the lint:markdown script.

We use Meteor Blaze Bootstrap as UI components library. Please read it's documentation, if you are interested to contribute to the UI part.

Note: we will migrate to Bootstrap 5 soon so consider to use plain HTML components with Boostrap classes.

This project uses several style rules, enforced by different linters. The following table shows the styles and their respective tools and commands (scripts, see package.json):

Make sure to run all linters without error, before you open a pull request. There is a lint.sh shellscript added for your convenience. It basically executes these commands in a row.

This project uses mocha and chai for tests. In order to run the tests locally in watch mode, you simply need to call the test.sh script and then watch your server tests on the console and your client tests on localhost:5566 in the browser.

You can call the script with the following options:

• -v - verbose, prints variables and paths before the test execution
• -c - cli, also used in the ci workflow, runs the script ones in headless mode using puppeteer

The ci workflows run on push to master and develop (which is restricted) and on pull requests. Every ci workflow includes the following jobs:

• lint code
• lint style
• lint markdown
• pass tests

If any of these jobs failes, the whole workflow fails and your PR is not considered for review until the issues have been resolved.

We use mup (Meteor-Up) as one-step deployment tool. While deployment to the official lea.online platform is restricted to the lea core developers, you still might want to deploy a custom build. In this case you should follow the documentation on their website. It's super easy.

APGL 3, see LICENSE FILE