Combine ticket and task content types to a single content type

bumping priority.

While working on a migration path i realized it would be rude to handle the migration by pm automatically.

If the fields in task and tickets are same, it would not be an issue. But we cannot make that assumption. It could happen that after installing Drupal PM, some fields could be have been added in Task but not in Ticket or vice-versa.

So how about just informing the user to stop using pmtask and pmticket. Also in order to use the awesomeness of 7.x-2.x they would have to migrate pmticket and pmtask to pmissue using this excelllent contrib module called Node Convert (node_convert)

Also the site admin might need some time to adjust permission and other stuff with the new content type (pmissue) before it is migrated.

A) For New installation of Drupal PM.
We can remove pmtask and pmticket from the project.

B) Upgrading from storm or 1.x version of pm.
pmtask and pmticket have to be present for updating. Further they need to be present when using "Node Convert" along with pmissue.

As you can see from "2", we need both pmtask and pmticket to be present along with pmissue for those who want to upgrade.

Proposed Solution:
1.) Move pmtask and pmissue to separate project with development status "obsolete".
2.) Create a documentation page to explain the upgrade process.
3.) pmtask and pmticket could warn the user about the need to migrate in http://www.example.com/admin/report/status page as shown in below image.

It wouldn't be bad to keep the projcet and task types as an option to enable or disable by configuration.
I use this for a classification. We have organization, then project -In my opinion it's a name for the software installtion, or a database name. In one org. they're multiple SQL database installations or software distributions. Task we have renamed as Module, it contains list of purchased modules per project or organization. In the new ticket form, each user have to select name of the project (if there's more than one), and the appropriate module for which the problem or request belongs. All requests (tickets) are well arranged and could be easily filtered in the ticket view.
Thanks.

Hi @roxor,

So basically you have a hierarchy like below.

Project (pmproject)-> Module (pmtask) -> Ticket (pmticket).

Let me try to explain what "Combine ticket and task content types to a single content type" means.
1.) In Drupal PM, Task and ticket node would be replaced by Issue nodes. (Similar to what drupal.org does ).
2.)All default workflow and views would be based on Issues (and not Task/Ticket)

What it does not,
1.) Drupal PM doesn't Stop the site admin from designing more content types to interact (reference) with Drupal PM.
2.) Drupal PM doesn't stop site admin from changing or creating more workflow to play along with Drupal PM.

Thus in your use case, i would suggest, you can ignore the warning mentioned in #6. Enjoy.

Hi D34dMan, thanks for explanation.
I don't know if I understood well, so in the Issue node will be lost the relation based on pmproject and pmtask.
For a test I have installed copy of production Drupal into virtual machine and tried to migrate PM into ver. 7.x-2.x.
But all classification settings in the new ticket form are lost. So I have to stay with ver. 7.x-1.x.
In the capture.png is an example of my new ticket form ver.1.x. In the new version of PM I can see only parent array, which doesn't make me a sense, there is only mixture with one or two pmprojects and 5-6 pmtickets (maybe most recent tickets).

But all classification settings in the new ticket form are lost. So I have to stay with ver. 7.x-1.x.

Please report it as a bug. with details how to reproduce it. We are trying to support proper migration from 7.x-1.x to 7.x-2.x with no data loss.

"Project Management" takes on different forms depending on the industry to which it is applied.

There are several Drupal modules which have been developed over the years to provide structure to project management activities, and in so doing provide an organized workflow toward solving problems using Drupal. A good summary of these modules can be found here --> https://groups.drupal.org/node/17948 where PM stands out as "A complete project management package ... "

Historically, PM (aka Storm in D6 world) has supported a WBS workflow. The original developer concisely explains how to use it here ...

I use tasks to register and schedule only deliverables, not to schedule every single piece of activity.
I use tickets to register requests by the customers and to plan the steps necessary to complete a task.
You can see tickets as your todo list, whilst tasks are the components of your project.

Another popular external tool, developed by the founder of Facebook, is Asana. Comparing Asana to ' Trello, Jira & PivotalTracker ' you'll see that Jira breaks Projects into "Issues", Trello breaks Projects into "Checklists", and PivotalTracker breaks Projects into "Stories". Asana is most like the present PM (Storm) in that it breaks Projects into "Tasks".

Seth Brown, the COO @ Lullabot describes in detail "A Typical Work Breakdown Structure" in his blog post "The Art of Estimation". The Number Spreadsheet he makes available there is comprehensive for Drupal projects. Using the Drupal PM module I have replicated this and use it as a PM template for setting up new Drupal projects that I want to manage using the PM module. I also use Jira and Asana routinely. I think Asana feels most like Drupal PM in that the work gets accomplished as Tasks. But unlike PM, if the task is a big one, you break it down into smaller, and smaller tasks which become hard to find.

For me, the best way to manage larger projects is to break them down into about 4 main primary tasks, something like Project Management, Design, Features, and Infrastructure. The idea is to give ALL people logging time to a project a place for them to account for their time, and then to see how that contributes toward project completion. While I really like the Lullabot WBS, it has too many tasks IMO, so I treat them as "subTasks" of sort, and group them into 3-5 primary tasks. Sometimes, the primary tasks are simply based on when deliverable defined in the project scope are invoiced, (i.e. deliverable #1, 2 & 3).

There is a great misconception out there that somehow if you use Agile methods like scrum for project management, then you can’t use Work Breakdown Structure (WBS) and will miss out its great benefits. This is not true and in fact Agile methods benefit greatly by using work breakdown structure for task management.

(ref: http://blog.binfire.com/2013/08/can-i-use-work-breakdown-structure-in-ag...)

So to strengthen PM, it seems like the better issue to address would be to improve support for subtasks, rather than doing away with them altogether ending up with a mess of issues to try and organize and address.

If the intent of this issue it to move PM away from WBS towards specifically Agile, then maybe a good way to handle it would be to fork the dev into a new "agile" branch, say -3.0 ?

Regarding creating a new release branch 7.x-3.x

TLDR; Not Required.

Long Version:
PM Task and PM Ticket have been deprecated. Means you "can" use them but please "may" not. Those modules are still available and compatible with 7.x-2.x Drupal PM suite. It is marked to be deleted in next major version. Marking them as deprecated in 7.x-2.x serves a lot of sense. It gives the old users a chance to use 7.x-2.x with PM Task and PM Issue, but still discouraging new users from enabling them. (@juliangb's comment in #14) We are even ready to help people migrate from PM Task and PM Ticket to PM Issue. Please open a ticket elaborating the use case.

So to strengthen PM, it seems like the better issue to address would be to improve support for subtasks, rather than doing away with them altogether ending up with a mess of issues to try and organize and address.

Work in Progress