crowdguru / crowdguru

crowdguru monolithic repository

crowdguru

A platform connecting people who have skills they'd like to share with those who need help

Go to [wiki page] (https://github.com/crowdguru/crowdguru/wiki) for further information

For any kind feature request, problem or defect please raise an issue from [here] (https://github.com/crowdguru/crowdguru/issues/new).

---

Web site: http://www.crowdguru.org

Development site: http://crowdguru.cfapps.io/

Developers mailing list: https://groups.google.com/forum/#!forum/crowdguru-dev

Google+ community page: https://plus.google.com/u/0/communities/115932858304206533693

crowdguru's Issues

Integrate a test coverage tool

We need a coverage tool integrated in the build system so that we can measure test coverage to increase traceability and facilitate change management

Implement responding help offers

Implement view for realizing UC2-Register

Implement UC9-Offer Help

Use case is here

Enable Travis-CI service hook

Per #6, Travis-CI service hook should be enabled for the repository as well in order to activate CI.

Here is the tutorial.

Determine specialism and specialism groups

Upcoming use cases heavily uses specialisms. Currently fields are empty in the related pages. Data set needs to be constructed asap.

Create a service layer between domain model and client side applications

Define the application's boundary with a layer of services that establishes a set of available operations and coordinates the application's response in each operation.

This will break the dependency between web applications and data layer and increase reuse possibilities. We can identify application specific logic and domain logic, thus making business logic more generic.

Integrate js and css dependency management libs

Add specialisms dataset

Release 0.0.2-SNAPSHOT

Description

Make a new release at the end of the sprint

Make datastore unit tests run automatically

Only webapp tests are running right now. We should cover datastore as well.

Clarify validation requirements for UC2-Register

Validation will be very important on the production stage. This use case should be clear in terms of:

• What are the acceptance criteria for a new submission? Important for acceptance test.
• What are the acceptance criteria for each field
• Which fields will be validated on client side? What will be the failure behaviour?
• Which fields will be validated on server side? What will be the failure behaviour?

Design database tables for user, cause and key contact

There are common fields among user, cause and key contact. Design possible inheritance & association relationship between those entities.

Create required controllers and views for UC2-Registration

Create a notification container that can be reused in any pages

Alerts would be useful for notifying users about the actions performed and failures. A global container can be put in a proper template and that segment can be reused in the pages throughout the application.

Create TaskService and implement TaskService#save() and TaskService#publish()

Description

TaskController will communicate with TaskService in order to commit new task requests. Hence, a service is needed for handling task related requests. First step is to provide save and publish services as described in UC3 Create task

There are a few examples implemented already in the service layer.

Task list

• Create TaskService interface in org.crowdguru.service.domain
• Realize TaskService in org.crowdguru.service.domain.impl
• Provide a gateway to consume JPA repositories org.crowdguru.service.gateway
• Create a POJO request DTO in org.crowdguru.service.request
• A stub service implementation would be useful for testing and development purposes.

Implement an acceptance test for UC2-Register

Test should verify according to the acceptance criteria defined in the use case.

A new test will be created in the acceptance module.

Related with #23.

Create a page for new task entry form

Description

A form is required to meet UC3-Create task needs.

Task list

• Put required fields according to the description in the use case. This page should be located in "tasks/create.html"

Add sectors dataset

Add terms of condition confirmation to the registration page

Investigate dependency management libs for css

Implement server side logic for UC2-Register

Release 0.0.1-SNAPSHOT

Description

Make a new release at the end of the sprint

Implement user, cause and key contact entities

Consider #21 for this implementation. datastore needs to be ready for new registration

Complete RegisterController#add() and RegistrationRequest

Description

Server side needs to handle all of the fields in the registration page. UC1-Create account has been changed since the last sprint. Also controller needs to inform front-end if anything goes wrong throughout the committing process. Omitting validation requirements on the server side, it is enough to check if submitted email address is unique or not.

Task list

• Add missing fields, getter and setters to RegistrationRequest according to UC1
• Implement exception handling and check return value from the service layer after calling register. If it fails, return proper error message to be used for notifying end users
• Before calling register, ensure that there is no account with the submitted email. If there is, stop the process and return error

Deploying automatically from Travis-CI

As a part of continuous integration, our builds should be deployed automatically from Travis-CI if it succeeds.

With this, any merge to master will be deployed to cloudfoundry automatically from Travis-CI.

Investigate importing possibilities from external web applications for UC2-Register

It might be useful for users to retrieve some fields from other web applications while registering. Possible applications:

• Linkedin
• Facebook

Possible fields:

• Skills
• Sectors
• Personal fields

Investigate how this can be done.

Extend RegistrationService#register() to create a cause if provided

Description

If a Key contact is creating an account, he/she might provide new cause. A cause will be created and associated with Key contact in that case as described in UC1-Create account. Current implementation does not capture this requirement.

Task list

• Inject CauseService into RegistrationService and create cause by checking related fields in the passed RegistrationRequest
• Implement CauseServiceImpl to create new Cause

Investigate dependency management libs for js

Create an independent module for acceptance tests

Acceptance tests will be used to verify functional specifications.

Add a "Create task" link to the navigation banner for Key contacts

Description

When a Key contact is logged on, a link on the navigation banner should be present which is mapped to "/tasks/create". When clicked, a form will be loaded for creating a task initiating UC3-Create task

Please note that this link will be visible and enabled only if a Key contact is logged on. For Guru and anonymous users it shouldn't be there.

Task list

• Put a link to the navigation bar as described above and map to /tasks/create
• Create a controller, map it to /tasks/create for HTTP GET requests and render an empty view. View will be located in "tasks/create.html"

Create "Task" entity to store tasks

Description

Create a new entity in the data layer to represent tasks. UC3 Create task includes required fields.

Task list

• Create Task class in org.crowdguru.datastore.domain
• Inject setters and getters
• Write unit tests to test fields.
• Extend integration tests

Add missing fields to the registration page

Description

Use case has been changed since the last sprint. The latest version is here

Please do not take validation parts into account now. First iterations are focused on providing basic functionality. Technical specifications need to be detailed.

Task list

• Add missing fields which are common to Guru and Key contact
• Add type specific missing fields
• Make type specific fields visible only if related account type is selected (very basic)
• Use XHR to post form data and notify user about the result (very basic)

Create TaskController to handle task requests from view

Description

A controller need to perform task actions. UC3-Create task describes the flow. In this iteration; create, save and publish actions will be handled omitting validation

Task list

• Create TaskController in org.crowdguru.webapp.controller. Map to "/tasks" from the top class
• Implement TaskController#create() for HTTP GET requests to render task creation form. Map to /tasks/create This might be already there if #35 resolved. Finish implementation in that case
• Implement TaskController#save() for HTTP POST requests omitting validation parts and map to "tasks/save"
• Implement TaskController#publish() for HTTP POST requests omitting validation parts and map to "tasks/publish"

Create UC9-Offer help

UC9 needs to be ready for the sprint 3.

Clarify UC2-Register

• Create a wiki page for storing use case
• Work on UC2-Register and define it as a flow
• Get rid of unclear requirements