Add additional fields to card entity

[Flamenco]

This request is to add the following fields to the card entity in order to make way for future features as mentioned here:

#2476

We are providing the database upgrade as the first in several incremental pull requests.

Documentation

Time To Complete

field name: time_to_complete
type: string or null

A text field using the format \d+\s*[mhdw]

Examples:
1w (1 week)
3h (4 hours)
2d (2 days)

m = minute
h = hour
d = day
w = week

This field is translated to actual minutes and updated in the corresponding time_to_complete_minutes field.
Invalid format becomes null in the corresponding field. A null or empty string indicates not set.

Time To Complete Minutes

field name: time_to_complete_minutes
type: number or null

The number of minutes from the parsed time_to_complete field. A null value indicates not set.

Milestone

field name: milestone
type: string or null

A string value to indicate a milestone for card. Null or empty string indicates not set.

Product

field name: project
type: string or null

A applicable product for a card

Component

field name: component

A applicable component within a product for a card. Null or empty string indicates not set.

Percent Complete

field name: pct_complete
type: number or null

The percent complete as a number between 0 and 100, or null to indicate not set.

[stefan-niedermann]

As @juliushaertl i have also concerns that at least some of those fields are way too specific. How would you track the percentage for example? Not everyone needs this feature and i suppose to go for the already mentioned generic fields instead to keep the UI clean for everyone.

To stay at the percentag example: We already track and display the progress for solved / checked tasks. I guess you are used to Jira, and some of the fields make sense but will introduce very much complexity like: How to track the time to completion? The time from the first to the last column/list? What if a user puts a card back from the middle to the first list? Reset? Count on? It doesn't make sense to make it changable by the users, we have a due date for that...

[Flamenco]

This is simply to indicate how far into a task you have achieved. We use it all the time to show where we are for a given milestone. Due date is not related AT ALL.

Furthermore, our feature that follows allows the field to be hidden, and has 0 impact on database performance.

Finally, one can make the argument that a 'completed' stack is actually a really bad idea', because you lose the context of the stack the card came from.

I would consider renaming Product and Component to Category and Subcategory, but that is just a surface UI change.

[juliusknorr]

For the actual done state of a card, I started working on #2503 for having a dedicated indicator of that on the card entry itself.

Now I still have the concern that we loose flexibility with manually adding those special fields instead of a generic way. Especially since we aim to at some point support CalDAV write support, we need a generic way of storing values anyways. My general proposal would be to start working on #1833 for this to add a custom attributes table where we can allow the user to basically add any data needed to a card.

Time To Complete Minutes
Time To Complete
Milestone
Product
Component
Percent Complete

All of those would definitely be good candidates for such a dedicated custom attributes table. This way we also don't limit users to a certain way of working with deck.

Furthermore, our feature that follows allows the field to be hidden

We generally should try to find a way to integrate features without having a custom setting for those, as some hidden features like this would just increase the test matrix and the risk for possible bugs.

[Flamenco]

So my thoughts on this is:

Time To Complete Minutes and Time To Complete require special processing and will never work with your custom attribute table.

The other fields are pretty standard for boards for almost all use cases.

I don't know how long it's going to take for you to implement custom fields, but once this goes through, users can start using a ton of new features I have implemented as indicated in the link.

These fields can always be removed from the main table and moved to custom fields in the future. Once that is in place, there really is no reason for ANY fields besides assigned to anyway.