I have a document library in SharePoint online. I keep on dumping the records into it. As SharePoint have a 5000 record view limitation the moment it reaches that limit, still I will be able to upload documents but it doesn't show up any where.
Eventually I end up creating a new view and apply a filter and then the document starts showing up under the new view.
My question here is: Is there a way to automatically create a view when it reaches the 5000 limitation and put the newly uploaded documents to the new view.
Yes, you can do this via MS Flow/Workflow & server side apps/scripts of course but it's not a good approach to the issue IMO.
Have you indexed the columns? I just tested this now on a document library with 20k documents and I'm able to filter. There are limitations which you should look into (complex filtering), that's where compound indexes come in.
If you still have issues then I recommend you give the highlighted content web-part a try. You can create custom search queries & it looks similar to a document library if u set the settings correctly. The only meh thing about this approach is there is a delay for search to update, from 15 mins to 6 hours depending on how much data you have
I am working on Notes in MS CRM 2011.
I have many roles over many entities.
I want role based security to notes for any entity records.
let me explain what i want:
Suppose i have an entity namely E1.
Role R1 and R2 has read and write access to E1.
But i want that user having role R2 can only upload and view notes for any record of entity E1.
Hope now my requirement is clear to all of you.
Please suggest me how can i achieve it using MS CRM 2011.
I can think of two ways to do this.
You can create a plugin on create/update of the annotation(note) and check if the note is related to entity E1 and check the roles of the user making the change and see if they only have the R2 role. If that is the case you can throw an InvalidPluginExecutionException with a message like 'You do not have permissions to edit/create these records'.
You can try using role based forms or JS to hide the notes area for R1 users.
You probably want to use a combination of #1 & #2. The users can still access the notes via advanced find and thus will be able to edit those notes. The plugin will prevent that fringe case as well.
*Edit
There are a couple more things that you might be able to deal with the advanced find records. You can remove the annotation entity from advanced find via the unsupported method described here.
Otherwise there is one more thing you can do if you want to prevent those results showing up at all, and you want to stay supported. You can write a plugin on Post-RetrieveMultiple of the annotation entity to strip out the results directly from the return result. There are a couple downsides to this though.
You are executing your plug-in every time the retrieve multiple is called on the entity. So this code will need to be as efficient as possible since that delay will be noticeable by the end user whenever they retrieve these records.
Things like advanced find will display odd results. For example if your paging is set to 50 records and you strip out 10, they will only see 40 records on their page and the total record count will include the records you are stripping out.
Through roles i don't know a way to do that, because you configure the access to notes generic, so applies to all entities. You have to access with Javascript navigating in DOM. Check a example:
document.getElementById("notescontrol").contentWindow.document.getElementById("NotesTable")
You can check this with the help of a develeper tool in your browser.
As a feed from external system we get a Catalog items (They are product info) as part of feed once a day. We need to take this feed and store in Sharepoint. Following are things we want to achive with this.
Need to search those items and show as part of standard search resutls.
There will be Insert (New Items) , updates and deletes to the items. In addtion to that catalog item will have metadata associated with it.
We would not be modifing any of that data in our system. it is just the display only.
I would like to know from the group what is the best way to store this in sharepoint and search on them.
I would agree with the suggestion of a timer job to do a perhaps nightly batch import and update of the sharepoint catalog. The catalog would be stored in a sharepoint list using a content type (set of fields) that you specify which will hold all the product related data for the catalog.
The BDC may well be your answer if it's compatible with the type of data you want to display and would be the easier cleaner option. However if it doesn't meet all your requirements, the above solution would be the most flexible route.
Give BDC (Business Data Catalog) a try. MOSS required.
If you don't have MOSS Enterprise, creating your own TimerJob that imports the Catalog info from this once a day into a list is also an option.
I'm having a hard time figuring out how to refer to a specific Item List within a list in SharePoint. I looked up the page in SharePoint Designer and found that the listitem is inside a custom made webpart inside a custom made webpage. I'm coding an event receiver and need to read the information that the user types into that listitem which is a textbox. Does anyone know the code to do this or how to get the guid for the specific list item?
I would appreciate any help I can get. I have tried looking all over the web for the answer. Thanks.
It might be a good idea to edit your question with exactly what you'd like to do with the information you read. However from what you've said so far:
The ID of the item being edited will already be passed through to the event receiver via SPItemEventProperties so there is no need to look it up. If you need to look up a different item in the list (or indeed in a different list altogether), the Accessing list items using the object model page on SharePoint Dev Wiki gives you all of the options. A good general rule is use SPQuery to get best performance on the whole.
Note: There is a pretty good page on the SharePoint Dev Wiki demonstrating how to write an event receiver. It shows how to query and obtain a list item title.
Update after comments:
Once you have an SPListItem object, you can find its GUID through the UniqueId property. In the "Accessing lists" wiki link I've provided above the code samples show how to use the Title property.
Every piece of data you need to access within SharePoint should be available through the object model. This is a simplification, but generally the pages themselves are rendered from template files on the server and combined with data in the database to display to the user. So editing the page programmatically or through its source isn't going to work.
Apologies if I'm making an incorrect assumption but you sound fairly new to SharePoint development. I strongly recommend you read at least the first few chapters of Inside Windows SharePoint Services 3.0 as the inner workings of SharePoint are important to get a good understanding of and this book should help a lot. There is a section of event receivers in it as well.
Have you looked at SharePoint.ListsService Webservice?
string url = "WSS Site URL";
SharePoint.ListsService.Lists lists = SharePoint.ListsService.Lists(url);
XmlNode list = lists.GetList("ListName");
XmlNode xlists = lists.GetListCollection();
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.