Tag: lists

  • Removing OPTIONS with jQuery

    Here’s a usability solution that was necessitated by my desire to present a logical, workable solution to my end-user.  I’m still learning jQuery so my solution may not be the most elegant – but it works. I welcome any improvements!

    The Setup

    I have a SharePoint site that is displaying the results of an SQL stored procedure.  I’m using Quest Web Parts for SharePoint – qSIListView part which is part of their fine System Integration web parts package.  The great thing about these web parts is that I can create a stored procedure on a database and then use the Filter capabilities of the qSIListView to supply the stored procedure with the parameter values.  It’s a pretty slick solution and very easy to configure.  My problem  is that when you use the filter fields as the Parameter input fields, only the “Equals” operator has any meaning.  I can select “Begins with” or “Contains” but it will only just pass the parameter value and not the operator.  That means that my End User will be presented with a lot of false options.  To avoid the confusion, I would like to present the user with one operator – “Equals”, or in the case where I’m trying to do some wild card matching in SQL, I would remove all but “Contains”.  You get my point.  The problem is that the Web Parts do not have the ability to filter out the operator selections.  I’ve submitted this change idea to Quest for future versions but in the mean time, I needed to find a solution.  My solution was to use jQuery.

    Click to enlarge.

    Solution

    There are many posts out on the web about using jQuery to manipulate the SharePoint interface.  One of the best sites for jQuery on SharePoint can be found on EndUserSharePoint.com.  The solution I am talking about today can be used in any web environment, including SharePoint.  Essentially, my short script removes all <option> elements from all select boxes that match a certain text value.  This effectively narrows the choices presented to the User to only the valid choices, Exclude from search and Equals.

    To do this, I placed a Content Editor Web Part (CEWP) onto my page and pasted my script in it.  In the script, I use jQuery to select all <OPTION> elements of the page and remove them if they contain any of the invalid choices.   The script is pretty straight forward.  I have jQuery stored in a script library on my SharePoint site.  This library provides read-access to all users on the site.  It is also a common place to store all of my scripts.  A good post on creating a script library can be found on here.

    Once I load the document, I have search for all matching <OPTION> elements and remove them.


    <script src="http://mysharepointdomain.com/scripts/jquery-1.4.2.min.js" type="text/javascript"></script>
    <script type="text/javascript">
    $(document).ready(function(){
    $("option").remove(":contains('Does not equal')");
    $("option").remove(":contains('Contains')");
    $("option").remove(":contains('Starts with')");
    $("option").remove(":contains('Ends with')");
    $("option").remove(":contains('Is empty')");
    $("option").remove(":contains('Is not empty')");
    });
    </script>

    That’s it!  The end result looks like this.

    Click to enlarge.

    As I said earlier, this is a pretty simple solution to a problem that I was having.  Now, every time I use filter fields to supply parameter values, I can be assured that I have presented my User with valid options.

    I welcome any feedback!

  • A SharePoint Design Question

    Normally, I write solutions to problems.  This time around, I need some suggestions to get ideas on how to design a solution to a problem.

    The credit department where I work accumulates/produces documents to support the credit limit they grant our customers.  We have categorized them as :

    • Financial Statements
    • Agency Reports
    • Parent Guarantees
    • Other

    We have defined a content type for each of these types of documents.  With each of these documents, one common field is the Company Name field that describes the company that the document refers to.

    The Company is unique in it’s structure.  Each Company can be a Parent company or it can be the Parent to other companies.  I created a Company list that had the fields Name and Parent where Parent was a lookup field type to the Company list.  We currently have the list populated by about 4500 company names with the parent relationships defined.

    List: Company

    • Company Name, Text Field (required)
    • Parent, Lookup of Company List (Company Name field) (not required)

    In the document list that contains the four content types, each content type has a Company field that is a lookup to the Company List.

    When we were discussing how to design this “application”, the user talked about how he would like to have a view where he could see all documents that related to a company, whether these documents applied directly to the company or one of it’s subsidiaries.  Another requirement would be that the documents for one particular company would be easy to find/view.

    As for volume, each company (so far at 4500) will have at minimum 1 of each document types but more than likely will contain 10 – 20 documents with a small growth rate.  There is no document disposition being considered.  From their standpoint, once a document goes into the system, it becomes a historical record for that company.  So – we’re looking at about 45,000-90,000 documents initially and it will grow.

    My original thought was that to stay within the 2000 item soft limit per view, I would create a folder in the Document Library for each Company created in the Company list.  I would then have the users save their documents in the folder that corresponded to the company name.  To achieve the view of the data where they could see all documents that applied to the parent and child companies, I would use the relationships defined in the Company list to create a custom view using the DataView Web Part.

    So – here are my questions:

    1. Do I need a separate folder for each company?  Am I limiting myself?
    2. If we just use a Company Name field using the lookup list, would we run into performance problems?
    3. If we do use the folder, is there a way to automate the creation of the folder when I create a new Company in the Company List.
    4. If we do use folders, is there a way to prevent documents from being created outside of the folders?
    5. Can a document inherit a property from it’s parent?  (i.e. could a document get it’s company name by being saved into a specific folder with the right company name?
    6. (If folder) How do I prevent users from saving documents into the document library outside of a folder?

    I’m sure there are more questions that I need to be asking.  It has been so long since I worked in Designer or the Web interface.  I’ve been living in Visual Studio for the last year.  Leave comments / remarks / insults.  Anything is appreciated.

  • Exporting List Data

    If you have list data that you want to use in another application, what are some ways to get to that data? That was the question posed by a recent requirement from a client. Fortunately, SharePoint presents us with some creative ways to get to the list data.

    1. Export to Excel. This is a good, and quick, way to export data out of SharePoint so that you can use it in other programs. Once you have it in Excel, you can further export it into different formats. The most common is as a comma-delimited text file. I am not an Excel expert but it is quite easy to Export To Spreadsheet from the Actions menu and then save the Excel file in, say, a CSV format. From there, many applications can import that text file. But what happens if one of the SharePoint fields are large text fields that could contain commas and line feeds?
    2. Export to Access. For quite a few data export requirements, I tend to use this way. Access has better import/export functionality. I can save the exported list data in many formats. How do you do this? From the Actions menu, select Open With Access. [Note: this isn’t available in Document Libraries]. From there you can decide whether you want to maintain a local copy or just link to the list. Once you have it open in Access, you can export it in a number of different formats.
    3. If your third part application can call Web Services, SharePoint exposes a lot of functionality via Web Service.  Web Services are beyond the scope of this article but you can find plenty of information on MSDN, like Windows SharePoint Services Web Services.

    What are some of the ways you deal with the requirement of external applications using list data?  I would love to hear your comments!