312 - Project Reporting Protoype #318

Open treasuretron opened 4 years ago

In GitLab by @thomasmurphy on Jan 15, 2019, 21:16

Based on the discussions at the meeting on 16.1.19 we will create a prototype of the projects and reporting system for planning and refinement purposes.

In GitLab by @thomasmurphy on Jan 15, 2019, 23:25

After some thinking, I have a plan.

Each projects could have two entity reference fields, each of which can reference multiple instances of two respective types of entities: 1) Project Aims (PAs - or metrics) 2) Project Updates (PUs - the blog updates)

The PU entities can create in context and reference Project Aim Update entities (PAUs) which have an entity reference field which can reference the PA entities that are referenced by the same project at the PU. They also have a percentage field. All this can be via intuitive autocomplete fields.

We can then build a view with multiple displays which:

A) list the percentage field from the most recent PAUs which references the current PA (eg in a block next to the PA - current status) B) List the average of the latest PAUs for each of the PA for a particular project (eg project current status) C) List of the average project aim percentage for each PU (a chart of progress for the project)

And so on. We don't need to build all of this up front, but if we start with this model I think we can safely extend in this direction incrementally.

In GitLab by @thomasmurphy on Jan 21, 2019, 22:02

@jayelless tell me what you think.

In GitLab by @thomasmurphy on Jan 29, 2019, 22:36

Useful links

https://www.drupal.org/project/field_default_token/issues/2825753

https://www.drupal.org/project/inline_entity_form/issues/2889850

https://www.drupal.org/node/2134073

https://www.drupal.org/project/entityreference/issues/2902934

https://www.drupal.org/project/simple_modal_entity_form

https://www.drupal.org/sandbox/michaelpetri/2827680

In GitLab by @richbodo on Jan 31, 2019, 16:47

I'll just drop a reminder on the MVP goals for Projects, and a description of how we will use this During the Space Challenge in a month or so:

This is the MVP spec that we thought would make it usable for the space challenge: https://gitlab.com/spacebase/spacebase/wikis/Design-Specs/Projects#mvp-summary

And our basic use case is:

We set up the 2019 space challenge as a project, fill out all fields. Add ourselves and other administrators of the challenge as members.
We set up each team with a project and make them affiliates. They add their own members.
Everyone reports out with "updates" which are the blog-like project reports in the spec.

In GitLab by @thomasmurphy on Jan 31, 2019, 23:04

@richbodo

In the project scope here https://gitlab.com/spacebase/spacebase/wikis/Design-Specs/Projects#mvp-summary

It has a list of MVP features, but it also mentions later that projects should have all the features of organisations, which aren't listed in the MVP list, or elsewhere on the page, are they listed somewhere else?

Also, in the list of the minor differences between organisations and projects, it doesn't mention whether these additional features are in the MVP or not and doesn't mention these equivalent features in the list of MVP features at the start of the page. I'm presuming they are MVP because it wouldn't make sense to make these changes later, but it would be better to have a clearly defined MVP description in one place.

Having read the whole thing I can see more of the importance of having projects as a multi-user membership object with private discussion areas, so I'll have to have another look at the reporting so that we can spread the views across groups and entity reference relationships.

In GitLab by @richbodo on Feb 4, 2019, 15:19

Hi Thomas,

Sorry for the confusion. Up until our last conversation, I had assumed that we were going to re-use the investment we made in Organizations, and expand on that functionality for Projects. Everything I have ever written on the topic assumes that. You have probably noticed lots of things that say "these are the differences between projects and orgs" in the spec. I can back and clean that up and remove any references to orgs.

Pretty swamped today, but here's the summary:

Projects must have members, and therefore member management.
Projects must have a way to link out to the online resources that are being used by project members.
Projects must have some ability to engage in brief discussions.

All three of those feature sets have been implmented and tested working in Orgs, and we have had no coimplaints about them, so to maintain a consistent UX across the site, and to save time and capture value, we thought it would be faster to make projects share as much of the same code as possible with orgs.

I can clean up the projects page and make small presentation on The Features Of Projects with mocks that explains them feature by feature for our next sprint meeting.

In GitLab by @thomasmurphy on Feb 4, 2019, 16:26

@richbodo thanks, I just thought we could do with that documented explicitly. Currently I'm researching the incompatibility between the groups base tables and the content tables in terms of views to see if there's a way around it. In short, there may be no benefit to reusing what has been done on the organizations because how you want to drive the project reporting, but we will update in more detail on options once they are available.

In GitLab by @richbodo on Feb 4, 2019, 16:34

O.k. Thomas. I'll still write a spec/presentation for projects that doesn't mention orgs for our meeting on friday. Look forward to seeing what you find out. Keeping the UX consistent across the site is a big deal, and given our situation, not being able to re-use any of the orgs work is a significant and unexpected turn. Hoping for the best.

In GitLab by @thomasmurphy on Feb 6, 2019, 21:08

@richbodo after some research I've found a way of relating the groups data in an efficient way, so panic over. I've now built a working prototype of the reporting system based on projects as groups, so that approach is fine :)

In GitLab by @jayelless on Feb 10, 2019, 23:26

As a first step to simplifying the custom module code and sorting out what can be re-used from the organization groups for projects, I have moved all hook_preprocess code and twig templates from custom modules to the spacebase theme.

Because we have control over the theme, there is no need to code hooks and templates in custom modules to over-ride the theme values.

In GitLab by @jayelless on Feb 11, 2019, 19:36

I recommend the that project group type is renamed from "project" to "project_group" to be consistent with the "organization_group" type and to emphasize that it is a group entity. There is also a content type called "project" that can be deleted.

In GitLab by @jayelless on Feb 11, 2019, 21:47

The group type "project" has been replaced with group type "project_group" and the unneeded content type deleted.

In GitLab by @jayelless on Feb 12, 2019, 21:17

A number of changes have been made and pushed to Gitlab. These include new views, templates and custom code changes to process project groups and associated information.

The resources taxonomy terms now have a new field "associated_group_types" which is a set of check boxes for each term that specify which group types the resource can be associated with (Organization, or Project) as resources are not always associated with both types. This field is requires, and so existing databases will need to be updated to specify this. The initial list is:

Communication : Organization & Project
Other : Project only
File Sharing : Organization & Project
Projects : Organization only
Links : Organization only
About Us : Organization & Project

In GitLab by @jayelless on Feb 12, 2019, 21:19

mentioned in merge request !265

In GitLab by @jayelless on Feb 13, 2019, 22:35

I have updated the project group functionality to match the display and behaviour specified in https://gitlab.com/spacebase/spacebase/wikis/Design-Specs/Projects#mvp-summary.

The dev branch has been merged to pick up the lastest changes to ensure that the merge PR#265 should complete without problems.

In GitLab by @thomasmurphy on Feb 17, 2019, 20:07

In regards to archiving groups, which is now out of MVP v1, this is the existing approach I think we should look at before approach this on our own https://www.drupal.org/project/group/issues/2873212

In GitLab by @thomasmurphy on Feb 20, 2019, 20:36

Just clarifying the workflow for adding project team members. If the user does't have a spacebase account they will need to be sent an invite to join spacebase (not just the project) and complete the basics of that before a user record exists which can be added to the project.

In GitLab by @thomasmurphy on Feb 20, 2019, 23:47

changed title from Projects and Reporting Protoype to {+312 - +}Projects and Reporting Protoype

In GitLab by @richbodo on Feb 27, 2019, 19:56

@thomasmurphy Yes, you can only add site-members to project teams.

As a MVP for invites, we dropped a few links to an invite form throughout the site, in an attempt to give org owners a way to at least quickly send email to prospective members with instructions for joining the site and then their org. The form allowed a comma delimited email list to be used to send to multiple non-site-members at once.

That process could probably be improved with projects, but if we don't think of a good improvement, it can be duplicated for the MVP of projects.

In GitLab by @jayelless on Feb 27, 2019, 23:36

@thomasmurphy The views based private message inbox allows a user with administrator role to see all message threads (but not the messages within the threads). This can probably be fixed with some tweaking of the view.

The alternative I had been thinking about is to prepare a patch to the private_message module that allows a different default display for the page "/private_messages". This would just list the current threads (to a configurable number) and clicking on any thread would take the user to the page "/private_messages/nnn" which would display the messages in the thread. This would then act more like a standard inbox.

It would also be possible to have the messages displayed in a block on the same page, and use ajax to populate the block contents. This would look like a message pane as is common in email clients.

In GitLab by @epaatdahlstrom on Feb 28, 2019, 14:39

Hello everyone, its March 1 so in advance of our standup today this is just a reminder of what I hope I will be able to access to use under the projects feature (per the deliverables on this day) in prep for the Challenge Launch next Friday 8 March.

Access to create a Challenge Project in Production at earliest convenience
Add resources under Challenge Project before 8 Mar
Add discussion information in Challenge Project before 8 Mar

Note that this are all informational from me as owner and no one needs to be a member or be able to message anyone at this stage unless you already have those features running.

ChristchurchNZ will expect a link to this specific project linked to the NZAerospaceChallenge.com website at earliest convenience or prior to 8 Mar. The sooner I have this up and running the better. Can discuss at meeting today.

Thanks.

In GitLab by @jayelless on Mar 3, 2019, 16:50

mentioned in merge request !277

In GitLab by @thomasmurphy on Mar 6, 2019, 17:53

mentioned in commit 37ab30e5671a7643e0539488150623003bf50021

In GitLab by @thomasmurphy on Mar 6, 2019, 17:53

closed via merge request !277

In GitLab by @thomasmurphy on Mar 11, 2019, 18:31

@richbodo James and I think it's best to reopen this ticket for the next phase of reports prototyping in order to keep using a 312 related branch name, so as to keep the repo simpler / more continuative.

In GitLab by @thomasmurphy on Mar 11, 2019, 18:31

reopened

In GitLab by @jayelless on Mar 24, 2019, 22:13

Hi Thomas. The commit you need to access to get the original view from config is " 5d39dceba9abb11451aa367c57f3f21cbc05fd21".

In GitLab by @thomasmurphy on Mar 27, 2019, 19:01

Based on the prioritisation done on 15.3.19 this issue is now 16/20 and not happening within this contract.

In GitLab by @thomasmurphy on Mar 28, 2019, 17:25

changed title from 312 - Project{-s and-} Reporting Protoype to 312 - Project Reporting Protoype

In GitLab by @richbodo on Mar 28, 2019, 17:34

Got it. This is about the reporting section of the website where we make a summary and show some aggregate info. We'll do that in another contract or something. Projects still have reports.

spacebase / spacebasenz

312 - Project Reporting Protoype #318