MSI

https://www.msi.umn.edu/ https://msi.dev.umn.edu/

PI DASHBOARD Archived


Meeting notes:

  1. Will remain as per the old site (for now)

  2. Old site copied to a new (sub-domain, or rather sub folder), we would duplicated the header and footer to apply to the sub-folder and the PI feels more seamless with the new site elements.

  3. We need to figure out redirecting to the current URLs under PIs

  4. “/group/name of group” will change

  5. Need to discuss with Drupal team to set up separate dev and staging just for PI
    Pull down to local and we’ll have more clarity around redirects 

  6. Can PI’s contribute posts to the site

  7. Invite PIs to contact us to share important things on the MSI site

  8. Submit some kind of content for review

  9. Renewal process needs to be integrated with PIs

  10. PI’s have the power to make group admins

  11. Make other linked PI’s clickable, tooltips to show other active projects, click to view different project titles

  12. Buttons need to be more prominent

  13. More help text and make notices of data updates more visible

  14. Infographics that show PI data


  15. Resource request interface revival, make it a bit easier to follow

  16. 3/4k lines of code that are managing this
    The big pain point is working with the previous version of Drupal and not having the capacity

  17. The interface between Drupal and MSI - some of it is in the Drupal database, but is that the source of truth?
    Old app groups show up as Drupal organic groups

  18. The source of truth is alderapp(?)

  19. Resource requests are an object in Drupal space, but when implemented are sent to other systems

  20. Coldfront - investigation 

  21. We're hoping it handles this PI dashboard and functionality

  22. Hoping to not have to reinvent

  23. Other organisations are using Coldfront and it's becoming the industry standard

  24. Coldfront does not have a storage dashboard functionality - support peeps are rallying for this

  25. Based on Jango

  26. Other challenges

  27. Mike: Major complaint: resource allocation without Drupal dev has limited modification ability

  28. We cannot add or remove workflows from those components

  29. Workflows have drifted away from what we do

  30. Messaging asking people to skip over details - we need to remove elements but are worried it will impact workflows

  31. Running tests has become difficult

  32. No dev space to look at what happens when changes are made

  33. Will take some time to set up

  34. But we can help set up more testing environments

  35. Renewals have just launched right now

  36. Rollout in the next couple of weeks might be challenging with renewals but we could run a parallel space that doesn’t impact

  37. Single sign-on is integrated with Drupal, currently using Off-ticket (old), UofM uses Shibalith

  38. All communicating and automating which is convenient, but do not have the in-house resources to integrate with Drupal 10, we would like to move to a more modern system that has a lot more documentation and resources and is more widely available

  39. Keycloak? - other orgs use this

  40. Daniel: Drupal - some things are in code and some are in Gooey, but there is little understanding about how they communicate together(or not)

  41. We have 300+ plugins

  42. A lot of moving parts and lots to configure

  43. There is a way to extract gooey code (Ian can share with Daniel) - which helps to make the code more accessible with imported configs

  44. Tried changing the tooltip text but when implementing it does not show the changes

  45. Graham: the code is bizarre between dev and prod


  46. Some pieces of code are weirdly set up so that is not accessible to see what its effects are

  47. Likes the idea of separating business

  48. The storage dashboard is not successful

  49. What is the most robust and capable solution - Coldfront plugin, or Open-on-demand fix, there are many options, but what would be the best?

  50. Jim:

  51. Subsystems prevent/reject PIs from making requests or making changes to their projects

  52. People get rejected and a manual system kicks in and then they have to be uploaded because of rejected job codes and are not authenticated

  53. Messaging that helps users understand what info they need to make requests and links to where to get that kind of info to go further

  54. Automatically Checking accounts and creating where they don’t exist 

  55. Sarah:

  56. The backend interface is a total conundrum and difficult to follow - accordions in accordions

  57. Drupal is the front office for providing resources and information

  58. That's where it should end. Find other tools to bring in bigger functionality

  59. Nothing is on Drupal light, everything should be on Enterprise

  60. Drupal meets are available to help learn more about the setup and how to go about creating