Dashboard Page

[dhornbein]

The dashboard skeleton is in place, needs to be made to work.

Just drop the bit at the top (name,job title, etc) variables in and I'll sort out the html.

part of the recent pull request:
sahana/eden#1369

Structure

The page is set up much like the updates directories, tabs with two column layouts.

The thing you'll want to look out for is the filter-group elements. In the mock up you'll see check box filters with fly out menus, that's what these are. I can go into more detail if need be.

mockup

Here's the live Google Drawing, below is the "published" version:

[devinbalkind]

@flavour what do you need to push this forward?

Thanks!

[dhornbein]

is there anything I can do to help move this along?

[flavour]

I've done a Merge.
What goes into 'Settings'?
I should hide it if there's nothing there yet

[flavour]

What goes into 'Panels'?
I should hide it if there's nothing there yet

[flavour]

Currently none of Updates/Staff/Orgs/Tasks are filtered in any way..but I assume they should be?
If so by what?

[flavour]

These custom Filters will be a lot of work, so this needs careful prioritisation.
(Each of the 2 could be 20-40 hours of work)

[flavour]

Groups are a whole new area within WACOP, so should implement that first before working on a custom filter which makes use of them.
What exactly is a Group here?
A collection of Persons? (e.g. a Team)
But they are not the same as a Resource which is modelled as a pr_group (collection of Persons)
So we need to have 2 completely different usecases for the same resource (small r, as in internal model)...so we should start this by ensuring that all the Resource (large R, as in WACOP visible resource) usecases use this filter properly: all creates set the flag, all reads filter to just this flag.
Once that's done then we can build the other usecase out: we need a way to manage these groups, possibly 2: 1 for Users and another for Admins.
Currently there seems to be no way to create new groups and seeing the list of groups is only possible by going to Dashboard & selecting 'See All Groups' in the filter section...what this does exactly isn't defined anywhere I can see...my guess would be that it makes groups visible within the filter section? I'm not sure what the difference between 'Admin Groups' & 'Member Groups' is? Is this 'Groups that the user is an Admin of'? & 'Groups that User is a Member of'? So the 'See All Groups' could open a new section here called 'Other Groups' (or similar).
The 'Admin Settings' popup menu item should only show for Admin groups? (Currently also showing for Member Groups)...this would take the user to a page where they can Edit Group Name/Description and Add/Remove Members?
'Go to group' would be the same page but a read-only version thereof?
So members can see the list of other members? Can unauthenticated people?
'Leave Group' seems pretty straightforward, although what happens if the user is the last Admin? Is that still OK? (overall Admin can still manage the group).
Do Admins get notified when a user leaves a Group?
Would the 'Other Groups' section have a 'Request to join group' instead Which sends an email to all Admins for the group which they can click to open a page where they can approve the request or deny it and then that would send an email to the requestor either way?
And also to any other Admins?

'Edit Notifications' takes the user to a special Notifications page which just contains this Group?

• seems odd to manage notifications like that...why not a Global Notifications page accessed in another way? (e.g. a new Tab, like 'Settings')

Can a user only get notifications for groups they are a Member of? (inc Admin)

As you can see a lot to do on this feature before we can think about investing a ton of time in a fancy custom filter...

[flavour]

Bookmarked Events:

• do we show all Incidents for Bookmarked Events or just those which have also been independently bookmarked?
• how do we handle Incidents which are bookmarked without bookmarking the parent Event?

[flavour]

Server is updated with the merge and some fixups inc a basic version of the Greeting, ready for proper HTML/CSS.
The fancy filters are in as dummy for now (I suggest they get hidden for now)
The empty tabs are in for now (I suggest they get hidden for now)

[flavour]

@devinbalkind : Need prioritisation of the many areas which are still open on this page
@dhornbein : ready for the HTML/CSS on the Greeting

[devinbalkind]

Here I go. :)

I've done a Merge.
What goes into 'Settings'?
I should hide it if there's nothing there yet

Yes, let's hide settings for now. We can add setting elements under the logged in user name.

What goes into 'Panels'?
I should hide it if there's nothing there yet

Yes let's hide Panels.

Currently none of Updates/Staff/Orgs/Tasks are filtered in any way..but I assume they should be?
If so by what?

Updates should be all events from Bookmarked Events, Bookmarked Incidents and Groups the user is a member of.

Does that make sense?

Staff and Organizations can be directories as they currently are.

Can Tasks be this: http://cad.aidiq.com/eden/project/task with the default filter being tasks assigned to me?

These custom Filters will be a lot of work, so this needs careful prioritisation. (Each of the 2 could be 20-40 hours of work)

What are "custom filters" in this context? The Bookmarked Events, Incidents and Groups on the left side of the Updates tab?

[flavour]

let's hide settings, let's hide Panels

Good, done

Updates should be all events from Bookmarked Events, Bookmarked Incidents

What about Bookmarked Updates?
& if we Bookmark an Event that means all Incidents linked to it are effectively bookmarked for these purposes?

and Groups the user is a member of.

ok, well Groups is a new feature which we'll need to link to Updates when done and then we can add these to the filter

Staff and Organizations can be directories as they currently are.

ok, completely unfiltered lists...feels a little odd having them in the Dashboard, but can leave as-is for now & review later if needs-be.

Can Tasks be this: http://cad.aidiq.com/eden/project/task with the default filter being tasks assigned > to me?

Yes, should be possible, although that's a lot of filters...we may have real-estate issues with moving these to the left-hand side, but we'll start with that fuill list & a default filter, fine.

What are "custom filters" in this context? The Bookmarked Events, Incidents and Groups on the left side of the Updates tab?

Yes. We will need to create custom filter widgets to get these working.

[devinbalkind]

Groups are a whole new area within WACOP, so should implement that first before working on a custom filter which makes use of them.
What exactly is a Group here?

A group is a collection of users who can communication and share information with each other.

A collection of Persons? (e.g. a Team)
But they are not the same as a Resource which is modelled as a pr_group (collection of Persons)

They're job is to coordinate resources but they themselves are not resources.

So we need to have 2 completely different usecases for the same resource (small r, as in internal model)...so we should start this by ensuring that all the Resource (large R, as in WACOP visible resource) usecases use this filter properly: all creates set the flag, all reads filter to just this flag.

I don't think they need to be tied up with resources at all. They're just user accounts.

Once that's done then we can build the other usecase out: we need a way to manage these groups, possibly 2: 1 for Users and another for Admins.

The only admin functions for a group is to edit name, title, type (public/private/secret) and add/remove members.
Public: any user can join and post.
Private: admin adds all users. Anyone in the group can post. Anyone can see the listing of the group but not its contents.
Secret: Private group but it isn't listed publicly or to other users.
Do you need more info from me about this?

Currently there seems to be no way to create new groups and seeing the list of groups is only possible by going to Dashboard & selecting 'See All Groups' in the filter section...what this does exactly isn't defined anywhere I can see...my guess would be that it makes groups visible within the filter section?

This idea was that this would create a popup with all the groups. Maybe it would be better if Groups were a tab in the Dashboard section with a simple table of all groups?

I'm not sure what the difference between 'Admin Groups' & 'Member Groups' is? Is this 'Groups that the user is an Admin of'? & 'Groups that User is a Member of'?

Yes

So the 'See All Groups' could open a new section here called 'Other Groups' (or similar).

This should go to a Browse Groups tab or popup.

The 'Admin Settings' popup menu item should only show for Admin groups? (Currently also showing for Member Groups)...this would take the user to a page where they can Edit Group Name/Description and Add/Remove Members?

Yes

'Go to group' would be the same page but a read-only version thereof?

Yes

So members can see the list of other members? Can unauthenticated people?

Public groups everything should be visible.
Private groups nothing should be visible to non-members except the top Group info box. If people want to join those groups they can email the admin user whose info is on that box.
Secret groups should not appear for anyone but members.

Members of groups should be able to see all the other group members.

'Leave Group' seems pretty straightforward, although what happens if the user is the last Admin? Is that still OK? (overall Admin can still manage the group).

Fine for now.

Do Admins get notified when a user leaves a Group?

Yes that'd be nice.

Would the 'Other Groups' section have a 'Request to join group' instead Which sends an email to all Admins for the group which they can click to open a page where they can approve the request or deny it and then that would send an email to the requestor either way?
And also to any other Admins?

That would be nice. Would it be relatively easy to implement that type of workflow?

'Edit Notifications' takes the user to a special Notifications page which just contains this Group?

seems odd to manage notifications like that...why not a Global Notifications page accessed in another way? (e.g. a new Tab, like 'Settings')

Yes the idea is that the Settings area would have a list of all the member's groups and their notification settings could be edited from there.

Can a user only get notifications for groups they are a Member of? (inc Admin)

Yes. And also notifications for Incidents and Events they bookmarked.

As you can see a lot to do on this feature before we can think about investing a ton of time in a fancy custom filter...

[devinbalkind]

What about Bookmarked Updates?

These would sit in the dashboard feed if no filters were activated. Like saved items.

& if we Bookmark an Event that means all Incidents linked to it are effectively bookmarked for these purposes?

Yes. In the custom filter I was imagining this would look like an:

[x]event

• [x]incident
• [x]incident
• [x]incident

And the user could deselect individual incidents. If all incidents were deselected they'd only get event-wide updates.

[devinbalkind]

Bookmarked Events:
do we show all Incidents for Bookmarked Events or just those which have also been independently bookmarked?
how do we handle Incidents which are bookmarked without bookmarking the parent Event?

We show all incidents of bookmarked events.

If the event was bookmarked, then all incidents would be selected.

If an incident were bookmarked, then the event and all incidents would appear, but be deselected except for that selected incident.

[flavour]

If an incident were bookmarked, then the event and all incidents would appear, but be deselected except for that selected incident.

What about if there is no 'parent' Event (this is an optional grouping if Incidents, so initially all Incidents start out without any Event)

[devinbalkind]

If an incident were bookmarked, then the event and all incidents within that event would appear, but be deselected except for that selected incident.

I clarified this statement in bold.

What about if there is no 'parent' Event (this is an optional grouping if Incidents, so initially all Incidents start out without any Event)

If there is no parent event then they'd appear in the sidebar anyway. From a design perspective they should be placed below the incidents with events.

[flavour]

A group is a collection of users who can communication and share information with each other.

A collection of users is an auth_group (not pr_group) however these are used to assign roles-based permissions (in fact the field used for the 'name' is actually called 'role') & using them for this purpose will bring a whole slew of issues, hence my thinking that since all auth_user users are linked to pr_person people, it makes sense to use pr_group for this usecase...but as I say, Resources got there first.
Very easy to say 'they should be different', yes that's clear from the user perspective they should be different, but we need to put it into a model, so the options we have:
(1) Use auth_group (has issues with mixing with roles & is a restricted resource generally)
(2) Use pr_group (which makes most logical sense but for WACOP, Resources got there first)
(A) Filter the 2 usecases (as I suggested above, not quick/easy, a bit fragile, but keeps the conceptual model)
(B) Move Resources somewhere else (a lot of work with lots of opportunity to break already-working functionality)
(3) Create a new model which is a parallel of pr_group, called something like wacop_group
(Breaks the conceptual model to have a parallel system which needs all the work done on core pr_group copying here which is not DRY)

I need to think more about which is the least bad option here.
In some ways I lean towards (1) since this is definitely Users not all Persons.
However this would really mean adding a new flag to the table to filter on (just as-described for pr_group although there we already have the 'type' field for this) & this would then slow down every Sahana system unnecessarily and there are already several flags in it (which I don't think we can (ab)use for this usecase):
https://github.com/sahana/eden/blob/master/modules/s3/s3aaa.py#L348

As I say, requires more thought.

[flavour]

Do you need more info from me about this?

Well, the key things I need are Priorities: currently everything all has the same priority & this 'just do Dashboard to complete the site' has introduced a huge new area which seems the wrong place to be introducing it...it's a separate feature it's own right.

[flavour]

This idea was that this would create a popup with all the groups. Maybe it would be better if Groups were a tab in the Dashboard section with a simple table of all groups?

Just like Orgs & Staff? A completely unfiltered list?
Possible, of course, especially with the space freed-up by hiding Panels & Settings, however, as I said for those, it feels conceptually wrong to me.
To me the 'Dashboard' is fundamentally a page with lists filtered in some way to be relevant to the user.
General, unfiltered, lists should be in the top-level menu, rather than within the 'Dashboard' page

[devinbalkind]

I like option 2A. In the past I found it confusing that auth_group and pr_group weren't linked. As a user, I'd edit my auth_group info and then it wouldn't be reflected in pr_group and vice versa. Maybe 2A could solve this - or at least be used to make it more clear to users that they have multiple profiles in the system?

As for the Dashboard, I agree with your sentiment but I'm very unsure about whether they'll even be staff or organization information added to the system at this point. If there is, the chances that it'll be useful to the public is slim so putting in the dashboard seems like a quick, easy and discrete way to hide something that might not be used.

[flavour]

Would it be relatively easy to implement that type of workflow?

Not that hard (simpler than the custom widgets, for instance).
What I keep asking for though is a prioritised list of requirements rather than a whole ton of requirements without priorities.
I may not reach all requirements (by x date or by y budget), so I should start work on those which are most important.

To me we should add incremental working functionality to the site, this thread was for your most important (and last critical, from our previous discussion) task: Dashboards.
So I propose starting by:

• Hiding everything which isn't working currently: Panels/Settings/Groups/custom Widgets
• Ideally moving the unfiltered lists (Orgs/Staff) from Dashboard to top-level menu (awaiting confirmation on this approach)
• Having the Dashboard resources filtered properly:
• Updates (to Bookmarked Updates, Updates linked to Bookmarked Incidents, Updates linked to Bookmarked Events (which are NOT linked to a specific Incident, unless that Incident is also Bookmarked)
• Tasks (add filter widgets & default filter to 'Assigned to me')

This is all relatively quick/easy.
We can then see what the next task should be, options:
(A) Custom Filter Widget for Events/Incidents on Dashboard Updates
(B) Implement Groups
[B then has a whole host of enhancements we can add which would need prioritising: Workflows, Custom Filter Widget, etc]

[devinbalkind]

This sounds like great prioritization to me. Definitely get the quick/easy stuff done first. While you do that I'll refresh my docs about groups and think about whether we can avoid/simplify the Custom Filter Widget.

[flavour]

In the past I found it confusing that auth_group and pr_group weren't linked. As a user, I'd edit my auth_group info and then it wouldn't be reflected in pr_group and vice versa. Maybe 2A could solve this - or at least be used to make it more clear to users that they have multiple profiles in the system?

As a User, auth_group should generally be invisible (unless we start making use of it for this usecase).
The User would think about the Roles they have assigned to them.
pr_group is either their Team or could be their Family, so much more user-visible.

I suspect you mean auth_user & pr_person...yes this is confusing & we strive to hide the fact that these are distinct to the User...they should just see a single 'Profile' (as an Admin this is much harder, but also less critical as far fewer of those and they are more technically literate...I suspect you have been looking at the system as Admin which is inevitably more raw/complex)

I don't think that any of these options relate to Profiles, so none of these will work on that issue at all, so perhaps your leaning towards 2A is based on a misconception.

[devinbalkind]

Yes almost certainly. You should do what you think is best. Let me know if there is any information you need from me that could be used to help you make this decision.

[flavour]

@devinbalkind :
Updates filtering is completed & ready for QA (along with the merge of Drew's Greeting HTML/CSS)
Next is working on the Dashboard Tasks filters.
Should the filter widgets be visible in all views of Tasks?
(Just that the Dashboard version has this defaulting to 'Tasks assigned to me')

Currently this code is common to all usecases so I need to know whether to split this off before starting work...

[devinbalkind]

Yes that sounds fine. Do whatever is easiest.

[flavour]

Tasks now have filters in all places and in Dashboard the filter defaults to 'Assigned to me'
Notes:
As-expected there is some screen real estate issue with having the filters on the side...mainly the list of priorities. These are currently a 1x4 list of checkboxes.
Options:

• replace with dropdown
• switch to 2x2
• Drew does something else just with CSS

[devinbalkind]

Nice progress Fran.

I think priority on the left could be a drop down.

Two other things:

• Assigned to options when creating a new task appears to be resources when they should be system users.
• Can you make it possible for people to upload multiple files to a task similar to how it's done for updates?

Thanks!

[flavour]

Dropdown, OK, easy

Assigned to options are all Person Entities: Persons & Groups ('resources' in this case)
We can customise this to filter to just System Users if-desired, so will do that

Will work on File Uploads

[flavour]

Whilst I am customising the Tasks form to add file attachments, should we simplify? e.g. remove all time related aspects?

[flavour]

ok, done (I see the Time simplification had been done already in other views)