The Lab
star_faded.png
Please log in to subscribe to updates for this article
The Lab:Development:Starting Software Projects:Creating Projects In The Lab
Last updated at Tue Mar 04 00:06, by Sharron Denice

Introduction  ⇑ top

Creating projects in The Lab requires administrator permissions. If you need administrator privileges then submit your request via the Team Tasks List project.

A project is needed for every project that requires development. There are three different types of projects in The Lab.
  1. Software Projects
  2. Team Projects
  3. Parent Projects (contains multiple software projects)
Based on the project permissions and settings will need to be managed accordingly.

How to start creating a project  ⇑ top

You can create a project by clicking on Manage Projects on The Lab front page. On the page, enter in a project name and click Add. Once the project is added it will be placed in the Existing projects section.

Specifying project details  ⇑ top

On the Manage Projects page, find the project that you created and click on Edit Project. The details of the project depends on the project type. All projects require an issue prefix which must be three (3) characters long.

Quick Edit Details  ⇑ top

  1. Software Projects
    1. When editing project details in the Quick Edit you will need to supply all details. Software projects require a key, issue prefix and project description. For addon and plugin projects the key must have the format (parent_project_key)-(any_key). The suffix key for the project can only be three (3) characters long. For example, for an addon project which is a child of Project Microsoft with a project key of microsoft, the addon project key might be, microsoft-123.
  2. Team Projects
    1. When editing project details in the Quick Edit you will need to supply all details. Team projects require a key, issue prefix and project description. For sub-projects the key must have the format (parent_project_key)-(any_key). The suffix key for the project can only be three (3) characters long. For example, an events sub-project which is a child of Project Team with a project key of team, the sub-project key might be, team-events.
  3. Parent Projects (contains multiple software projects)
    1. When editing parent project details in the Quick Edit you will only need to specify a key and project description. Parent projects can be any length but for usability, please keep the project key short.

Advanced Project Settings  ⇑ top

All projects require that an icon be added according to the project type. From the Quick Edit window click on More Settings. After the page loads, click on Settings.

Project Details  ⇑ top

Most of display settings have been populated from the Quick Edit window. However, the following need to be done BEFORE creating a project in The Lab.
  1. Create the product in the Market Place, Mark the product as hidden until the product's project is added to The Lab.
  2. Note the product URL (format: http://www.letaprodoit.com/index.php?dispatch=products.view&product_id=249). The Product URL will be used as the Homepage URL for Software Projects.
  3. Note the category URL (format: http://www.letaprodoit.com/index.php?dispatch=categories.view&category_id=260). The Category URL will be used as the Homepage URL for Parent Projects.
  4. Project icons need to be associated to the project based on it's type.
    1. Software Projects - See Software Project Icon in Attachments Section
    2. Plugins/Addon Projects - See Plugins/Addon Icon in Attachments Section
    3. Software Request Projects - See Software Request Icon in Attachments Section
    4. Team Projects- See Team Projects Icon in Attachments Section
    5. Website Projects- See Website Projects Icon in Attachments Section

Display Settings  ⇑ top

Keep the default settings except for the following:
  1. Software Projects: Show Project Downloads: Yes
  2. Team Projects: Show Project Downloads: Yes
  3. Parent Projects (contains multiple software projects): Show Project Downloads: No

Advanced Settings  ⇑ top

Keep the default settings except for the following:
  1. Software Projects
    • Enable Releases: Yes
    • Allow Issues to be reported: Yes
    • Issuetype scheme: Primary issuetype scheme
  2. Plugins/Addon Projects
    • Enable Releases: Yes
    • Allow Issues to be reported: Yes
    • Issuetype scheme: (Depends on parent project) Currently there are three (3) issue types in The Lab for CS-Cart, WordPress and Joomla and the issuetype will be based on the details of the parent project. Seperate issuetypes are necessary because plugins/addons are based on an existing software application and fields such as versions and editions need to be supplied when submitting issues.
  3. Software Request Projects
    • Enable Releases: No
    • Allow Issues to be reported: Yes
    • Issuetype scheme: SR issuetype scheme
  4. Team Projects
    • Enable Releases: No
    • Allow Issues to be reported: Yes
    • Issuetype scheme: Task issuetype scheme
  5. Website Projects
    • Enable Releases: No
    • Allow Issues to be reported: Yes
    • Issuetype scheme: Primary issuetype scheme
  6. Parent Projects (contains multiple software projects)
    • Enable Releases: No
    • Allow Issues to be reported: No
    • Issuetype scheme: Primary issuetype scheme

Team  ⇑ top

All projects must have the TSP Admin set as the project owner. If the project has a client then you must assign the user to the team. The rest of the team assignments will be set after the sprint planning meeting.

Roles & Permissions  ⇑ top

Keep the default settings except for the following project types:
  1. Software Projects: Default Settings are OK
  2. Team Projects
    • Can see the project exists: (No one can, except Team & Administrators)
  3. Software Request Projects
    • Can create issues, edit basic information on issues reported by the user and close/re-open them: (Everyone can, except Users, Guests, Clients)
    • Can access all project pages: (Everyone can, except Users, Guests, Clients)
  4. Parent Projects (contains multiple software projects)
    • Can see the complete project hierarchy: (No one can)

VCS Integration  ⇑ top

Keep the default settings except for the following:
  1. Software Projects
    • Enable VCS Integration
    • Enable workflow
    • Access method: HTTP (enter details)
      • HTTP Passkey: Ask team lead for PassKey or establish a PassKey if team lead (Use Password Generator with all options checked and make the password length AT LEAST 8 chars)
      • Repository URL: See Configuration Management Category to continue to setup a repository for revision control. Keep note of the Project ID
    • Set Repository browser to the appropriate repository (GitHub for Public Repositories, BitBucket for Private Repositories)
  2. Team Projects: Disabled
  3. Parent Projects (contains multiple software projects): Disabled

Project Milestones/Sprints  ⇑ top

We added a listener to the /core/classes/TBGContext.class.php class to use to automatically insert milestones and sprints into the database.
  1. protected static function setupCoreListeners()
  2. {
  3. TBGEvent::listen('core', 'TBGFile::hasAccess', 'TBGProject::listen_TBGFile_hasAccess');
  4. TBGEvent::listen('core', 'TBGFile::hasAccess', 'TBGSettings::listen_TBGFile_hasAccess');
  5. TBGEvent::listen('core', 'TBGProject::_postSave', 'TBGProject::listen_CreateDefaultMilestones'); //Modified by TSP
  6. }


The listener is implemented in the /core/classes/TBGProject.class.php class.
  1. /**
  2. * Add in default milestones each time a project is created
  3. * @param \TBGEvent $event
  4. * @return none
  5. */
  6. public static function listen_CreateDefaultMilestones(TBGEvent $event)
  7. {
  8. $project = $event->getSubject();
  9. $project_milestones = $project->getMilestones();
  10.  
  11. if (empty($project_milestones))
  12. {
  13. // Default values
  14. $default_milestones = array(
  15. 'name' => 'Concept approval',
  16. 'itemtype' => 2,
  17. 'description' => 'Feasibility studies and basic system concepts have been approved by management and the project is authorized to proceed to detailed requirements definition.'
  18. ),
  19. 'name' => 'Requirements review',
  20. 'itemtype' => 1,
  21. 'description' => 'Requirements specifications are complete, correct, approved and suitable for input to design.'
  22. ),
  23. 'name' => 'Preliminary design review',
  24. 'itemtype' => 1,
  25. 'description' => 'The architectural design satisfies all product requirements, is approved and is suitable for input into the detailed design process.'
  26. ),
  27. 'name' => 'Critical design review',
  28. 'itemtype' => 1,
  29. 'description' => 'Detailed designs fully implement the system architecture, are approved and are suitable for input into the development of code.'
  30. ),
  31. 'name' => 'Test plan review',
  32. 'itemtype' => 1,
  33. 'description' => 'Test plans are adequate for the testing of all product features, are approved and are suitable for input to the development of test cases and test procedures.'
  34. ),
  35. 'name' => 'Test readiness review',
  36. 'itemtype' => 1,
  37. 'description' => 'Developed and unit tested software has been passed by the test team and is suitable for input into integration testing.'
  38. ),
  39. 'name' => 'System test review',
  40. 'itemtype' => 1,
  41. 'description' => 'The software product has passed system testing and is suitable for input into acceptance testing.'
  42. ),
  43. 'name' => 'Operational readiness review',
  44. 'itemtype' => 1,
  45. 'description' => 'The software product has passed acceptance testing and is suitable for deployment in its target production environment.'
  46. ),
  47. 'name' => 'Product operational',
  48. 'itemtype' => 1,
  49. 'description' => 'The software is in use in its target operational environment.'
  50. ),
  51. 'name' => 'Documentation review',
  52. 'itemtype' => 1,
  53. 'description' => 'The software documentation is approved and is suitable for release with product.'
  54. )
  55. );
  56.  
  57. try
  58. {
  59. $pid = $project->getID();
  60.  
  61. foreach ($default_milestones as $dms)
  62. {
  63. $milestone = new TBGMilestone();
  64. $milestone->setName($dms['name']);
  65.  
  66. // create a sprint milestone
  67. if ($dms['itemtype'] == 2)
  68. {
  69. $milestone->setType(TBGMilestone::TYPE_SCRUMSPRINT);
  70. }//endif
  71. // create a regular milestone
  72. elseif ($dms['itemtype'] == 1)
  73. {
  74. $milestone->setType(TBGMilestone::TYPE_REGULAR);
  75. }//endelseif
  76.  
  77. $milestone->setProject($pid);
  78. $milestone->setDescription($dms['description']);
  79. $milestone->save();
  80.  
  81. }//endforeach
  82. }//endtry
  83. catch (Exception $e)
  84. {
  85. throw new InvalidArgumentException("Unable to create default milestones");
  86. }//endcatch
  87. }//endif
  88.  
  89. $event->setReturnValue(true);
  90. $event->setProcessed();
  91. }
Details can be found in issue #WWW-9.

The sprint milestones added are as follows:
  1. Concept approval (Sprint) - Feasibility studies and basic system concepts have been approved by management and the project is authorized to proceed to detailed requirements definition.
  2. Requirements review (Milestone) - Requirements specifications are complete, correct, approved and suitable for input to design.
  3. Preliminary design review (Milestone) - The architectural design satisfies all product requirements, is approved and is suitable for input into the detailed design process.
  4. Critical design review (Milestone) - Detailed designs fully implement the system architecture, are approved and are suitable for input into the development of code.
  5. Test plan review (Milestone) - Test plans are adequate for the testing of all product features, are approved and are suitable for input to the development of test cases and test procedures.
  6. Test readiness review (Milestone) - Developed and unit tested software has been passed by the test team and is suitable for input into integration testing.
  7. System test review (Milestone) - The software product has passed system testing and is suitable for input into acceptance testing.
  8. Operational readiness review (Milestone) - The software product has passed acceptance testing and is suitable for deployment in its target production environment.
  9. Product operational (Milestone) - The software is in use in its target operational environment.
  10. Documentation review (Milestone) - The software documentation is approved and is suitable for release with product.


Article attachments

  • /public/files/show/114
    software.png uploaded Mar 03, 2014 by unknown user
  • /public/files/show/115
    diagram_v2_10.png uploaded Mar 03, 2014 by unknown user
  • /public/files/show/116
    system_software_installer.png uploaded Mar 03, 2014 by unknown user
  • /public/files/show/117
    folder.png uploaded Mar 03, 2014 by unknown user
  • /public/files/show/118
    web.png uploaded Mar 03, 2014 by unknown user

Article comments (0)

There are no comments