when you have a project with a more complex structure, then Calendar view is not very informative, because the Task name could be generic and you would not know what is the actual project.
My coworker asked if it would be possible to include a name of parent task, so instead of seeing on the Calendar:
Surgery
Surgery
Surgery
You would see:
Patient1 - Surgery
Patient2 - Surgery
Patient3 - Surgery
What code needs to be added to calendar_show.php?
If you think that this would overcrowd the view, could it be at least added to the tool tip? I guess it would be possible to add even full path to the tool tip, eg:
Project1 > Patient1 > Surgery
Can we implement both ideas?
Thank you!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Adding the project name should be relatively straightforward, but there prpbably needs to be another database call.
Adding tasks and subtasks gets more tricky. To make the code more versatile, every task record only has the overall project and the immediate parent task (if any). To display full information, the code has to 'walk' up (or down) the tree following the trail and assemble the tree. It 's a bit inefficient, but it means that there is no limit to the combinations or depths of tasks and sub tasks that can be created.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, Andrew, I thought I will follow up on this post. In case you are considering implementing this idea, please let me know, that would be super useful for our team.
Thank you!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've also updated the github repo as well. It doesn't get a lot of attention, so I tend to forget about it. There is a note on the front page directing to the Sourceforge page.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
thank you for the new release! I have several suggestions:
It would be good to add a CSS class selector for the calendar icon bullet_add.png and also state icons, eg. "Done/New". This way you can hide them via print.css when printing the calendar. And overall, for some reason the bullet_add icon does nothing when I tested - do we need it?
It would be good to restructure calendar entry. Currently whole entry falls under tooltip CSS class, but in reality there are 2 parts: visible calendar entry and then tooltip. If those two would be clearly separated and denoted with distinct CSS class names, then in printing we could hide the regular short entry and only display full tooltip text that is much better for the printing purposes.
Hi, Andrew,
when you have a project with a more complex structure, then Calendar view is not very informative, because the Task name could be generic and you would not know what is the actual project.
My coworker asked if it would be possible to include a name of parent task, so instead of seeing on the Calendar:
You would see:
Patient1 - Surgery
Patient2 - Surgery
Patient3 - Surgery
What code needs to be added to calendar_show.php?
If you think that this would overcrowd the view, could it be at least added to the tool tip? I guess it would be possible to add even full path to the tool tip, eg:
Project1 > Patient1 > Surgery
Can we implement both ideas?
Thank you!
Interesting idea. I'll have a look at the code.
Adding the project name should be relatively straightforward, but there prpbably needs to be another database call.
Adding tasks and subtasks gets more tricky. To make the code more versatile, every task record only has the overall project and the immediate parent task (if any). To display full information, the code has to 'walk' up (or down) the tree following the trail and assemble the tree. It 's a bit inefficient, but it means that there is no limit to the combinations or depths of tasks and sub tasks that can be created.
Hi, Andrew, immediate parent task (it looks that it would be easy) culd be a great start! (in fact, that is what we need at the moment) :)
And in term of the Tooltip, we could use those two easy items:
Main Project > [...] > Parent task > Task
[...] - would indicate possible additional layers.
Hi, Andrew, I thought I will follow up on this post. In case you are considering implementing this idea, please let me know, that would be super useful for our team.
Thank you!
Yes, it's been added to the Git repo.
I've also started preparing for a release, since there are enough changes to make this worthwhile.
That's great! I checked the Git, but the last update is shown in 2017:
https://github.com/andrewsimpsonnz/webcollab
I will wait for the new version, thank you!
Oh, actually I meant the git repo on this (Sourceforge) site:
https://sourceforge.net/p/webcollab/code/ci/master/tree/
I've also updated the github repo as well. It doesn't get a lot of attention, so I tend to forget about it. There is a note on the front page directing to the Sourceforge page.
Hi, Andrew,
thank you for the new release! I have several suggestions:
It would be good to add a CSS class selector for the calendar icon bullet_add.png and also state icons, eg. "Done/New". This way you can hide them via print.css when printing the calendar. And overall, for some reason the bullet_add icon does nothing when I tested - do we need it?
It would be good to restructure calendar entry. Currently whole entry falls under tooltip CSS class, but in reality there are 2 parts: visible calendar entry and then tooltip. If those two would be clearly separated and denoted with distinct CSS class names, then in printing we could hide the regular short entry and only display full tooltip text that is much better for the printing purposes.
Last edit: Tomas M. 2021-01-08
To enable printing styles we need to change head:
<link rel="StyleSheet" href="css/default.css" type="text/css">
<link rel="StyleSheet" href="css/calendar.css" type="text/css">
<link rel="stylesheet" media="print" href="css/print.css">
This way printing styles will be added in addition to main stytles, ref:
https://www.sitepoint.com/css-printer-friendly-pages/
Thank you!
Hi, Andrew, I improved the code in my recent comments, so please check the forum version, not the one that is sent via email. Thank you!
Sounds good. I am just on holiday at present, so I will look further when I return to base in a few days.