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/ | shPlease 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.shFor 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.shFinally, 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.
-
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 approvallabel. -
Issue approved / rejected
The core team will discuss the issue and approves or rejects it. Approved issues get the
pr welcomelabel assigned and will also contain a comment of approval / denial to inform all issue members. -
Open pull request
You should always create a pull request to the
developbranch, unless there is a strong reason to merge into another specific branch. Note thatmasteris 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 requiredlabel.Work-in-progress pull requests are encouraged and you should tag them with the
work in progresslabel to show others that this PR is still incomplete. -
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.
-
Merge
The PR is merged into the
developbranch 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.
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):
| Category | Style | Tool | NPM Script |
|---|---|---|---|
| JS | Javascript standard style | standard |
lint:code |
| SCSS | Sass Guidelines | stylelint |
lint:style |
| Markdown | Markdown lint | markdownlint |
lint:markdown |
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 usingpuppeteer
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