Targetprocess

Targetprocess Help Desk

  • Select a product
  • Targetprocess Help Desk
  • Targetprocess Android
  • Targetprocess iOS
  • TauCharts
Michael Dubakov
  • Settings
  • Logout
  • Ideas
    • Ideas
    • Issues
    • Questions
    • Top
    • My
  • Issues
  • Questions
  • Top
  • My
Sort by Votes
  • Any Status
  • Under Review
  • Approved
  • Started
  • Done
Any Status
  • Any Status
  • Under Review
  • Approved
  • Started
  • Done
  • 536 Votes
    25 Comments

    Undo / Undelete action

    Would be nice to have undo action in gmail style: when drag-n-drop, do batch or remove smth, etc.
    Dmitry Pikhto on September 4, 2012
    Approved Approved Approved Approved Approved Approved Approved Approved ApprovedvApproved
    State was changed 3 days ago
    Michael Dubakov Founder

    Accepted, but not in the next 6 months for sure

  • 466 Votes
    103 Comments

    Automatic Rules (various) / Custom Business Rules / Rules Engine

    The idea is, to mark the parent User Story as "In Progress" as soon as a related task leaves the initial status.

    For our bug handling, we use a few states: more info, rejected, in progress, fixed, closed, etc. When a bug is finally closed, we have no way of looking into the history to find why it was closed; was it rejected initially, or was it a code fix. (I tried to create a custom report to figure this out but had no luck.)

    For our bug handling, we use a few states: more info, rejected, in progress, fixed, closed, etc. When a bug is finally closed, we have no way of looking into the history to find why it was closed; was it rejected initially, or was it a code fix. (I tried to create a custom report to figure this out but had no luck.)

    For our bug handling, we use a few states: more info, rejected, in progress, fixed, closed, etc. When a bug is finally closed, we have no way of looking into the history to find why it was closed; was it rejected initially, or was it a code fix. (I tried to create a custom report to figure this out but had no luck.)

    For our bug handling, we use a few states: more info, rejected, in progress, fixed, closed, etc. When a bug is finally closed, we have no way of looking into the history to find why it was closed; was it rejected initially, or was it a code fix. (I tried to create a custom report to figure this out but had no luck.)

    For our bug handling, we use a few states: more info, rejected, in progress, fixed, closed, etc. When a bug is finally closed, we have no way of looking into the history to find why it was closed; was it rejected initially, or was it a code fix. (I tried to create a custom report to figure this out but had no luck.)

    For our bug handling, we use a few states: more info, rejected, in progress, fixed, closed, etc. When a bug is finally closed, we have no way of looking into the history to find why it was closed; was it rejected initially, or was it a code fix. (I tried to create a custom report to figure this out but had no luck.)

    For our bug handling, we use a few states: more info, rejected, in progress, fixed, closed, etc. When a bug is finally closed, we have no way of looking into the history to find why it was closed; was it rejected initially, or was it a code fix. (I tried to create a custom report to figure this out but had no luck.)

    For our bug handling, we use a few states: more info, rejected, in progress, fixed, closed, etc. When a bug is finally closed, we have no way of looking into the history to find why it was closed; was it rejected initially, or was it a code fix. (I tried to create a custom report to figure this out but had no luck.)

    For our bug handling, we use a few states: more info, rejected, in progress, fixed, closed, etc. When a bug is finally closed, we have no way of looking into the history to find why it was closed; was it rejected initially, or was it a code fix. (I tried to create a custom report to figure this out but had no luck.)

    For our bug handling, we use a few states: more info, rejected, in progress, fixed, closed, etc. When a bug is finally closed, we have no way of looking into the history to find why it was closed; was it rejected initially, or was it a code fix. (I tried to create a custom report to figure this out but had no luck.)

    For our bug handling, we use a few states: more info, rejected, in progress, fixed, closed, etc. When a bug is finally closed, we have no way of looking into the history to find why it was closed; was it rejected initially, or was it a code fix. (I tried to create a custom report to figure this out but had no luck.)

    Show more
    Ole Fritz on February 14, 2013
    Started
    State was changed 5 months ago
    Michael Dubakov Founder

    In v.3.5.3. we've released about 20 predefined rules that you can enable.

    http://guide.targetprocess.com/settings/custom-rules.html

    Later we are going to provide a possibility to create your own custom rules. Please share your feedback!

  • 347 Votes
    16 Comments

    Multiple final states

    For our bug handling, we use a few states: more info, rejected, in progress, fixed, closed, etc. When a bug is finally closed, we have no way of looking into the history to find why it was closed; was it rejected initially, or was it a code fix. (I tried to create a custom report to figure this out but had no luck.)

    When changing defect state we can make comments mandatory which is useful. Expanding that idea, it would be useful if we also pick other fields (including custom fields) to be mandatory (so when closing we could give...

    Anup on April 2, 2013
    Under review
    State was changed yesterday
  • 332 Votes
    31 Comments

    New Help Desk Portal

    Allow customers to view Boards with Requests, add new Requests, vote for Requests, etc — without any additional license.

    Olga Ikhelis on June 20, 2013
    Started
    State was changed 6 month ago
    Michael Dubakov Founder

    UX and Implementation started this week

  • 239 Votes
    10 Comments

    Create custom entities / custom hierarchy — custom domain model

    TP2/3 is already very flexible and that's great!

    However there is still a non-customizable fixed entity structure:

    (besides bugs and test plans)
    - Request
    - Feature
    - User Story
    - Task

    Even if there is the possibility to change the name of the entities and add custom fields, in some cases it may be necessary to insert new kind of entities within the structure. This is the case of our company in which we need (to complain with ISO standards) to also manage audits, user requirements, system requierements and more independent and hierarchically dependent entities.

    By now we manage by...

    Sergio Anza on April 29, 2013
    Done
    State was changed 6 month ago
    Michael Dubakov Founder

    Most likely we postpone custom hierarchy for next year, but we are adding some flexibility into Targetprocess.

    Firs thing is Epic entity above Feature entity. If you need this functionality, please check the solution and provide a feedback, it would be really helpful! Epics implementation is started actually.

    http://www.targetprocess.com/agileproductblog/2014/09/upcoming-feature-epics-as-one-more-hierarchy-level.html
  • 1
  • 2
  • 3
  • 4
  • 5
  • ...
  • 189
  • 190
Powered by Targetprocess Inc.