[Feature] Ability to add new columns other than draft and final

[digitarize]

Is your feature request related to a problem? Please describe. I started using grapheneos and started using davx5 for sync and found this notes app. I'm coming from trello and I liked it has multiple columns cause I can see all my to dos without going in an out of each list

Describe the solution you'd like Have an option for users to add new columns

Describe alternatives you've considered

Additional context

[patrickunterwegs]

Hey @khelochagabia ! Thank you for your feature request! Can you describe it a bit more in detail or give some examples of which additional columns you would use?

There is kind of a soft constraint regarding the status, the definition comes from the standard (iCalendar). Adding additional status options is theoretically possible, but might cause incompatibilities with other applications. But please provide first some examples to get a deeper understanding!

Cheers, Patrick

[digitarize]

I see, Thank you for reaching back.

What I meant is on the kanban view of each type (journals, notes, tasks).

In trello you can add a new list (columns/status) on each board (i think this is implemented as collection on jtx)

So instead of just Draft and Final for the kanban view, Have a user option to create new columns that they can name, and maybe make the draft and final renamenable.

I'm trying to find something similar to trello but opensource and having a davx5 sync feature is a bonus and this one is something that has both.

I think if we could make this feature, this would attract more users in the future jumping from degoogled phone and foss comunity.

[patrickunterwegs]

But would such a status really be an extension to the given status? Like "in review"? Or would that be something completely different? I'm thinking if your proposal here isn't also somehow more related to categories than to a status?

[rogercreagh]

Is there a problem here in that RFC5545 only allows the values NEEDS-ACTION, IN-PROGRESS, COMPLETED, CANCELLED for the STATUS property of a VTODO entry. (DRAFT,FINAL,CANCELLED for VJOURNAL)

So adding new values would technically break the spec and might cause unexpected results from the calendar server. I suspect many servers will simply reject unexpected values

I agree that additional columns are useful for a Kanban view- might a way around the problem be to break the IN-PROGRESS column into a nuber of columns depending on the setting of the progress property. An option to define a number of divisions with a label for each, for example: 0-10% = On Hold, 11-30% = Started, 31-60%=Developing, 60-70%=Alpha, 71-80%=Beta, 81-90%=Testing, 91-99%=Awaiting Approval

[rogercreagh]

see #127

[patrickunterwegs]

So adding new values would technically break the spec and might cause unexpected results from the calendar server. I suspect many servers will simply reject unexpected values

Basically it would be possible to add new STATUS values, that's not such a big deal. But as you say, servers might not be able to process them correctly. Additionally there's the problem with the progress, as you state. But what you suggest with breaking down the "IN-PROGRESS" status would just add more fixed statuses (as they need to be linked to the progress) and not individual columns. I also wanted to insist on an example, because maybe the Kanban-columns don't have to be related to the progress, think of a column "Review", this could mean that a task is done with progress 100 %, but a review is necessary once it's done. (I have been working with tools like Jira and I had endless discussions on such topics)...

What I'd rather suggest is a Kanban-view based on categories with an adjustable sort order, this would at least make it fully flexible. This would be completely independent from the status though...

[rogercreagh]

I now agree, having discovered that NC Deck is using categories as status for ToDos, that that is the way to go. Compatibility with NC Deck would be a big plus for some users.

A year ago I was working with an organisation which made extensive use of Kanban Decks in our project management. We started off using Trello and looked at switching to NC Deck because we had our own secure NC server and preferred the opensource model (and ability to customise), but in the event inertia ruled as we had too much time invested in getting a good system working with Trello, so we stuck with the insecure (as in giving our sensitive material to a third party) and proprietary system.

Since Trello got taken over and made more commercial my login no longer works, so I can't check, but from memory we had about 8 columns to 10 columns. Incidentally "Review" or "Awaiting Approval" does not for me correspond to 100% on a progress bar ;-)

The issue for jtxB may be the need to restrict the categories which can be used for Kanban compatibility with NC Deck, when Journals and Notes need a complete open field for categories. This will need some thought - it could be a matter of self discipline by the user - but you would want to be able to show empty columns so that cards can be moved to them.

Columns imply a fixed subset of categories for a particular collection of Tasks, and also imply an ordering or the categories from left to right. So both might need setting up as (internal to jtxB) properties (settings) of a collection being used for Kanban cards.

[patrickunterwegs]

Hey @rogercreagh , @khelochagabia , so finally I came to the point where I implement this request. The custom status fields (independent for journals, notes and tasks) are already implemented the same way as the preset categories and resources are done (from v2.4.0).

Now I would like to do the adaptions on the Kanban-Board. Basically I think it would be nice to define the (custom) status fields in a specific order in which the columns will be shown. Still there is the question with the categories. I think categories were pretty much misused by Nextcloud Deck in this case. It would still be possible to add an option to choose either statuses or categories, but does it really make sense for categories except for compatibility with Nextcloud Deck? In even then, does it make sense to have compatibility with Nextcloud Deck when anyway those entries are ALWAYs read only...?

So I'm still not sure what to do here...

[patrickunterwegs]

Ok, I got the specification wrong, the status cannot be extended. Given the problem with the categories, I'm a bit stuck now.

[rogercreagh]

Hmm. A thought.

In the spec STATUS can have parameters as well as the fixed values (NEEDS_ACTION|COMPLETED|IN-PROGRESS|CANCELLED for to-dos, DRAFT|FINAL|CANCELLED for Journals)

This property is defined by the following notation:

status = "STATUS" statparam ":" statvalue CRLF statparam = *(";" other-param) statvalue = (statvalue-event / statvalue-todo / statvalue-jour)

One way forward might be to introduce an X-parameter for Status if the Value=IN-PROGRESS or =DRAFT. eg STATUS;X-KANBAN=kanvalue:IN_PROGRESS

kanvalue would be any value the user cares to define for his Kanban column headings.

It would be a completely new usage that wouldn't (yet) work with any other system, but should be transparent through any servers. It would be jtxB specific for now.

Regarding integration with Nextcloud Deck one solution would be to have an option for the parameter value X-KANBAN=NCDECK which would tell jtxB to use the first category for the item as the Kanban column (status). Might be some issues about what happens if the jtxB user changed the item category to a value Deck wasn't using.

I suggest that this solution would give the flexibility that users require to define their own status values - the needs-action,completed, and cancelled status values would need to be available as Kanban heads and copied in to the x-kanban parameter value when the status was changed.

It could also allow integration with NC Deck with a little extra work. Some details need thrashing out.

[patrickunterwegs]

Hey @rogercreagh ! Thank you for your reply and remarks!

I actually went through a similar way of thinking. And was very close to do it as you suggest with a parameter on the status.

Basically I want to follow the approach that a user can define any status and at the same time let the user choose to which default status a custom status should match (as a fallback for other applications). The parameter has one major downside: you cannot represent "no status" (ie. No status present) but you would always have to make an explicit status. I didn't want to do that.

So instead I would like to introduce another X-STATUS as a parameter additionally to the STATUS, so this new status can just contain any custom status while the actual STATUS can still be missing. I think it's also a nice compromise!

About Kannan and category-columns: While implementing it I saw that I could easily make columns based on a category, so I added the option to set columns based on the first category of an entry. I also didn't want to make a specific solution to show the entries from NC Deck (which anyway would always be read only die to constraints in NC Deck), but a general solution that would always work.

I think this is also a nice generalized approach. I hope you'd agree with me 😉

[rogercreagh]

So you mean X-STATUS as a new property that is divorced from STATUS but is required to have a value.

I'd forgotten about STATUS being optional.

What happens if you import an entry created on another server that hasn't set a value for status? You'd have to have a default x-status value (eg "unknown") to represent it

Presumably if there is a value for status you'd copy it to x-status? But what do you do if after saving and then later syncing it and you find the status had changed? Do you then change x-status to match the new value or not. Maybe the remote user has intentionally marked it completed, you need to update x-status to reflect that, so x-status values can't be reliably sync'd.

Unless you are only going to use the x-syatus value when status=in-progress. In which case we have the same solution exvept you ate adding an entire line, and I'm adding a patameter to an existing line.

Which is more likely to be lost by passing it through another app that fails to preserve everything it doesn't recognize I wonder?

I see that the same problem of a missing (not set) status property applies in my idea of using a parameter on the standard status field.

In my case too there would have to be a locally inserted value for status like "unkown" which would be a separate column in the kanban view. In order to be able to set a new x-kanban parameter value the status value would have to be changed to "in-progress".

This makes sense to me, just as needing-action, completed, and cancelled are special cases so is "unknown"

I guess either scheme would work; creating a whole new property which can still have the same values (including unknown) as the core status property just sounds like replication...but maybe it's simpler to implement.

[rogercreagh]

About Kannan and category-columns: While implementing it I saw that I could easily make columns based on a category, so I added the option to set columns based on the first category of an entry.

But in jtxB you can't change the order of categories on an item - I just tried but deleting a category from an item and then reselecting it and it popped back in the same place. Even if I savef and sync'd the item before reselecting the category.

So I have no control over which category will appear in first place so using category for Kanban columns wiil only work if you only use a single category.

[patrickunterwegs]

What happens if you import an entry created on another server that hasn't set a value for status? You'd have to have a default x-status value (eg "unknown") to represent it

So if there is no status set, the DB field for the status would stay empty, the x-status value as well (it is only filled out if it was explicitely set).

Presumably if there is a value for status you'd copy it to x-status? But what do you do if after saving and then later syncing it and you find the status had changed? Do you then change x-status to match the new value or not. Maybe the remote user has intentionally marked it completed, you need to update x-status to reflect that, so x-status values can't be reliably sync'd.

I would keep the x-status empty and show the default status as a fallback (which might also not be set). If you choose a default status explicitely, the x-status would be reset to null. But yes, the case that you describe is a problem, if another application changes the status but NOT the x-status, the status would be kept while the x-status is still there and might get inconsistent with the x-status/status mapping. But I'm not sure if there's a proper way to avoid that...

Unless you are only going to use the x-syatus value when status=in-progress. In which case we have the same solution exvept you ate adding an entire line, and I'm adding a patameter to an existing line.

Imagine a status like "Unassigned" and "Assigned to...", both would not reflect "In Progress", they both would mean "Needs Action". But then we run into the problem that the status could be missing.

Which is more likely to be lost by passing it through another app that fails to preserve everything it doesn't recognize I wonder?

I would expect that too...

I guess either scheme would work; creating a whole new property which can still have the same values (including unknown) as the core status property just sounds like replication...but maybe it's simpler to implement.

Yes, for now it's definitely easier... but also to make this clear: if a user uses a default status, I wouldn't set the x-status at all (it would just be missing). So basically there will not be a replication!

[patrickunterwegs]

But in jtxB you can't change the order of categories on an item - I just tried but deleting a category from an item and then reselecting it and it popped back in the same place. Even if I savef and sync'd the item before reselecting the category.

So I have no control over which category will appear in first place so using category for Kanban columns wiil only work if you only use a single category.

Yes, in fact making the user aware that they should only use a single category was the idea. When I said that the app would take the FIRST category, I already had the technical implementation in mind (taking the first if there are multiple). I would leave it up to the user to make sure the categories are set the way they need them... If you want to move a category to the first place, there's no other way but to delete all and set them again in the right order.

[rogercreagh]

So if there is no status set, the DB field for the status would stay empty, the x-status value as well (it is only filled out if it was explicitely set).

If x-status is being used for kanban view columns (which I understood was the proposal) I would prefer a that the status value was reflected in x-status including "unknown" for status value not set. Custom values for x-status would only apply if the status was "in-progress"

Otherwise you might have a entries with no status set that wouldn't appear in Kanban view? Or maybe that is desirable?

For me x-status (or x-kanban) is logically an extension of "in-progress".

Handling it like this gets rid of any problem with the remote app changing the status. The x- value would (should!) be preserved and apps like jtxB using the x-status could simply continue to use x-status for Kanban view. Only if you changed the status in jtxB (or other compliant app) would the x-status get changed to the new master status value.

Imagine a status like "Unassigned" and "Assigned to...", both would not reflect "In Progress", they both would mean "Needs Action". But then we run into the problem that the status could be missing.

Yes but I would argue that marking an item as "unassigned" or "assigned to xyz" is a first action on a newly created item so it is now "in-progress". Needs-action means that nothing has been done yet. After all when an item is in-progress it still neds action until it is completed or cancelled.

In jtxB setting an x-status value to anything other than the other three valid status values would automatically change the status value to"in-progress"

[rogercreagh]

Yes, in fact making the user aware that they should only use a single category was the idea. When I said that the app would take the FIRST category, I already had the technical implementation in mind (taking the first if there are multiple). I would leave it up to the user to make sure the categories are set the way they need them... If you want to move a category to the first place, there's no other way but to delete all and set them again in the right order.

The problem here is that vcalendar doesn't distinguish between the one-to-many category-item relationship and the many-to-many category-item relationship that I would call tags. There is the one-many relationship for status-item, but status has fixed values. Hence x-status with a single value is a much better solution.

Since we only have the one property called "categories" (which for me would be better called "tags"). If you use first in categories as the column head for Kanban view then I've got to pay attention to the order for ALL items (including deleting and reinserting categories for existing items) and also including those items I might not care about in Kanban view which would all have to have a first category of "misc" or 'notkanban" Also if I want to change an item's column I have to delete all its categories and rebuild with the new correct order.

I don't think it would be acceptable to say that Kanban view gives uncertain results if you use multiple categories per item. And given the difficulty of the user controlling the order just picking the first category doesn't work.

I'd strongly prefer your x-status solution (subject to comments above).

[rogercreagh]

A suggestion - if STATUS is not assigned don't show the item in Kanban view?

[patrickunterwegs]

If x-status is being used for kanban view columns (which I understood was the proposal) I would prefer a that the status value was reflected in x-status including "unknown" for status value not set. Custom values for x-status would only apply if the status was "in-progress"

Together with this change I would make the kanban-board configurable (also the order of the columns). But the user would have to choose on which attribute they want to base the columns on (either status, x-status or category), but they cannot mix it. So yes, if you have columns with x-status and an entry that either has no x-status or has an x-status that is not selected as a column in the kanban-board, it would not be shown. The same applies for categories or default statuses. So I would even say this is desirable and clear for the user...

For me x-status (or x-kanban) is logically an extension of "in-progress".

I don't see it that way - like I said in my example. I understand that it opens up the problem with a possible inconsistency (between status and x-status), but also it doesn't make so much sense anyway to use jtx Board with x-status and at the same time update a status in another app where I couldn't even see the x-status.

In jtxB setting an x-status value to anything other than the other three valid status values would automatically change the status value to"in-progress" I'm afraid this would really just open up many more discussions.

I would like to give the user the possibility to choose to which status an x-status should map.

[patrickunterwegs]

I don't think it would be acceptable to say that Kanban view gives uncertain results if you use multiple categories per item. And given the difficulty of the user controlling the order just picking the first category doesn't work.

I understand the concerns. This was meant as an additional option for Kanban-Columns (not instead of x-status). I don't see another proper alternative, only just do it that way (use the first category) or not offer the option at all. I still think it's a good thing. I believe users who want to use kanban-columns based on categories just must be made aware that they should only use one category per entry. Then the rest is up to the user!

[patrickunterwegs]

A suggestion - if STATUS is not assigned don't show the item in Kanban view?

As I want to give the full flexibility anyway to choose the columns, it would be up to the user to select the status columns they want to see

[patrickunterwegs]

In fact, now that I'm thinking of the status again, I'm thinking about removing the "no status" option completely, as for all components it is defined which status should be used if the property is missing...

[rogercreagh]

In fact, now that I'm thinking of the status again, I'm thinking about removing the "no status" option completely, as for all components it is defined which status should be used if the property is missing...

We had an earlier debate about that (possibly on gitlab) where we agreed that no status was a valid option (especially for journals) where a user doesn't want to clutter up the screen with spurious status values.

eg None of my journal entries normally have a status. I'd be reluctant to be forced to have one shown when it adds no information to the entries. On tasks I can see the point that all tasks need to have a status (we just wish that more values including user defined values were in the spec as with categories)

Otherwise I'll support your comments above; it allows another app to interpret the relationship between x-status and status differently.

It might be nice to have a way of excluding items from the kanban view. I'll take that into discussions.

[patrickunterwegs]

Alright, thanks, I'll additionally mark the change as experimental, so we can have a look how it turns out and maybe adapt if necessary 👍

[rogercreagh]

@patrickunterwegs

In fact, now that I'm thinking of the status again, I'm thinking about removing the "no status" option completely, as for all components it is defined which status should be used if the property is missing...

Just to follow up I think we are confusing the rules around CLASS and STATUS. The way I re-read the spec is that neither is compulsory but if CLASS property is missing or if CLASS property is set to a value (iana-token or x-value) that the local app doesn't recognise then it must be treated as if the value is PUBLIC. ie no-value == PUBLIC

For STATUS there is no specification for how a missing value should be treated - so no-value is a valid value.

CLASS can have alternative values specified which an app might recognise or if unrecognised must treat as public. (and by implication preserve the unrecognised value???) - I can see this as being of use for apps which have a more finely grained security model than simply public and private.

STATUS cannot have alternative values - hence the need either to use an extended parameter on an existing value (which other apps should preserve) or a new X-property (which other apps should preserve)

So I think you are wrong in saying that no-status is defined as equivalent to one of the predefined vlaues (which?) - so please leave it (and I would suggest excluding items with no status, or no x-status, from Kanban view, or adding an "undefined" column for them, or making a optional setting mapping to a defined value)

I would also like to keep the no-class option (which is equivalent to public) as it is a way of de-cluttering pages whch show the class (and status) if it is not being used.

[patrickunterwegs]

Yes, I will keep it. It's almost done already anyway 👍