I've got this one thing I'm not really sure where to begin with. In our SharePoint 2007 solution, we've got this project room where each employee has their own folders with their resumé etc. And we want this information to be distributed to their MySite.
I've noticed that I can basically copy the files from one are to the other. But the files in MySite are connected to the corresponding user based on properties of some sort. But they are not regular file properties is seems. When I open all of the files in the MySite files collection, I can see categories such as Title and Name. If I copy a file in there, these properties are blank. And if I manually assign a username to the Name property, the file automatically appears in the correct user's MySite.
Probably horribly explained.. But, is it possible to program this somehow? I would like a nightly or weekly schedule that basically copies the content and assigns the username and title to the correct fields. I can pick up both the title and the username based on the folder names. This I can probably solve later. It's just where to begin that's bothering me. Do I use SharePoint designer? Can I user VB code? Do I have to code at all? I've never developed a thing for SharePoint before. And no, I do not want to be redirected to a basic "Getting started with developing for Sharepoint" site.. Just a simple answer really, on where to begin.
Simple answer: Yes you can use VB. Create Timerjobs.
TimerJobs you can set to start on specific weekdays, specific hours etc. and they do exactly whatever you program them to do.
Related
I have a SharePoint Online list that uses folders with unique permissions. Each user can only see their own personal folder and the items inside. I set the default view to show content inside of folders rather than flat. In SharePoint, the user first sees their personal folder at the top level of the list. They click on the folder and add items inside of it in order to keep them private. Seems to be really tricky for a power apps beginner like myself to create that in power apps and I'm looking for some ideas on where to start.
I know I can make the start screen gallery be filtered by only showing things that have a content type of folder. Hopefully, this would respect permissions and show each user only their own folder like in SharePoint Then, when you click on the folder, it would take you to a gallery on another screen. But this screen would have to be filtered to only show items that relate to the folder clicked on. SharePoint does this naturally. So the second gallery would have to somehow be filtered by knowing what was clicked on to get to that screen. I don't want to make a screen or even a gallery for every user case.
Also, I need to make sure that any entries on the second screen are being entered into the person's folder rather than the top root. SharePoint seems to record it as being under that folder, but will power apps do the same?
Can anybody get me started or give me some ideas as to how to approach this? Maybe an article that solves a similar problem? I couldn't find one yet. Thanks.
If users don't have directly access to share point is the best way for build your app, you may put all file in the same folder and filtered by a column with user informatcion, for example: column isFolder with values ["Yes", "No"] yo can filter and show in gallery only folders and column userEmail you can filter folders for a especific app user.
In case users have access to sharepoint you must create a connection for each user folder to collect files inside and show it in second screen and populate gallery with condictional (switch or if), for example: Gallery Property:Items = If(User().Email = FirstGallery.Selected.userEmail, colForThisUserName)
So, I've run into a VBA problem. Due to IT policies I can't control read/write access to my Excel files on folder level, but have to do it for each individual file. I have a folder with 15 files, that everyone having access to the folder can access and write in. On a certain date I want to lock these files down, so that only a specific group can write, but the rest can still read.
I'm aware it's realtively easy to do this manually (File->Info->Protect Workbook->Restrict Access), but since I already run a macro for other reasons when we want the files locked down, I'd like for it to do this part too. This is where I run into my problem:
I've figured out how to set the permission for a specific user, using this code
Sub set_access()
Dim UserPerm As Office.UserPermission
Workbooks("workbook name").Activate
Set UserPerm = ActiveWorkbook.Permission.Add("name#company", msoPermissionFullControl)
I can loop through this for each person I want to have writing/full access, no problem. There's like fifteen of us and I know who we are.
The thing is I also want everyone in my organization to retain their reading rights. This has it's own button if I do it manually (in the Permission menu that is accessed as mentioned above), but I can't understand how to trigger that setting via vba. I've tried to record a macro of me doing it manually, to see the code, but nothing is recorded. I've also read just about everthing I could find online like four or five times, and what I need simply doesn't seem to be covered.
Does anyone know if this is poosible? Or if it isn't; can I reach the same results some other way?
tldr: I can set permission by individual, but in addition to this I want to give a general read-only access to my Excel files for anyone in my organization. Can this be done with vba? If so; how?
I had the same problem and was looking into it. After all, by using "Everyone" instead of an email address, I was able to set permissions for everyone in my organization. try it.
I am working off of a great solution created by #MattHall from 2011 to a question that I also shared about importing a dynamic range from Excel into Access.
Specific to that--though in general for future VBA's--my question is whether there is an additional way to be able to point to the Excel source file if it is moved without having to go into the VBA editor every time?
For my specific needs, I am trying to work on these Access and Excel files with others through a shared BOX that has a different file path for whoever is working on it.
USER 1 may be: C:\Users\USER1\Box Sync\filename.xlsx
USER 2 may be: C:\Users\USER2\Box Sync\filename.xlsx
...and so forth for any other users. I am curious how we can all work off this when the file path used in the VBA created and used by USER1 is not accessible by USER2? Could there be some code that allows for the every user to locate the file each time through their own filepath?
It would be a pain to do that but I also do not know a better option as we are not working off a shared server and this is unfortunately limited to Box share at the moment.
EDIT: If anyone could also suggest how to integrate their recommendation into the 'Dynamic Range' code in solution from #MattHall in the linked Stackoverflow, that would particularly helpful to my request.
Is there a way to change the name of a folder within the discussion area of SharePoint 2010? The folder by default is given the name of the discsussion name when it is created, however, if you then change the discussion name, it does not (quite rightly) automatically update the folder name - I would like to though.
Just had a go there, I was able to rename it using SharePoint designer (use the All Files link on the left).
However if you need to do it automatically then you'll have to build an List Item Event Handler, and update the folder name using the API using the ListItemUpdated Event.
Shane
One of our customers has a problem that we cannot reproduce. We programmatically copy a document's properties to a destination file using SPFile.Properties. However, for some reason the file's properties do not match the meta data specified on the list the file is stored in.
Now, we can probably solve this by copying SPFile.Item.Properties (not tested yet), but I am just wondering under what circumstances SPFile.Properties is unequal to SPFile.Item.Properties.
Update: We have just received an update from our customer. Using SPFile.Item.Properties always returns the up to date information. However, we still would like to understand the original question.
There is a slight difference between SPFile.Properties and SPFile.Item fields and the first one is much, much slower to call.
You have most probably seen Microsoft Office document's "properties" window (this one - http://dradisframework.org/images/tutorial/custom_document_properties.png). These are the properties that are read when you access SPFile.Properties. Reading them is slow since there is some code infrastructure that parses the binary DOC file and finds the properties. (takes up to 30 or something milliseconds for every property access) See more here: http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spfile.properties.aspx
In SharePoint, every item is an SPListItem and its field values (and I don't use the word "properties" on purpose here) are stored in Sharepoint's content database. So, when you access SPFile.Item.Properties, you actually look at the SPListItem to which the file is attached and look at its properties from SharePoint's content database.
What happens behind the scene, when you upload a file having some "Office properties" set, is that SharePoint copies them to same-named fields in SPListItem. (Some information about it here: http://weblogs.asp.net/bsimser/archive/2004/11/22/267846.aspx)
This is why these properties typically have the same value, BUT it only happens if SharePoint knows how to read metadata from your file and write them back. So, in case you put a .txt file in your SharePoint store, you will not get any SPFile.Properties back.
The user will always see the ListItem Properties and not the SPFile properties in a document library. So using the ListItem properties in the copy is the way to go.
I believe this issue is related to the Sharepoint property promotion/demotion feature which enables document properties to be embedded in the physical MSOffice file and travel with it to the client etc. This however is only supported currently for Office file types (to my knowledge).
Jonathan
Trying to find the "official documented" anything for sharepoint is pretty much undoable. :-D. The online docs suck, you are better of using blog entries etc.
P.S. I agree with Alex here. Although an SPFile never exists in a list without an accompanying SPListItem, the connection between the 2 can get corrupted (i.e. being able to edit the list item but the file is not openable). This to me indicates information about the 2 is stored in different locations in the content db. I have had this happen before.