I have connected excel with AzureDevOps, as explained by microsoft
https://learn.microsoft.com/en-us/azure/devops/boards/backlogs/office/bulk-add-modify-work-items-excel?view=azure-devops
Is it any way possible to export the Parent Work ID in the same row in excel as the actual work item that I am exporting?
What I want to achieve is to sum all remaining work that is left on feature level. This means I need to summarize the remaining work for all tasks under all users stories that belong to this feature.
I could fix this by adding tag of the parent feature in all tasks, but I want a better way.
There can be only one parent. Is there any way to export the parent ID?
Thank you.
Excel can`t import an id of linked work item in the same row. In your case, work items have to contain a parent ID in separate field. I see two ways to resolve your issue:
Create a new field for parent work item types (e.g. summary work). Then with custom solution fill that field with sum of child work.
Create a new field for the child work item types (e.g. parent id). Then with custom solution copy into that field a parent work item id.
Additionally, to avoid customization of your process template you can use Power BI custom reports (Analyze and report on your work using the new VSTS analytics service : Build 2018).
Using excel for analyzing the AzureDevOps work did not really work for all use cases.
The main reason was the ParentId. But basic graphs its easy to do.
Since then I have started using PowerBI instead. And I have managed to achieve all my requirements. After the initial setup its very straightforward to build custom reports in PowerBI.
Azure DevOps has introduced a new feature to make the Parent column available in queries.
Add parent field to backlog and queries
"The parent field is now available when viewing backlogs and query results. To add the parent field, use the Column options view."
Related
I need to implement a solution for a client SharePoint Office 365 site. I know you can do things with 3 parts solutions or Jquery but I'm trying to keep it OOTB as possible. Here is a simplistic view of the scenario.
There is a list called Parent. It has one field Title.
There is a second list called Child. It has one field Title and another Parent
Parent is the type Lookup and points to the Title field of the Parent list.
The SharePoint form is for the Parent List so the main connection points there.
I simply want to create a data connection to the child list and have the Edit / View pages populate that a listbox with the ID(Value) and Title(Display) from the corresponding match in the Parent list.
I've tried several ways but I lack the experience to probably describe what I've tried (Using Rules and the lists.asmx as well as a retrieve data connection to child and filtering it upon load).
Thank you in advance, I really need to get this implemented.
As per your query, I understand you want to open the form on the click of the list item with the view & edit.
for that you have to create the rules with the proper actions like if I click on the parent A then form open but after the form open we have to fetch the ID & title again by the create the connection who dynamically operate as per the call of action.if you need more details please mention comment on this / If I understand wrong the please brief your problem with the example.
Thanks
I need to filter a a table with parameters that are calculated on a non related table, but to do this in Access web I need to add the [Project_Id] to the task list.
To clarify further, the user answers some questions regarding the details of a project, which in turn will calculate in the background a group of parameters that are needed to sort a task list.
The problem is the task list is generic and not related to a project so before I can use the project related filter parameters I need to assign a project id to the task list or there is no relationship and no way of knowing what project parameters to use.
I tried to do this with a query but being a Web database I am unable to select the data from the form control.
Hopefully someone can help me find a solution, because I have exhausted Google and my own knowledge on the subject. One last thing I am unable to use code thanks to security issues.
In case anyone is interested I found away to assign the project id to the task list using data macros.
The data macro is assigned to a table that is related to the project and when updated edits the tasks list to add the current project id for each record in the table.
I still have some issues to work around, but in general it does what I need.
I have two lists in SharePoint, one each for projects and tasks, that I need to relate through the use of a lookup field.
If I create the lookup field in the project list then I can assign multiple tasks to the project and easily see what tasks are assigned to the project and click through to the project. I cannot, however, see what project tasks are assigned to in the task views.
If I create the lookup field in the task list, then I can easily choose which project to assign it to and I can sort or filter the task list view by project using the values in the lookup field, but I can't easily see which tasks are assigned to any given project in the project list view.
If I have to choose one or the other, the latter is the better option since the list of projects is shorter than the list of tasks and I can always filter on the project name in the lookup field column in the task list view.
Ideally, however, I would like to easily be able to see which tasks are assigned to a project from within the project list view, and maybe even edit the relationship from there.
Is there any way to do this in SharePoint?
Thanks!
it will work if you keep the 2 lookup but I don't recommend that the other way around is to create a custom listing web part thru SharePoint API and get the tasks related to each projects
So far the following solution seems to be working pretty well and does not involve the use of any new web parts or custom code.
I have the lookup field (with select multiple disabled) in the task list (the child list).
As stated in the question, the lookup list for the projects is much shorter and easier to use than the lookup field for the tasks. This also allows me to go into the tasks list view and filter on the lookup field (which is also a link to the respective project).
To facilitate easy access to the tasks for any given project, I added a link field to the project and link to the list view that is filtered for that particular project's tasks.
This keeps the list structure simple but allows me to quickly jump between the two lists.
Thanks!
I need to create some functionality in our SharePoint app that populates a list or lists with some simple hierarchical data. Each parent record will represent a "submission" and each child record will be a "submission item." There's a 1-to-n relationship between submissions and submission items. Is this practical to do in SharePoint? The only types of list relationships I've done so far are lookup columns, but this seems a bit different. Also, once such a list relationship is established, then what's the best way to create views on this kind of data. I'm almost convinced that it'd be easier just to write this stuff to an external database, but I'd like to give SharePoint a shot in order to take advantage of the automated search capabilities.
Proper Parent/Child in Sharepoint is near impossible without developing it yourself. There is one approach to that here: Simulate Parent / Child relationship in SharePoint 2007 with Folders & Content Types
(Note: This concerns SharePoint 2007. In 2010, Joins make this much easier)
Do it in a separate database, create a page(s) with controls that surfaces the data and run search over that. Loses quite a bit of the SharePoint features though.
Otherwise it may be okay to create a custom field control that will allow you to lookup the data in the other list.
The custom field control can be the one to "view" the related data.
I know we have done it for parent child relationships between pages on the same list. Not 1-to-N though.
Tough choice either way.
My vote is "to write this stuff to an external database"
You miss a lot of things in Sharepoint things like transaction support, referential integrity, easy way of updating (compare SQL), reporting (using Reporting Services and a SQL database)... see sharepoint as a way to store documents and simple lists.....
The argument for Sharepoint is if it is a small application, no requirements on support for transactions, no need to import external data etc...
When people say Sharepoint is a development plattform there is a need to define whjat they think a development plattform is.
The latest rumours about Sharepoint 2010 tells us that there will be support for SQL server based lists in next version ..... which I think will at least move Sharepoint in the right direction ....
Take a look at SLAM, SharePoint List Association Manager, an open source project my company created and actively supports. SLAM allows you to synchronize SharePoint data to SQL, including any relationships between lists. SLAM, in addition to being very useful on its own, is really a framework intended to allow developers to create their own complex data associations using what we call SLAM type profiles. We have one out-of-the-box type profile which is part of the open source project which actually allows you to make a SharePoint list hierarchical using the nested set model. For more information, see this page on our codeplex site.
I do this a lot just using sharepoint, using a framework called AAA (Activity,Assignment,Artifact), which allows you to use lookup columns to link an assignment or artifact to a parent Activity. You then build a web part page with connected web parts that allow you to filter all assignments and artifacts by activity. For example, click next to a submission in the submission web part, and all of the submission items attached to that submission will show up. Works great.
The other approach that you can look at using is persisting XML with a field in the item. This is the approach used by the Podcasting Kit (on CodePlex) to store things like ratings.
One possible method is to create a submission content type based on the folder content type and a submission-item based on item content type. Then you can store data hierarchically like in file system and also will work default views and search functionality.
Other way is to create lookup field that points to same list (list=”self”). This field will be used like reference to parent item and you will get list that contains recursively related data. To use this data programmatically will be ok but using views functionality will be little bit complex.
It's easy to do using a connected web part.
Create two lists:
Parent (Id, Title)
Child (Id, Title, ParentId)
Create a new sharepoint page, add DataFormWebPart (displaying Parent) and another one for Child, set both of them to filter based on a QueryString parameter (use that Parameter to filter Parent.Id, and Child.ParentId) voila, you can display parent-child relationships. Now, adding children is more difficult, and that's the part I haven't worked out yet.
I want to show the documents in my document library grouped by category. The category is a lookup column that I added that allows for multiple values. Unfortunately this breaks the "group by"-functionality completely. Is there a programmatic solution to this problem?
There is one way... It's complex and ugly - but it should work :)
It is possible for you to write you own view for at list (HTML, JavaScript and all). The VWSTYLES.xml file in the C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\GLOBAL\XML folder, contains the HTML and JavaScript for the default SharePoint view styles - getting your inspiration from this, you can create your own view style, where you can do anything you want!
The problem is, that SharePoint don't have any way to deploy your custom view style - this is where the ugly part comes in - you have two options for deploying your view style.
Add you code directly to the VWSTYLE.xml/Edit a copy of it and override it with a feature
Pros:
You will still be able to edit the
view from the SharePoint interface
Cons:
You override a default SharePoint
file - your work can be overridden by
a SharePoint update.
Your view style will be available on every list in SharePoint.
Create your view programmatically on the list
Pros:
You don't override any default
SharePoint files.
You can control which list uses your
view
Cons:
You wont be able to edit the view thru the SharePoint interface
I've used method 2 a couple of times myself - and it works... but it's not pretty! :)
I don't think what you are trying to do is possible. When grouping items/documents, you display them in different groups based on a grouping value. I don't think SharePoint has support for adding a single item to multiple groups. With multiple values in the grouping field its' impossible to know which group to add the item/document to. I am not sure if this is an error or if it's by design.
Thomas is correct, this is by design as the item would have to appear multiple times in different groups. It is worth noting that this is possible via the web services, however.
See why I was getting duplicate rows from the sharepoint lists web service
And no, I've no idea why the lists webservice will do it, but the API won't.
Check out this link as well. Access supports this functionality without having to do much ugly code. http://office.microsoft.com/en-us/access/HA012337221033.aspx
So here is a sort of hack that has worked for me, no guarantees though. While your column (Office in my case) has allow multiple values enabled, fill in all of your data as needed. Once done, go to List Settings, click the Column "Office", and turn off allow multiple values. SharePoint will pop up a warning about how this data may be lost (never happened to me). Hit okay, then modify the view you want grouped, "Office" should now show up on the drop down of columns to group by. Finished result will result in your groups (and or sub groups) showing up just fine.
The only qualm I have is that instead of having an item show up in both Group A B because it had both field A and field B checked in Column X, it just creates a new group, Column X: A; B. So in my case, I have staff in both Beaufort and Orangeburg Offices, instead of having those staff in both groups (preferable) it creates a new group as below: