Welcome to projecto’s documentation!¶

Overview¶

Project management systems nowadays are too complicated for small-medium sized projects. Good ones costs money and offers the product as a service rather than a software package that you can host on your own server.

Projecto offers four main features:

• Feed: for project updates
• Todos: managing tasks
• Files: file sharing
• Schedule: time scheduling with people

Feed¶

Pretty much like twitter. Short messages are made here. Tasks done in other parts of the systems can be posted here and so forth. People can also comment on each feed items.

Features that need work:

• Integration with other systems: such as tasks, files, and so forth
• RSS feed

Todos¶

Sort of like github issues. Has tags, assign, due date, and so forth. This is a place where people can use Markdown for description, as well.

Features that need work:

• Assignment of tasks, duedates
• Milestone
• Single todo view/commenting

Files¶

A simulated file systems for file sharing. Straight forward and simple.

This system is currently minimally viable. More features will be added soonish.

Wishlist:

• WebDAV
• Integration with things like Dropbox

Schedule¶

A meeting calendar for the team.

This system needs to be designed.

Wishlist:

• CalDAV integration
• Commenting/voting on meeting times. - Integration with doodle?

Management¶

Management of projects. Adding/deleting contributors, admins, and so forth.

Features that need work:

• Another class of users with readonly permission
• An owner that cannot be deleted by other admins
• Changing project name, and maybe have other attributes.
• Automatically add all users with a certain domain name for email address.

Users¶

Login system uses Mozilla Persona for easier integration. This means people can feel free to integrate LDAP by using a Mozilla Persona LDAP bridge for authentication.

Gravatar for avatar, and other user profile features are currently minimal, but could be worked on.

Planned features¶

• Email integration: Sending emails to update the team. Let team use email to respond to the system. - There are security concerns here but there are ways to mitigate this.
• Standards, standards, standards. - Things like WebDAV and whatnot is essential in my view. Although it would be too much work to get an MVP out for now.
• Mobile clients - responsive site may not be possible. A mobile webapp seem to be the way to go as we do not want to support all the platforms.

Vagrant Setup¶

The requirements for the vagrant setup is fairly light. You need to install the followings:

• Vagrant
• NFS - For Windows, ignore this and follow the instructions in Vagrant Setup (Recommended).
• NodeJS
• Firefox and Chromium for now.
• After you get all of this, go to the project root and run npm install.
• Now remember to add node_modules/.bin to your $PATH.

Instructions for those are available online. So follow them.

Continue to Vagrant Setup (Recommended).

Windows Notes¶

(This may or may not be broken with the new files feature).

The lack of NFS on Windows is a big deal. So what we can do is redirect the DATABASE_FOLDER to be something different. The recommended place is your home directory, which is /home/vagrant.

So, create a database folder in /home/vagrant:

$ mkdir /home/vagrant/databases

Your settings_local.py file should have the extra line:

DATABASES_FOLDER = "/home/vagrant/databases"

After this, your unittests should pass. You can also remove the databases folder inside your directory.

Git Workflow¶

When authoring a patch for a feature or to fix a bug, use git’s branching feature. Always branch out to a branch with the issue number in it. Let’s say if you’re working on issue 42 and it is about refactoring the feed controller, before you start your patch, you should branch out like this:

$ git branch refactor-feed-42

Of course, the name of the branch is up to you. Try to reference the issue number in the branch name.

Next, you should author your patch. Try to have some descriptive commit messages.

If master receives additional commits after you started your patch, have no fear! If master’s change is relatively insignificant, just keep going. Otherwise you should rebase your changes against master:

$ git fetch upstream # Assuming that upstream points to the projecto repo.
$ git rebase upstream/master

Once you’re done your patch, commit and push it to your own repository:

$ git commit # commits
$ git push origin refactor-feed-42 # or other branch names

Now go to the Github UI and hit pull request. Have a descriptive title and some descriptions of what this patch does and why it is useful. Put “Fixes #<issuenumber>” (example: Fixes #42) at the end of the pull request description.

Wait for review and once you get a thumbs up, your code will be merged.

Unittests¶

Testing is a very important part of Projecto. Not everything was tested when the project first began. However, all new code must have unittests unless it is an extremely trivial change (typo, or things that doesn’t affect the core logic).

Additionally, all unittests must pass for code to be merged. So please run all tests.

The clientside tests runs by typing the following command on host machine:

$ karma start karma.config.js

This will test the clientside code in both Chrome, Firefox, and PhantomJS.

The server side tests runs by typing the following command on the Vagrant box:

$ t