When you open the company settings dialogue and you close it by clicking on the grey rest of the page (not the cancel button or the little cross) and then open it again, all the fields are there twice. If you repeat that more fields are added.
I don't know how to fix that, but the other dialogues don't have that problem.

Implement a project dropdown that shows all available projects when trying to add a new engagement to an employee

Let´s talk about how to structure this project better.

Also check that hpw is positiv and not 0

https://stackoverflow.com/questions/19428121/height100-inside-table-cell-not-working-on-firefox-and-ie

If you sign out and you log in again with another user, you get on the same site like you loged out before. e.g. you are in the detail employee view on a specific employee then you log out and log in with another acc you get on the detail view again. you don't see anything because of god rights management but thats not a usefull behavior

shows 'undefined'

I would add a litte icon to enter the Employee Detail View like:

and i think that this view will provide to much information for a modal dialog. I think it would be a good idea to configure this view as fullscreen and separate route.

What do you think?

In publication.js enagments must be impl as the other collection, because engagements should also be shown only for the creators.

I think there is no need for a projectName field within the Engagements collection since the project name can be resolved by looking up the projectID

@robme91 has this field any other purpose than storing the project name?

I removed all the d3-gantt stuff and started a small html dummy for our employee timeline view. Take a look at 87ce21a branch: dev_timelineViewV1_experimental

Insert useful data for employeeID, projectID, startDate and endDate.

There is a new Version Meteor 1.0.1 out now. Someone read something about it? whats new etc. probably just some bug fixes. Shall we update it? Or do you think we stay now on version 1.0 till projects end?

The more i get into modals i think this is getting a huge pile of clusterfuck. Look at #37 #36 #28 for example. The main problem is that a modal is "always there". Even though it´s hidden, it has been rendered into the page. That leads to updating problems. Life would be easier if i would find a way to "reset" a template to it´s data-source, like "force-rerender" it. Example:

Imagine a modal with one input field bound to a reactive data source...

• open the modal
• edit the input field
• close / cancel the modal without saving

Reopening the modal would now show the edited data, because the reactive datasource has not been changed and so no template rerendering got triggered.

Any ideas on this?

Reminder to change the settings modals to the new render system

StartDate and EndDate has to be something like a date-object like ISODate("1914-07-14T22:00:00Z"), but selecting a date via the DatePicker does only create a string "2015/01/14"

Just a reminder.
In line 66 Employees should be Engagements

Instead add the start and the end sate of the current view.

Hey Leute, wie ist denn hier der Status? Gibt es mittlerweile eine Live-Version oder ein OS-Projekt oder stirbt die Beta mit dem Abschluss SWP? :)

Please have a look in the assignProjectEmployee Branch. I wonder why there are objects in the Engagments collection, as i found with the mongo shell, but won't displayed on client side. Publication.js is edited already, but in the browser console I can't find the inserts.

Engagements should be planed on a weekly basis...

• Engagements should have a week
• and some sort of workload (i.e. 50% or 10h per week)

Every test on TravisCI fails. I guess this problem is caused by Travis CI because:

• local laika testing works
• even old, allready passed tests, fail

node: ../src/coroutine.cc:75: void* find_thread_id_key(void*): Assertion `thread_data_key' failed.
Aborted
make: *** [test] Error 134
The command "make test" exited with 2.
Done. Your build exited with 1.

We should decide if a user can register with a user name or with a user name and a email.
If we use email, should the user have to verify the mail?
Meteor offers everything, we just have to decide.

if you open your project now on master branch there is a error in the console.
TypeError: Template.Homepage is undefined
Template.Homepage.created = function() {

who did this? because i didn't find the homepage template or what it was nebfore. i didn't find the commit where that happened. we have to fix this quick

If so, i would change the Manager field in the Add project dialog to a dropdown showing only the employees...

Or should Projects.Manager be a reference onto the user that created it?

worker-bee?
slave?
teammember?
employee?

The template helpers for project and employee modal dialogs are still in the surrounding template. They should be in their own js file.

... and display it somehow...

I think we have to switch the button colors for "dangerous" operations ... "Delete" should be red, and "Cancel" should be green.

I guess this one (see comment):

Template.employees.rendered = function(){
        $('#editEmployeeModal').on('hide.bs.modal', function (e) {
            /*
            clear session variable when dialog is hiding.
            i´m not really shure why this is neccessary,
            but leaving it set causes data display errors (empty fields...)
            */
            Session.set('employees.employeeToEdit', null);
        });
    };

is caused by the fact that the corresponding modal-close button is of type "reset":

<button class="btn btn-default cancelModalButton" type="reset">Cancel</button>

I didn't find any tags in our master branch. Shall we tag our Sprints after the reviews? I think that would be nice

• It must be possible to add a project even if the week is utilized with 100%
• project startdate must be <= project endddate
• ...
• insert more here...

If you add a simple button to a modal and click it, the modal gets closed. It seems that there is an event handler gone crazy somewhere. Also i found out that there is no need for an seperate event handler to close the modal. A button like <button class="btn btn-default" data-dismiss="modal">Cancel</button> within a modal is enough to close it.