Feature Requests

Would love to see a feature in ClickUp that could be used to request changes and then designated people could approve or deny them and assign the task accordingly

We want subtasks to remain the basic "task" icon, not inherit the task type of the parent task. This could be a toggleable option in settings, for those who like subtasks inheriting task types from tasks. For example, we might have a contract template as a task with task type "resource," which we are using to track through our document development and maintenance system. We like that we can use the "resource" task type to differentiate it from actionable tasks, but then when we add a subtask like "update footers on this version", it defaults to a resource task type when it IS an actionable item.

Would be great to see the task type symbol in calendar view to differentiate between tasks, milestones, holidays etc.

I add a lot of subtasks to lineup, and I would love to be able to see the parent task above the subtask I added to help me out!

Being able to color the tasks on the calendar by the Task Type would be a great feature. I could see this meaning you set the color when you create the Task Type - default is gray but you could change the color, which would reflect on Calendar Views (Color tasks by Task Type) and icons.

It would be great if we could make a Task be a Subtask when it is in a different Space (and vice-versa). For example, you take Task 1 in Space A and make it a Subtask of Task 2 in Space B. When you open Space A, it is a Task. When you open Space B, it is a Subtask. This would be useful for building a Goals system, where you have a Goal that is a Task in Space A, broken down in to Subtasks underneath it. But then you want that Goal to be a Sub-Goal of a main Goal in Space B. This is not possible to do right now. You have to create a lot of duplicates to get this kind of functionality.

i would like to have an admin for each task based on the nature of the task, up to me to choose whether the whole workspace tasks are administered by the workspace creator or by the user who created the specific task, so that other people can have attachments to the task and write comments but not change the status or mark the task as completed, but they just can provide a request to have it completed but make the task as it is until the task admin confirms the request to mark as completed.

Hello, One idea I had is to be able to set a guide or a "How to fill" by task type, that we display when creating or modifying the task. It could ensure some soft rules about custom fields, but also give some information on how to fill it, based on team's guidelines, workflow, or even tutorials / technical documentation, link to the task type. It could be also some piece of information linked to specifics custom fields that we can reuse in different tasks. It could be an other solution, but the result would be less understandable if it depends on the context (task type). For example for bug reporting: https://github.com/godotengine/godot/issues/new?assignees=&labels=&projects=&template=bug_report.yml Would make echos with : https://feedback.clickup.com/feature-requests/p/add-requirements-before-status-changes https://feedback.clickup.com/feature-requests/p/required-mandatory-fields-to-close-a-task-including-comments https://feedback.clickup.com/feature-requests/p/make-standard-fields-required-when-creating-a-task https://feedback.clickup.com/feature-requests/p/statuses-by-task-type https://feedback.clickup.com/feature-requests/p/custom-fields-by-task-type This solution could serve as user documentation for the features above.

we use Item Types, but we often encounter situations where we need to clearly distinguish between current and previous revisions. To improve this, we need to add the following features: Revision Distinction in Relationships: Relationships should be able to clearly express connections between items of different revisions. Users need the ability to specify particular revisions when defining relationships. User-Defined Revision Management: Users should be able to assign unique names to each revision. When specifying revisions, users should be able to use either names or automatically generated identifiers. UI/UX Improvements: Implementation of an intuitive interface for revision selection and management is necessary. We need to provide a way to visually distinguish between current and previous revisions. Data Model Modifications: Addition of fields to store revision information in the Item Type is required. Implementation of revision reference functionality in the Relationship model is needed. Performance Considerations: We must minimize performance degradation in database queries due to revision management. If necessary, we should establish an indexing strategy. Through this feature enhancement, users will be able to manage and reference item revisions more accurately, which will greatly improve the data accuracy and usability of the entire system.