4244-Kanban-Column-Menu

[Kanav-Arora]

Closes #4244

[Kanav-Arora]

Hi @charlesBochet
I'm able to create new record but not in specific Stage because RecordIndexBoardContainerEffect is not in context provider of

const { selectFieldMetadataItem } = useContext(RecordBoardContext);
const { columnDefinition } = useContext(RecordBoardColumnContext);

therefore while creating new record I'm unable to provide selectFieldMetadataItem.name

[FelixMalfait]

Hey @Kanav-Arora not an easy one, thanks for taking it!

For the "hide" part we don't want to navigateToSelectSettings but instead we'd want to leverage views (viewFields) to save the visible columns like we do on the traditional list views.

As for your above question, could you do something like this? (not tested)

• Modify the callback in RecordBoardColumnAction to take an optional column id
• Modify computeRecordBoardColumnDefinitionsFromObjectMetadata to pass selectOption.id to the callback
• Modify createEmptyObjectWithStage to pass the stageId upon creation

[Kanav-Arora]

Hey @FelixMalfait
I'll look into it

[FelixMalfait]

Linked discussion: https://discord.com/channels/1130383047699738754/1225049182839111690/1225049186387492964

[charlesBochet]

I have also commented on discord.
Pasting the discussion here for future record:

Félix — Yesterday at 2:54 PM
I think the right path would be to add a jsonb "options" or "hiddenOptions" column on the viewfield table. On that column we would store the fields that are explicitly hidden. Wdyt @charles?
I know the behavior of storing the hidden options feels inconsistent with what we are doing at the field level where we have to explicite create the viewFields but it feels closer to the product POV where we want options to be available by default. OK for me if we keep the same behavior for consistency and have to update every options column when adding a new option value

Kanav Arora — Yesterday at 4:35 PM
I'm not much aware of the backend architecture but basically we are filtering out rows of data so can we maintain the id of stage which is hidden and filterout the rows with that id
sorry if I'm wrong

Félix — Today at 10:21 AM
You'd need to copy what is done for viewFields, but doing it at a second level which are options. The difference is that viewFields are stored in their own table while options would be a json within a viewField record to avoid table bloat
But overall it's very similar
I think we should copy the patterns exactly. Inverting the pattern as I initially suggested saying we should store the options we hide would be a bad pattern in the end I think

charles — Today at 12:57 PM
so we add a new field to the view object (RawJSON type): kanbanOptions which will contain:
{
optionVisibilities: [
{ optionId: string, visible: boolean }
]
}
I'm not sure about the naming, right now columns of a kanban are selectOptions but we will authorize building kanban on top of other field type later
note that we have option.id which is more robust than option.label for SELECT but we still need to think about what's going to happen when we add / remove SELECT options in the settings
Alternatively, we can also introduce a table for that, but as options of SELECT are already store in JSON, we won't benefit from postgres constraint engine (to keep the data robust) so I don't really see a point justifying a new table. Both work, JSON is easier to implement

[FelixMalfait]

Bonus point: have a virtual column for items that don't have a select value than we can chose to display or not (cc @thomas)
I found it strange that I couldn't find a card and it was because the select field was nullable and the card just didn't appear anywhere

Edit: this was completed

[FelixMalfait]

Hey @Kanav-Arora, still working on this one? Or should we close the PR for now?

[charlesBochet]

@Kanav-Arora I'm closing this PR to keep the PR history clean but feel free to re-open it when you pick it again

[FelixMalfait]

Would be great if you do! Will be very cool to have this!

[charlesBochet]

Yes, happy to review it when it's ready!

[FelixMalfait]

Note -> I think we should create ViewGroup object instead of kanbanOptions column we mentioned above

#4244 (comment)