This question is about root drive items in SharePoint drives, i.e. document libraries (because doc. libraries are backed by drives).
Namely, in a SharePoint site, I have multiple document libraries: the default one (called 'Documents') and a few more (let's call them DL1 and DL2).
To get the root drive item, in the drive backing DL1, I use this:
GET https://graph.microsoft.com/v1.0/drives/dl1-drive-id/root
I use a similar query to get the root drive item in the drive backing DL2.
However, all of those root drive items have the same ID. The drives, of course, have different IDs.
I tested this on two tenants and it's the same behavior. Is this expected?
The element IDs are not guaranteed to be unique outside of their parent scope (for this case, parent scope is root folder of the document library).
However, the fact that root elements in different document libraries have same IDs is the side effect of the SharePoint provisioning process. As Jeremy Kelley (one of PMs that works on Microsoft Graph APIs for SharePoint) wrote in an answer to my question on Twitter: "Most provisioning of things in SharePoint is optimized partially through the use of static templates to stamp things out rapidly. Which means each thing created using that template has the same ID."
Can you elaborate: How do you retrieve Drive IDs?
You should first retrieve correct Drive ID based on the SharePoint site by performing
GET /sites/{siteId}/drive
or for the Microsoft 365 Group
GET /groups/{groupId}/drive
and then you can refer it by correct ID. You can test these queries in Graph Explorer https://aka.ms/ge
The official documentation for different use cases for retrieving drives is here: https://learn.microsoft.com/en-us/graph/api/drive-get?view=graph-rest-1.0&tabs=http
Related
I have a requirement in a Sharepoint 2013 setup wherein I've to give access to external users to a document library. Each User will have a folder by their name, and would be allowed to ACCESS their folder ONLY. They are not even allowed to see each other folder names. They can anytime upload additional or delete the existing documents. External Users are setup using FBA.
Inside the network, there is a Windows user who'll have access to all the folders and documents of that library. I don;t think standard document library can handle this since there is no "Deny View" Permission in Sharepoint.
Sharepoint Folks - Please guide what will be the best way to handle this kind of requirement.
I don't think having a bunch of folders makes sense. However, you could have users upload documents to the shared documents library and have a column in the documents library of the user's username. You could then create a content query on that list to query documents that the current user uploaded. You could then replicate a "folder" type of feel by creating this page, styling it, and directing all users to it.
Let me know what you think of that.
There actually is a way to deny all users. Remove the Authenticated Users, and Remove Anonymous Access from the Library. I agree, that using folders is the wrong idea here. Folders can cause much more harm than help in certain situations.
Create a site to hold multiple libraries, or disinherit the site, remove everyone not essential to the libraries, and use it as a container for the document libraries. Each library can still have it's own unique permissions, and without Authenticated or Anonymous, you'r essentially telling SharePoint that none has access except for the users specified in the ACL's on that library.
You COULD leave the permissions intact on the site and powershell the creation of the document libraries within the site, assigning custom permissions.
I am beginning sharepoint development and have some quick questions concerning basic terms.
How do i find out whether a particular site is a site collection, or a site JUST BY THE URL? Is their a powershell command to do this?
I was creating some sites in sharepoint. Some sites were appended with /sites/sitename whereas others were just under the base url of sharepoint. What is the difference between the 2? AND, how do i recreate the ones under the sites node? For some reason, I cant find the option to create under the sites node again. Please explain this concept as all msdn tutorial are very confusion for beginners like me. Those are good once you get the hang of basics.
Please provide an analogy how to understand web app, site collection, site, web site, etc.
Is there a way to use NEWFORM.aspx for a document library instead of UPLOAD.aspx?
The Site collection is at the root level of your Web application.
So http://abc.com/ => Site collection
Using Powershell, open the Sharepoint Powershell prompt and run Get-SPSite to get all Site-Collections
the /sites/ is called as a managed path
It can be defined in the Central Administration for every web application.
The option to select the /sites will be available only when you create the second site collection under the Web Application (The first one take the / by default.)
Have a look at Technet Article
document library is for uploading file, not for storing user submitted data, for that you need to create a list
1) Document Set is used in cases where multiple documents have the same properties, its like putting all these documents in a folder and then providing attributes to that folder which are in turn applied for each document in that folder.
In your case, if all the files have the same values for the 8 fields then the document set is the correct way to go.
2)If there is additional metadata associated with the files then these can be added either to the content type (eg. document or document set content type) or to the columns in the library itself, you dont need to create a separate list for holding that data. Adding data to the content type ensures consistency across all the document libraries within that site collection, adding columns to the library affects only that library.
I have a document library with a few files in it and I've noticed that doing a search for files in the document library (even the exact file name) does not seem to give any search results. The search does seem to provide results of terms within lists (such as Project Tasks) thought.
Does Sharepoint Services 3.0 index files within document libraries? I've gone into Advanced Settings of the document library -> Search and made sure the radio button is set to 'Yes' (it was 'Yes' by default).
The short answer is Yes.
The long answer will require some further reading as I can't remember how or where to set it up and of course there is always the chance you have it configured but it just isn't working.
OK, after doing a little digging around it turned out the Service Account and Content Access Account in SharePoint Central Administration > Operations > Services on Server > Windows SharePoint Services Search Service Settings were both set to the in-built user "Local System" which didn't have the permissions to fully index the site. What was odd was that it was indexing the lists but not the documents - I presume a different type of indexing operation is done on the two.
I created a new user on the server with the relevant permissions and assigned that to the Service and Content Access Account and within minutes I could see the Document Libraries within the search results.
To quickly summarise my question:
Is it feasible to programmatically change the name of a directory (with both files and sub-folders) in SharePoint? I am expecting that users will have files checked out on at least some occasions what I am attempting the rename.
The background:
I am currently contracting for a company that produces web based software (ASP.NET) with a configurable document management system. The system can be configured to use different underlying systems, with the most common environment being SharePoint (WSS 3).
I have been assigned a task to extend what has to now been a fairly simple system (simply output files into a fixed directory structure, occasionally read). Having never worked with SharePoint before I am doing some research on best practices, and am attempting to work out what is viable. At this stage I do not have access to a testing environment myself, so am limited to reading up online.
One request is to have the directory structure reflect the name (as one example) of the current client - so all documentation for a client will be in one place, and can be accessed externally via SharePoint or other compatible applications. The specification cites that if the name of the client changes then the directory structure should immediately update. My concern is that this will either directly cause errors (eg. Permission denied) or indirectly cause errors (loss of work for users who have externally checked out files).
As a follow up question if there are concerns with the above, is there a better way to implement the above? I have looked at suggesting the users use views to access the structure in SharePoint, however there is a concern from our BA that users will not be able to directly upload new files into this structure.
Thanks
The issue with Folders in SharePoint is that they are not really folders in the way you would expect of a file system. All files in a SiteCollection are stored in one big-assed table on the Database (checkout the AllDocs table).
I cannot categorically say it is safe to rename the folder without doing a bit of testing, I know that the folders "name" is not the key to accessing the document, despite it appearing to be based on the Url you see in the browser.
The best bet is to do a quick test, but I am pretty sure that your plan will not be a problem.
The potential issue is if any Content Query Web Parts etc rely on specific folders to exist or if any other "code" or "pages" look for that folder and not the folderId.
Save the content of the list before you "attempt" it in production. You don't want to loose data.
Checked out documents will still work the way you expect them to.
You may however have to run a crawl again.
SharePoint 2007 (both Moss and Wss) exposes document libraries via web dav, allowing you to create documents via essentially file system level activities (e.g. saving documents to a location).
SharePoint also seems to expose lists via the same web dav interface, as directories but they are usually empty. Is it possible to create or manipulate a list item somehow via this exposure?
In short: No.
Longer answer: Kinda. Any item stored in sharepoint is in a list, including files. But not all lists have files. A document library is a list with each element being a file+metadata. Other lists (like announcments) are just metadata. Only lists that contain files are exposed via webdav, and even then you are limited to mucking around with the file - there is no way to use webdav (afaik) to edit the metadata.
Hope this helps.
Oisin.
Agreed. The only thing exposed to webdav is a list item's attachment (or a library's documents). Even if you bring up a file's properties in explorer, there's no options for list data.
If you're working with Office 2007 documents, you can create a document information panel that can be tied into sharepoint.
No, but in my experience most things looking to speak WebDAV to something are pretty much expecting to work with files or documents of some sort. Since non-library lists in SharePoint don't really have an associated file (yeah, they can have attachments, but that's not the same), then effectively the primary construct WebDAV is built around (document) is missing. What would you be Authoring and Versioning?
If you are writing your own client, there are robust web services for interacting with lists (both the library and non-library varieties)