Add routes for Tasks into views

[jia1]

@leeyimin could I hire your expertise in exposing all the routes for the Tasks functionality into the Views?

I'm not very clear about groups and memberships (very nested routing). Maybe you can refer me to your documentation, or explain a little about your thought process here.

My personal algorithm for housing various communities is like this (definitely not the best or correct one, but we should let each other know).

Let's say we have 10 organisations in our customer base. Each of 10 organisations has a single task. What I would do is to have the Task model talk to the same database and fetch the filtered task(s).

Hence, in my case, there would not be any routing for an organisation name. (i.e. We have KouhaiDash and SenpaiDash as our two organisations, there will be no routing like .../kouhaidash/tasks and .../senpaidash/tasks).

I hope to hear from you soon so that we can all add our tasks~!! Personally, I hope to use this app for myself too!

[leeyimin]

Sorry! I only just saw this post after some sort of implementation! My initial idea was that each organisation (which I called group in the app) is independent from one another so they would have their own task lists. I thought about the routing issue too but only 2 other alternatives came to my mind: Either put params in the GET link, which would results in similar routes ( eg. /group_tasks/group_id/category_id) Or store some data in session to make it work, which seems more complicated and would not allow users to copy/paste links for tasks. I do agree the current nesting does seem a bit too much ( /groups/:group_id/categories/:category_id/tasks) 😂

[leeyimin]

In the latest commit, I have added a link to access groups index and the associated paths for a group in the navigation bar when a group is being accessed (eg. /groups/:group_id/...). Currently, the membership hierarchy is flat, either the member is approved or not. A logged in non-member can request to join through the groups index page and any approved member of the group can approve the membership through the memberships index of the group. Any member added through the memberships index page by an approved member is approved. There isn't a way to leave the group yet, except for deleting unapproved members by an approved member. I will probably do it soon. When creating a new group, the user is also added as an approved member of the new group. Categories were made so that a group can have multiple task lists or multiple contact lists etc. Now, it acts as access control (public/not) and does redirection (redirects to tasks if the type_no is 3) when you access a particular category (/groups/1/categories/2 -> /groups/1/categories/2/tasks).

[jia1]

I think your system is working + helpful, that's wonderful already.

Is it possible to have a page specially for categories instead of having them pop up at the side bar?

[jia1]

And the Tasks link on the sidebar is not there... not sure if it is really present because the word "Tasks" is not there.

[jia1]

Sounds like the "Categories" are for customising the sidebar. But it's not being UI-friendly.

[leeyimin]

yeah it is kind of. What do you mean by task link by the way?

[leeyimin]

Should I move the categories index link to the group show page?

[jia1]

Oh cause I thought the sidebar is something like

Calendar Tasks Files Contacts

[jia1]

"Should I move the categories index link to the group show page?"

Not sure T_T because I am still not clear about the system.

[jia1]

@leeyimin is working really really hard on KouhaiDash! already and this issue should have been closed a long long time ago (: