New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Thoughts #1

Closed
creecros opened this Issue Oct 9, 2018 · 22 comments

Comments

Projects
None yet
2 participants
@creecros
Copy link
Collaborator

creecros commented Oct 9, 2018

Then create a board and name the first (!) swimlane "backlog" and the first (!) column also "backlog".

  • I guess the goal here would be to make it so there is no need for this?
    • Just use the first column, regardless of name. Or create Backlog column if doesn't exist.
    • Create a swimlane through the plugin, eliminate the prep work for the user.

If you change an existing board, make sure that there are only tasks in the first column in the first swimlane and that there are no tasks in the first column in all other swimlanes.

  • Maybe we can figure out a way to just show everything in the column and ignore whatever swimlane it may have been in.
  • If we create a swimlane to use as the first swimlane, there will be no need to worry about whether tasks were in the swimlane or not

Most of it works. The only problem is that this way collapsing the columns does not work completely for the main area (columns that are NOT the backlog) and not at all for my new column backlog.

  • it all works for me, I say bravo. unless I am missing something. Every column and siwmlane is collapsible.

I'd also add some type of an on/off switch on the board, by doing this, you will be able to go through your own controller where you do all the above, preventing a complete override of existing controller.

@vistree

This comment has been minimized.

Copy link
Owner

vistree commented Oct 10, 2018

Then create a board and name the first (!) swimlane "backlog" and the first (!) column also "backlog".

  • you are right - we need to automate!
  • maybe best to always create new column if column[0][name] != _backlog ?!
  • maybe best to always create new swimlane if swimlane[0][name] != _backlog ?!

If you change an existing board, make sure that there are only tasks in the first column in the first swimlane and that there are no tasks in the first column in all other swimlanes.

  • If we implement above workflow in always creating new smimlane/backlog, we only need to worry if user disables plugin, creates new tasks in _backlog-swimlane[columns] > 0 or other-swimlanes[column] = 0
  • on plugin-enable check, if column[0][name] = _backlog and swimlane[0][name] = _backlog
  • -> if this is true, move all tasks in all columns of swimlane[0] to first column (_backlog[column][0]]) AND move all tasks in all swimlanes[column][0] also to _backlog[column][0]

Most of it works. The only problem is that this way collapsing the columns does not work completely for the main area (columns that are NOT the backlog) and not at all for my new column backlog.

  • Yes, collapsing the columns itself work, but the width of the columns after collapsing should be minimised. Currently the width stays the same in the backlog-column regardless the column is collapsed or not and it seems that the width is not optimal lowered for the other columns (compared with the original board)
  • make of _backlog-column to automatically resize in width after collapsing / uncollapsing AND append the free space to the other columns
  • check if column size of other columns is optimised after collapsing them

I'd also add some type of an on/off switch on the board, by doing this, you will be able to go through your own controller where you do all the above, preventing a complete override of existing controller.

  • I agree! Then users can decide to enable backlog column for single project and we have a flag we can use in the first topic of this list to check against

I think, the only real unclear point is whether we need a new first column or not.

Besides this, we can discuss if my approach in creating an extra table (which requires a unique swimlane AND a unique column) is the best, or if trying to use the first column in combination with rowspan would be the better way. As I described in the old issue, I tried this, but found it more difficult to make it work then using the extra table. Only disadvantage I see in current table-based solution is the collapsing problem and that we need to take care about a - maybe - needless swimlane.

Can we convert the topics to "working" packages so we can discuss them in detail? Is it best to create an issue for each of them or is the project area the better place?

@creecros

This comment has been minimized.

Copy link
Collaborator Author

creecros commented Oct 10, 2018

I think, the only real unclear point is whether we need a new first column or not.

  • I'm thinking, might as well, regardless of whether or not there is already a "Backlog" column

I was poking around last night for a couple hours looking at things, think all the above is pretty doable. I'll go ahead and get the model and controller in place, unless you beat me to it. Was also thinking about putting a prevention in place to keep people from moving the created swimlane and column from the first positions.

I see what your saying about the collapsible column widths as well. I'll let you figure out that formula, I do remember seeing the current formula you had in there, and noticed there is a reload in the boarajaxcontroller, so it should be an easy fix.

@vistree

This comment has been minimized.

Copy link
Owner

vistree commented Oct 11, 2018

Great, I recognised your new branch. Anything you want me already to test?

@creecros

This comment has been minimized.

Copy link
Collaborator Author

creecros commented Oct 11, 2018

Test away. I think I left off at the last function in the controller, moving the tasks out of the column before removing it. Everything else was working, although I didn't get a chance to implement into your template either.

@creecros

This comment has been minimized.

Copy link
Collaborator Author

creecros commented Oct 11, 2018

Ok, everything added works, so far. Test out and let me know thoughts before I go any further.

In case you don't see it, the switch is here:
image

image

@vistree

This comment has been minimized.

Copy link
Owner

vistree commented Oct 11, 2018

Will do - thanx!

@vistree

This comment has been minimized.

Copy link
Owner

vistree commented Oct 12, 2018

Hi, great work!!! Like the way you implemented the backlog switcher! I found some smaller problems with PHP5 and PHP7.1. Do you want me to change the code or better to discuss them first here in the issue?

@creecros

This comment has been minimized.

Copy link
Collaborator Author

creecros commented Oct 12, 2018

No worries, just change it

@creecros

This comment has been minimized.

Copy link
Collaborator Author

creecros commented Oct 12, 2018

These should have been == 2 not === 2, forgot that i changed them and didn't push it.

foreach ($allColumns as $column) { if ($column['position'] == 2) { $column_to = $column['id']; } }
$allSwimlanes = $this->swimlaneModel->getAll($projectId);
foreach ($allSwimlanes as $swimlane) { if ($swimlane['position'] == 2) { $swimlane_to = $swimlane['id']; } }

@creecros

This comment has been minimized.

Copy link
Collaborator Author

creecros commented Oct 12, 2018

Also, added a UI prevention:

  • when backlog board is set, 'Backlog_Board' column and 'Backlog_Swimlane' swimlane will be hidden from column/swimlane config.
  • users can still drag and sort other columns/swimlanes, but the created swimlane/column will be hidden and will remain in first positions always.
  • API calls will be able to move them though.
@vistree

This comment has been minimized.

Copy link
Owner

vistree commented Oct 12, 2018

Really good! Many thanks for the enormous progress! I will have time on Sunday to do my tasks!

@creecros

This comment has been minimized.

Copy link
Collaborator Author

creecros commented Oct 12, 2018

Take your time, it's your plugin! I'm in no rush over here.

@creecros

This comment has been minimized.

Copy link
Collaborator Author

creecros commented Oct 12, 2018

I'm gonna go ahead and merge where it's at, rebranch from here on out and merge when complete.

@creecros

This comment has been minimized.

Copy link
Collaborator Author

creecros commented Oct 23, 2018

Anything else on this one? Think we covered all the bases. Do you know how to add to https://github.com/kanboard/website?

@vistree

This comment has been minimized.

Copy link
Owner

vistree commented Oct 24, 2018

I think there is one thing left - if the backlog related column/swimlane name exists before switching to backlog-view, tasks being in the backlog-swimlane and NOT being in the backlog column or being in the backlog-columns of other swimlanes then the backlog-swimlane are hidden after switching to the backlog-view. + I think we should discuss if we really want to remove the backlog-column / -swimlane if we disable the backlog-view, or if we better leave them and leave the tasks in first backlog-swimlane/column as they are and let user clean it up if they really want to remove the extra swimlane / column.

@creecros

This comment has been minimized.

Copy link
Collaborator Author

creecros commented Oct 24, 2018

That's why we named them "backlog_board" and "backlog_swimlane", so there a little chance of that. We could name them a more unique name, though, like backlog_<today's date> etc.

@creecros

This comment has been minimized.

Copy link
Collaborator Author

creecros commented Oct 24, 2018

The swimlane has about a 0.00001% chance of anything ever being in it, only an API call could put anything in there, maybe an automatic action too, I'd have to look into that, which i guess we could block those too if we really feel the need, so that can be deleted on disable.

leaving the column, is entirely up to you, but the code will have to be rewritten i believe, because now we just increased the chance of "Backlog_Board" column already exists before Enable by a factor of 1000x, i'm just making these numbers up, but the chance of it existing before enabled is now high. We could leave it, but it would need to renamed at least, and if that column doesn't get cleaned up, some idiot could enable/disable to their hearts desire, creating a plethora of columns that now have to be cleaned up, so I think we are doing them a favor by removing.

@creecros

This comment has been minimized.

Copy link
Collaborator Author

creecros commented Oct 24, 2018

also, if you don't delete it, there is the posibility that enable/disable could be repeated to the point of a whole bunch of columns being created and not removed.

@creecros creecros closed this Oct 24, 2018

@creecros creecros reopened this Oct 24, 2018

@creecros

This comment has been minimized.

Copy link
Collaborator Author

creecros commented Oct 24, 2018

didn't meant to close. pushed wrong button!

@vistree

This comment has been minimized.

Copy link
Owner

vistree commented Oct 24, 2018

You are right - let's go with the concept and see if we get any feedback from other users ;-)

@creecros

This comment has been minimized.

Copy link
Collaborator Author

creecros commented Oct 24, 2018

K, i'll add to my current pull request kanboard/website#89

@creecros creecros closed this Oct 24, 2018

@creecros

This comment has been minimized.

Copy link
Collaborator Author

creecros commented Oct 24, 2018

sent you a collaborator invite on another plugin i was working on, if your interested

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment