As of July 2016, EventMan(ager) is under heavy refactoring. For a list of main changes that will be introduced, see https://github.com/raspibo/eventman/issues
Every contribution, in form of code or ideas, is welcome.
These are the paths you see in the browser (AngularJS does client-side routing: no request is issued to the web server, during navigation, if not for fetching data and issuing commands):
The paths used to communicate with the Tornado web server:
Notice that the above paths are the ones used by the webapp. If you plan to use them from an external application (like the event_man barcode/qrcode scanner) you better prepend all the path with /v1.0, where 1.0 is the current value of API_VERSION. The main advantage of doing so is that, for every call, a useful status code and a JSON value is returned.
Also, remember that most of the paths can take query parameters that will be used as a filter, like GET /events/:event_id/tickets?name=Mario
Being too lazy to implement a proper MAC or RBAC, we settled to a simpler mapping on CRUD operations on paths. This will probably change in the future.
User's permission are stored in the permission key, and merged with a set of defaults, valid also for unregistered users. Operations are read, create, update and delete (plus the spcial all value). There's also the special admin|all value: if present, the user has every privilege.
Permissions are strings: the path and the permission are separated by |; the path components (resource:sub-resource, if any) are separated by :. In case we are not accessing a specific sub-resource (i.e.: we don't have a sub-resource ID), the -all string is appended to the resource name. For example:
Sometimes we have to execute one or more scripts in reaction to an action.
In the data/triggers we have a series of directories; scripts inside of them will be executed when the related action was performed on the GUI or calling the controller.
Available triggers:
update_ticket_in_event and attends will receive these information:
In the data/triggers-available there is an example of script: echo.py.
Information are stored in MongoDB. Whenever possible, object are converted into native ObjectId.
Stores information about events and tickets.
Main field:
Notice that all the fields used to identiy a person (name, surname, email) depends on how you've edited the event's form.
Contains a list of username and associated values, like the password used for authentication.
To generate the hash, use:
import utils
print utils.hash\_password('MyVerySecretPassword')
The code is so divided: +- eventman_server.py - the Tornado Web server +- backend.py - stuff to interact with MongoDB +- utils.py - utilities +- angular_app/ - the client-side web application | | | +- .html - AngularJS templates | +- Gruntfile.js - Grunt file to extract i18n strings | +- js/.js - AngularJS code | | | +- app.js - main application and routing | +- controllers.js - controllers of the templates | +- services.js - interaction with the web server | +- directives.js - stuff to interact with the DOM | +- filters.js - filtering data | +- i18n.js - i18n +- data/ | | | +- triggers/ | | | +- triggers-available/ - various trigger scripts | +- triggers/ enabled trigger scripts | | | +- attends.d/ - scripts to be executed when a person is marked as an attendee | +- create_ticket_in_event.d/ - scripts that are run when a ticket is created | +- update_ticket_in_event.d/ - scripts that are run when a ticket is updated | +- delete_ticket_in_event.d/ - scripts that are run when a ticket is deleted +- ssl/ - put here your eventman_cert.pem and eventman_key.pem certs +- static/ | | | +- js/ - every third-party libraries (plus eventman.js with some small utils) | +- css/ - third-party CSS (plus eventman.css) | +- fonts/ - third-party fonts | +- images/ - third-party images | +- i18n/ - i18n files +- templates/ - Tornado Web templates (not used +- tests/ - eeeehhhh
It's enough to be consistent within the document you're editing.
I suggest four spaces instead of tabs for all the code: Python (mandatory), JavaScript, HTML and CSS.
Python code documented following the Sphinx syntax.