What exactly is the difference between a task and a ticket, and why is it necessary to separate between the two?

I'm asking because generally it is best to keep things as simple as possible, and these tabs within the project management seem to overlap a lot in terms of features and use, without having any clear distinction. That can confuse users, seemingly without adding any significant value. Both seem to create a task node, and are principally about something that needs to be done. Why not consolidate the two into just one type, called "Ticket"? A ticket, with the help of attributes such as type and category, can describe everything from a bug to a feature request, and would therefore be able to cover a wide variety of use cases.

(Consolidating these would also free up space for other tabs, which in itself is a valid point to take into account here.)

Comments

manuelBS’s picture

manuelBS CreditAttribution: manuelBS commented

Right you are, we are actually discussing this issue in our internal daily use of ERPAL. The intent was to have development in one "queue" the tasks. Developers shoul work with these tasks and should not be interupted by tickets a customer adds as support requests. And in some cases may be the customer should not see all tasks but tickets so we thought its a good practise.
But as you describe to give tickets (or tasks, howevery they will be called) a category or type, a user can filter to just see all feature requests and if we limit access to a customer to only see his own tasks, we have access control for that.

sigveio’s picture

sigveio CreditAttribution: sigveio commented

Yep, exactly; filtering options for the ticket list solves that issue. Users would have one type of reporting to relate to, keeping the interface sleek and intuitive, while the developers and others are be able to narrow the list down to whatever might be relevant to them at any given time. :)

Keeping that separation purely filter based also allows for a lot of flexibility, which is a good thing.. because not everyone have clearly defined roles, and some times people also have to cover for their colleagues and combine their ticket queue with their own.

The important thing here, unless all activity under a project is meant to be completely transparent to the customer in all cases, would be to keep customers from seeing tickets they shouldn't see. That would demand for fine grained privilege separation. For an example being able to use a checkbox upon creating a ticket to toggle whether or not the customer assigned to the project should see a given ticket and it's content/children. (With the "internal" option checked by default, and appropriate visible warning if the ticket is set to be customer visible, to avoid unfortunate mistakes.)

Anybody’s picture

Anybody
Primary language German
Location Porta Westfalica
CreditAttribution: Anybody commented

hoesi, your points are very good! I agree that things should be kept as possible and that there should be an easy selection in visibility aspects.

My suggestion:
Add a select like "Assigned To Users" which only allows "read access" / "notifications". If a ticket is created by a user then he should self-subscribe. That's very flexible and can be used internal and external. Furthermore it fits the typical needs in projects (see RAM: http://en.wikipedia.org/wiki/Responsibility_assignment_matrix)

Anybody’s picture

Anybody
Primary language German
Location Porta Westfalica
CreditAttribution: Anybody commented

In addition: May I ask for some documentation regarding the already existing features? For example how can I cleanly allow clients to create tickets and is an email integration already existing (mail tickets?) - I could not find anything about that. Perhaps a good starting point for the next webinar? :)

andrisek’s picture

andrisek CreditAttribution: andrisek commented

Hey Anybody,
i am going to make a screencast about adding customers to projects for ticketing. I think I will do it at this friday. I will post it also here.

Edgar Saumell’s picture

Edgar Saumell CreditAttribution: Edgar Saumell commented
Version: 7.x-2.x-dev » 7.x-2.0-alpha2

I guess this is the screencast that andrisek was talking about: http://www.youtube.com/watch?v=eW1ee3fwKY0

Be aware of #1952686: Permissions not working solution is at #4

andrisek’s picture

andrisek CreditAttribution: andrisek commented

Yes that is the right screencast. We found the source of this permission bug and will fix it soon.

andrisek’s picture

andrisek CreditAttribution: andrisek commented
Issue summary: View changes
Status: Active » Closed (works as designed)

Closed due inactivity.

sigveio’s picture

sigveio CreditAttribution: sigveio commented

Closed due to "inactivity" you say... but out of curiosity; what happened with the original issue reported here? From what I can see it was awaiting the outcome of an internal discussion at Bright Solutions (see #1), so your reason for closing (without any comment on the issue itself) doesn't make much sense to me.

As a disclaimer I can add that I've personally lost interest in ERPAL and I am therefore not up-to-date on changes made since. I just feel that the issue brought up in the original post, and discussed in comments #1 and #2 (before it derailed a bit), flagged a valid concern. If it has not been addressed yet, and no final decision has been made on what to do with it, inactivity in itself isn't really a good/valid reason to close it. On the other hand... if the issue has been addressed in the meantime, or you have decided to leave it as is... it would be reasonable to point this out / explain the outcome when closing the ticket. That's just common courtesy to the people who take their time to report things and/or follow the issue. :-)

andrisek’s picture

andrisek CreditAttribution: andrisek commented

Like ManuelBS said before, the main difference for those two is the handling when the people are working with it. In our daily work it was established really well, that we have tasks and tickets, because everything related with the customer is directly a ticket and the internal work is addressed with tasks.
So we did not find a reason to sum everything up into one tab. I hope this provides some more informations, why I closed this task.

manuelBS’s picture

manuelBS CreditAttribution: manuelBS commented

@hoesi if you have any other concrete question (or anyboedy else in this issue) you are always welcome to ask.

Anybody’s picture

Anybody
Primary language German
Location Porta Westfalica
CreditAttribution: Anybody commented

The explanation in #10 is great and I think it will help many people.
Perhaps you should think about to point that out in a kind of "help" or info text in the ERPAL UI?

This point was not THAT clear to me before in such a technical view. We used tickets and tasks as you described, but it was more driven by "is it a bug or not"...

andrisek’s picture

andrisek CreditAttribution: andrisek commented

Ah okay. Yes Anybody, with the beta release will also beginn with the documentation. We have some videos, but I think it is also good to have some written text for the overview. Glad I could help.

manuelBS’s picture

manuelBS CreditAttribution: manuelBS commented

So just to bring it to the point how we use it:

Task: Developers queue (should not be interrupted by customer requests)
Tickets: Customer and support queue for "everything that is related" to the project but needs to be evaluated by for example a manager

From a ticket you can either create a subtask (to put the ticket in development with the final agreement and specification) or you can uncheck the checkbox "Is ticket" and you ticket will be put into the task queue. Hope this helps again.

Anybody’s picture

Anybody
Primary language German
Location Porta Westfalica
CreditAttribution: Anybody commented

Thanks a lot. Perhaps we should re-open this and set it to "documentation" as reminder?

Of course I don't mean to write a handbook or so - which perhaps nobody will read or that will be hard to keep up to date - I think a better solution would really be to put that somewhere into the direct UI where you use it. For example the node type description that appears if you create a task / ticket... we can discuss that :)

andrisek’s picture

andrisek CreditAttribution: andrisek commented
Component: Miscellaneous » Documentation
Status: Closed (works as designed) » Needs work

Good idea, I just added this to documentation.

camoa’s picture

camoa CreditAttribution: camoa commented

How is this look from the point of view of the CRM? I believe this can be a full CRM system including following opportunities as a project.

I mean do you have any ideas in the use of tasks as part of the opportunity development?

manuelBS’s picture

manuelBS CreditAttribution: manuelBS commented

I dont understand exactly what your question is. What do you want to do with tasks regarding opportunity development?

camoa’s picture

camoa CreditAttribution: camoa commented

Can we chat in Skype? Thanks. Email me please.

andrisek’s picture

andrisek CreditAttribution: andrisek commented

Sure.. you can add yourself a task to follow the contact in your crm. But why not use the activities for that?

camoa’s picture

camoa CreditAttribution: camoa commented

The contacts and activities, have you thought on joining with crm_core?
I am working on a sales oriented CRM. and have some ideas :)

manuelBS’s picture

manuelBS CreditAttribution: manuelBS commented

About CRM Core it would be interesting which ideas you have as in ERPAL 3 that we started to develop a view days ago, we will use CRM Core.