Subtask-related features

[MangoCubes]

Found out you can't set parent task in this web GUI, so I added it. The button is not clear, but at least you can select the parent task. Kinda fixes #124.

2023-06-08.00-51-04.mp4

[barathrm]

This is awesome! :) Would be cool to be able to create a child task with some more UX (add child, or a context icon), but even just adding this would be new functionality and improvement 🚀

fyi @tasn

[barathrm]

I'm not a webdev so I can't comment on that without more work, but I'd bundle your commits into logical changes and try to avoid commits names like Setting task parent is now working. Those are great during development, but imo a commit history is better off containing "chunk" of work so that it's easier to test what causes a bug or easier to revert something by just revert 1-2 commits.

So since I'm not a webdev it's not immediately obvious to me which commits you might want to squash, but if everything is new and there are no single stand-alone changes that could "live on their own" then maybe just one commit? 🤷

[MangoCubes]

In terms of what users would see, yeah, I don't exactly see how any of the changes could 'live on their own' either. It's one feature and all commits are supporting one another. But some of these 'supporting features' can sort of live on their own, and it would be something like this:

Task selector~Parent task added into TaskEdit: Adding dialog window itself, edits made via dialog windows doesn't actually change anything, and they're just visual
Setting task parent is now working, Task can no longer be child of its children: Critical commits that makes the dialog to does its job properly
Simplified selection step, Selection changes field and closes the dialog, Setting default parent if it got one: Making it easier for users to use the dialog

Feedback on how I grouped the commits would be great; I have some more features I want to see in EteSync, and need some samples on what you're looking for.

Oh, and looking back to it, I do agree that commit's message is crap. It was meant to be that one critical commit where the changes user make actually gets applied and it's no longer dry runs only. But yeah, should have been something like "Change in task parent is applied and gets sent to the server".

So regarding these two (squashing and changing commit messages), should I do them myself, and get back once that's done?

[barathrm]

Nice, those three groupings sound like they might make sense to bundle things into, so that'd end up as 3 commits after squashing/interactive rebasing.

Feedback on how I grouped the commits would be great; I have some more features I want to see in EteSync, and need some samples on what you're looking for.

Note that I'm just a drive-by commenter, not a contributor on this repo :D I just package etesync for some platforms and am a (non-web) dev in general, but ultimately it's up to the repo owner (@tasn).

When in doubt, it's always good to look for existing patterns: https://github.com/etesync/etesync-web/commits/master

It looks like most commits add a single "feature" or atomic change, and that commit message titles follow a pattern of <area/topic>: <short description of change>.

So regarding these two (squashing and changing commit messages), should I do them myself, and get back once that's done?

Yeah I'd just do an interactive rebase (git rebase -i HEAD~13 or something if you're a terminal user) and squash and edit, then force-push the changed branch, as I think bundling this feature into fewer commits is something we'd want anyways. :)

[MangoCubes]

I'm pretty sure it went as intended; Let's hope tasn sees this.

[MangoCubes]

Perhaps I am going a bit too ahead with this, but I have added subtask list in the edit page, something requested in #252. This demo shows the feature I have implemented.

output.mp4

[tasn]

Whoops, I missed this! Going to look at reviewing this on the weekend. Thanks a lot for this, and thanks @barathrm for pinging me about it!