GitHub Community
[Projects Beta] Support "Multi select" field #6580
Replies: 20 comments 12 replies
-
|
I'm currently working on a larger application and we divide it into broader components. To reflect these components we use a single-select, but several times issues arise which are related to multiple components at the same time. A multi-select would better reflect this instead of insanely adding multiple single-selects or circumvent the absence of a multi-select by messing up issue labels which would have to be duplicated into multiple repositories. |
Beta Was this translation helpful? Give feedback.
-
|
We don't need to explain this to developer 1 when developer 2 is offering this feature. Developer 1 should just include it themselves. |
Beta Was this translation helpful? Give feedback.
-
|
Multiselect would be great for us since we track which customer(s) requested/reported an issue. |
Beta Was this translation helpful? Give feedback.
-
|
Multi-select is a much-needed field for managing projects right now. Similar to assignee |
Beta Was this translation helpful? Give feedback.
-
|
Multi-select custom fields would be an invaluable feature! |
Beta Was this translation helpful? Give feedback.
-
|
We need multi-select to track with customers asked which features. This is not possible without multi-select. |
Beta Was this translation helpful? Give feedback.
-
|
Yes its much required , kindly implement the same so that we can run multiple test suites |
Beta Was this translation helpful? Give feedback.
-
|
Would love this feature as well |
Beta Was this translation helpful? Give feedback.
-
|
Requesting this as well. Critical to track which customers have requested for a feature. Should work like labels, but based on a different list. |
Beta Was this translation helpful? Give feedback.
-
|
馃挴 I cannot believe that Projects was released in General Availability without this feature. Not being able to add multiple tags is a major blocker. |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
|
Currently having to create a mashup of emojis when picking a type for the issues within our board. Multi-Select would significantly cut down on the amount of emoji mashup options I have to create |
Beta Was this translation helpful? Give feedback.
-
That's sounds good. |
Beta Was this translation helpful? Give feedback.
-
|
That's a really cool workaround, thanks for sharing 馃憤 |
Beta Was this translation helpful? Give feedback.
-
|
We really need multi-select! And have been waiting almost a year. Can it make it on the project board?? Doesn't seem too hard. You already have the "Assignee" acting like a multi-select. Generallize that behavior and your set. |
Beta Was this translation helpful? Give feedback.
-
|
This issue seems buried - but important ... it's one of your TOP requests for projects by up-votes, that hasn't been addressed. Can someone please add the appropriate tags "Projects", "Enhancement"? My team really needs this feature. |
Beta Was this translation helpful? Give feedback.
-
|
I understand that "issue" could have multi-labels, but this multi-select custom field is crucial for tasks that are not issue-ready. Perhaps there are performance/product concerns of supporting custom multi-select fields, but please do response to the community request as there are so many people voting and waiting for this feature 馃檹 馃檹 馃檹 |
Beta Was this translation helpful? Give feedback.
-
|
I work with both private and public repos - these are pulled into one project. We can't use labels to track private stuff on public issues. It is really broken. |
Beta Was this translation helpful? Give feedback.
-
|
@azenMatt - Tagging you in hopes that you might take a look at this request for a multi-select field on project boards. It is one of our top two requests for the project boards to be more useful - and it seems like the request is buried by newer requests - despite the large number of up-votes it has. Thanks for taking a look! And please add appropriate new labels. |
Beta Was this translation helpful? Give feedback.
-
|
In contrast to all the "me too, me too" comments, it would be helpful to have specific use-case examples |
Beta Was this translation helpful? Give feedback.
-
|
Plenty of use cases in the comments above. |
Beta Was this translation helpful? Give feedback.
-
|
There have been a few examples already in the earlier comments about the need for multi-select, but here are two of ours. 馃馃 for this to be discussed and added to the roadmap in some form. Identifying affected productsA product can consist of multiple repositories for various hardware and software elements, and some of these repos may be used by multiple products. Currently there is no way in Projects to categorise which products are affected by a task/issue. Single-select is not suitable because an item can (and often does) affect multiple products. Identifying relevant teamsSimilarly, an issue may (and again often does) affect multiple teams. |
Beta Was this translation helpful? Give feedback.
-
|
Like @kathy-phet I've noticed that this is now the 4th most upvoted discussion about the beta features that is still unanswered. Surely they must have thought about it when they added single-select? I don't know how difficult multi-select would be to implement, but it seems to me that the design is done (single-select but, well, multi) and it's hard to imagine the backend changes being that challenging in comparison to other features being discussed. It's making me wonder if I'm misunderstanding something - is there perhaps a practical or ideological reason that multi-select should be avoided in this kind of interface? Or could similar functionality be being reserved as part of a higher-paying tier? I'm absolutely not suggesting that this feature has to be a priority, of course Github can prioritise feature development as they wish. But it just seems a bit odd to me that there has been no response from them at all after over a year, given that so many people seem to have such an obvious need for it. I wonder if I'm missing something, or if there has been a response elsewhere? |
Beta Was this translation helpful? Give feedback.
-
|
Hey @justyn, Thanks for taking the time to provide this feedback and also for your generous patience with us. Let me give an update here: The short answer is adding new field types is not an easy lift for our team at the moment. In fact, it's actually quite hard as we learned from the last time we added a new field type. The team understands this feature would unlock a lot of value for our customers and it's high on the backlog but we need to land a few updates to our platform that would make adding new field types easier first. Trust that we are readily aware of this gap as Projects users ourselves and are regularly evaluating whether it makes sense to do this the "hard but sooner way." For the moment, we're making the choice to try to accelerate many new types of fields in the future by investing in our platform now. I know that doesn't solve the problem at hand for everyone needing multi-select but I hope this provides some context - we want to do this, it's just a matter of time and sequencing. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @2percentsilk for responding, and for the background context, it's appreciated! It's very good to know that this feature is also seen as important within Github and that it forms part of your roadmap. I look forward to using it when it's ready (or even before!) Thanks again |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
|
Every other modern software project management system supports this capability for custom fields. I understand it's a lot of work, but please do prioritize it. We've considered moving away from projects just because of this one missing capability. |
Beta Was this translation helpful? Give feedback.
-
|
This is the major reason we're not using GH Projects at my company. Even when using it in my personal projects, sometimes it's difficult to attribute a particular issue into a single field, where multiple are needed. Please prioritise it, if possible |
Beta Was this translation helpful? Give feedback.
-
|
Hi @2percentsilk is it possible to get a 9-month update on this? Any progress towards multi-select becoming available? Thank you! |
Beta Was this translation helpful? Give feedback.
-
|
I hope this can be prioritised sooner than later. While not it is not something ground-breaking, it is definitely a blocker. Almost all of our work is on GH, and given the advantages of a tight int茅gration, I'd like to move from my project organisation over here as well. Using something like clickup just for the sake of minor QoL features feels a bit wasteful |
Beta Was this translation helpful? Give feedback.
-
|
Just realised that the |
Beta Was this translation helpful? Give feedback.
-
|
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! |
Beta Was this translation helpful? Give feedback.
-
|
Would love this feature (or even a solution/workaround). In our case, we are building various reusable components that make up a website or an app, and want to be able to track all the pages that the component lives on and filter the "Tasks" view. A multi-select would be the easiest solution, but I am open to other workarounds. |
Beta Was this translation helpful? Give feedback.
-
|
Why work around? |
Beta Was this translation helpful? Give feedback.
and others
{{title}}
-
In my company, for instance, we often create issues that span different areas of development (i.e. design, frontend, backend, etc), and we would like to manage this attribute as a multi-select field.
Ideally, those issues can be divided into smaller subordinate issues for each area, but we tend to do so as we go.
This could also benefit the scenario where users want to manage issues that concern multiple teams.
Beta Was this translation helpful? Give feedback.
All reactions