Forum Discussion
Question: Custom Webpart for Project Site
Greetings,
I am trying to better understand the development potentials involving custom Webparts & Project Sites. Or more plainly: if the basic ideal I am wanting to develop is possible, or if there would be a manual configuration for each new Project Site.
I will give a basic overview of our current configuration (rather unique), and envisioned solution. [If it helps, we are a Construction company, so we are utilizing PWA a bit differently than most use cases I’ve researched.]
Basic Overview
We are using PWA/Project Online. Each project created also generates a Project Site.
PWA – Master Lists & PDPs
At the PWA-level [https://contoso.sharepoint.com/sites/PWA] we have 7-8 ‘Master Lists’, which are utilized by every Project. Currently, these lists functions as Change Registers/Logs… examples: Submittals, Change Orders, Requests for Information, Purchase Orders, etc.
Each Register/Log (List) is hosted on its own PDP. Each PDP has 2 Webparts: List View & Query String (URL) Filter.
The List View connects to the List/Register/Log. The Query String webpart is using ‘ProjectID’ as the QueryString parameter. Basically, depending on which Project you have opened, the PDP/List/Register you are interacting with is filtered to only show list items which match the ProjectID.
Project Sites – Document Libraries
At the Project Site-level, we have a classic Document Library, which accepts all Content Types, and 7-8 Modern Libraries, configured to 1-4 Content Types each.
Current Workflow
- Within PWA, on a PDP page/Register, with the Project ‘checked out’, the users clicks an ‘Add New Item’ button.
- The user is directed to a form that the fill out. [Note: JSlink/Jquery is used on the form to hide & autopopulate certain fields, such as ProjectID, ProjectName, etc.]
- The user saves the form and is redirected to the PDP Page.
- [Most Register Items will have a document(s) associated with them] & the user will click the Upload button on the list item.
- A modal pop-up appears to select a file to upload.
- Select file and click ‘Next’
- Select a Content Type [*Note: Depending on Content Type selected, you be given metadata fields to populate. The SAME metadata fields populated by the user in step 2.]
- The fields are populated, and the User clicks save. [RelatedProjectItem is automatically added to the document’s metadata, as a link between the Project Site-level document and the PWA Master List item.]
- The file is automatically sent to the Project Site’s classic Documents library
- Simultaneously: A Flow kicks-off which copies the file into a Document Library which matches it Content Type.
The issue: Things happen in multiple places [PDP page, Form, Pop-up, Project Site] & metadata has to be entered twice.
Envisioned Solution
The ideal is to develop a custom webpart, which will be hosted on the Project Site, on a Site Page.
Initially, the webpart’s property pane would allow the user to select a List (or all of the Master Lists/Registers), and configure them to:
- Get the PageContext (Project Site’s URL, etc)
- Compare the above Context to a list, at the PWA level, that is created via a Flow collecting Odata (example columns: ProjectName, Owner, InternalWorkSpaceURL/ProjectSiteURL, ProjectID, etc.), to find a match ProjectSiteURL, and then to get the ProjectID (for filtering)
- Whatever else would be necessary to make it function like a current PDP page with a List being filtered by a Query String Filter URL, to only show List items related to that Project.
The Site Page would be saved. The Project Site would be saved as a Template. The Template would become the new Project Site Template in the EPT.
The Million Dollar Question
Would the webpart be able to automatically be configured, based on the original setup?
Or…
After a new Project is created… would a user have to go to the webpart Site Page, on the new Project Site, and configure it for that specific project?
Is any of this feasible?
Much appreciation to anyone who spent the time parsing this mind dump!
-TR
Hi tayram ,
It sounds like you have built a nice solution but I understand the optimisations you are trying to achieve. A custom web part (SPFx etc.) would be able to dynamically get certain properties so it should work fine in a template. One question though, why don't you just use the lists on the Project Sites for the registers /log (Submittals, Change Orders, Requests for Information, Purchase Orders)? That way everything would be associated to the project automatically and take advantage of the out the box access model. I guess on the "master lists" at PWA level, you have to have item level permissions so users can only edit the list items for the projects they have access to or can all users access / modify all list items on the master lists?
Paul
Paul,
Absolutely appreciate the reply. (Although, I should also say that I appreciate your years of wonderful content, across forums and your blog. You have been a vital asset to my personal explosion of knowledge of PWA, Power Auto, REST, Odata and all the fun stuff, so thank you!)
"Why not use lists at the Project Site level..."
My mind keeps going to this ideal. My main concern is breaking our custom PowerBI (not my strong suit) report, and creating a cascading clean-up for myself. Yet, using Power Automate to write the Project Site-level lists upwards to the PWA-level 'master lists' seems like it would fix much of this issue. There are 1-2 other concerns with making this move, but they aren't coming to mind at the moment.
"Item level permissions..."
This is one of my biggest concerns with developing the aforementioned webpart, and currently a topic I am digging into for possible solutions... without making Project Permissions (and adding the same folks to the Teams Team) an even more cumbersome process.
I have thoughts of completely overhauling our current PWA configuration for permissions & the resource pool itself... but first, I have to get onboarding alignment with HR and IT! Switching to Sharepoint Permissions Mode might actually fit us better once I move more to a PWA platform that is focused on the Project Site (and Teams), rather than half of everything occuring within the classic PWA PDP framework.
On another note...
I came into my current role (inherehited "what is") without any background in MS Project, the Admin side of SharePoint or the Sharepoint Framework... yet, after a year, I am starting to see that the choices, and expensive customizations made before my arrival, have almost locked us into an out-dated box. At this point, I see my goal on this front as trying to put us into a bigger, better framework, without breaking too much of the connective tissues that I do feel is important & functional.
I've brought up the possibility a few times, with our COO, about potentially reaching out to you for consulting purposes. Your reply here only reinforces this ideal. What would be the best way of getting the ball rolling with contracting your services on the consulting front?
Much appreciated,
TRHello PWA_Service ,
It's great to hear that you have found my content useful over the years - makes it worth while, thank you.
I understand the Power BI challenge with querying lists across sites but there are solutions to that challenge. Using the lists and libraries on the Project Sites would keep your solution simple - probably all out of the box, minus the reporting side of things.
I'm not sure I would switch to SharePoint permission mode - not unless you are happy to manage the team members access to each project site manually?
The thing to also consider, depending on your project management requirements, have you considered Microsoft's latest project tool - Project for the web? Project for the web alone wont meet your requirements due to the registers / logs, but building an app in Power Apps might?
I'm happy to have a chat about how I might be able to help you / point you to a Project partner who can etc. I'll drop you a private message regarding that to keep this post focused.
Paul
