I am building a phone catalog of my organization (an AJAX application which accesses the search.asmx web service).
I'd like to show a list box where the user could select a department (which is stored in managed property Department). To fill the list box with values, I need to somehow select all the distinct values of that property.
Is it possible through search.asmx web service?
What I've found:
an article, which states that it is possible, but it does not use the web service interface
a Microsoft's white paper which states that "If the protocol client specifies at least one property, it MUST also specify the Path property. If it does not, the protocol server MUST return the status code "ERROR_BAD_QUERY"."
The two findings are somewhat inconsistent. (and, yes the search really returns ERROR_BAD_QUERY).
Why bother to check with the web service or complicate it?
Get all the properties into a DataTable.
Then create a DataView & then you can apply the DISTINCT on required column.
Finally use it to bind to your list box.
Related
In the API-Management's Developer Portal, we have the problem that all Operation (API) calls are listed in a long list, making it difficult for our customers to find out what calls that belong together. What we'd like is the possibility to group calls by something, i.e. the controller name. (In Swagger this can be done by using the tags field in the Swagger specification.)
In the templates section, there's an option Operation list (grouped), which, by the name of it, might be able to solve our problems. But how can I use this template?
I'm currently importing the API list using the OpenAPI specification.
Update 1:
This is what it looks like in a sample operation list for us. There's no search box available.
(grouped) template is used when user selects "Group by tags" option - rightmost button next to search field on APIs/operations list. Here is how it looks on UI:
I have a custom page type for employees, and one of the fields is Location. I want to show/filter only employees in "San Jose" or "San Francisco" and used this WHERE condition below but it didn't work. Apparently, I missed something very basic. Could you help?
Location LIKE '%San%';
I did another test, where instead of page type, I used custom table with the exact field names and was able to filter using the same statement. On a related note, I'm new to Kentico and exploring which is more suitable for creating/maintaining a list of about 100 employees - Page Types or Custom Tables - with the ability to filter by department, location etc. Appreciated your input here as well. Best!
If you're adding the WHERE condition into a standard Kentico repeater or other data source, the syntax looks right except you do not need the semicolon ";".
You'll also want to double check the field name, and if you are limiting your query to certain columns (as is best practice especially for larger data sets) and be sure the field you are filtering on is being selected.
Regarding the management of your employee list, either method you've described will work. In that scenario it typically depends on who will be editing the content, and how frequently. It is more editor-friendly, in my opinion, to add those documents into the content tree. This also gives you quicker control over the order, and keeps it similar to how other content on the site is maintained. I also like to set up folders or other parent page types as categories if needed, so the documents can be dragged and dropped between them and it sets up a visual taxonomy that isn't possible if it's all stored in a table. Storing items in the tree also allows for workflow and versioning, as well as more granular control over permissions/access, if this is important to you.
It's awesome that you are thinking about how to best store your data in advance. There many factors to consider such as overall number of records, number of columns, the fact whether you need to use workflow, versioning, preview etc..
The best source of information regarding this would be this article which summarizes all options you have and gives clear explanations of which to use in which scenario.
And to your original question - What components are you using to display the data? Is the repeater? If so, can you make sure to set the Page types property to match the page type you are displaying? If the page types is not configured, Kentico will not load any custom fields because it doesn't know from which table it should load the data from.
Additionally make sure to either include the "Location" field in the Columns property or leave the columns blank (not recommended because then Kentico loads all columns which is like 200. when you count all from CMS_Document, CMS_Tree etc..)
Below is the framework that I use to debug whenever I wish to add a repeater and is facing some problem.
First get all the columns instead of accessing limited columns. Fetching all columns will make sure that I don't have any problem retrieving data.
If I am missing any particular column information name, then I would double check the column name.
I verify this by firing up SQL server management studio and access data from page type table or custom table.
If access to SQL server is not available(generally in Azure hosted solutions with restrictive access to DB), I would enable SQL debug from the settings and see what query repeater is generating to see if it is correct.
I have column Status (0= Default, 1=Accepted, 2=Rejected), when first creating this list
I want to hidden this field and filling it with default value (0).
On edit form, I want to hide this column from updating if user role is not HelpDesk.
Thx
For your first requirement, you could use SPUtility.js (full disclosure this is a library I maintain). You would basically put some JavaScript in a Content Editor Web Part on your NewForm.aspx page:
SPUtility.GetSPField('Status').Hide();
If you want to change the value (if you don't have a default specified in your list settings) then you could do:
SPUtility.GetSPField('Status').SetValue('Default').Hide();
The second requirement is a bit tougher. You don't really specify how the user gets a role of "HelpDesk" (profile property? SharePoint group?). Depending on how it is setup, you may be able to use an AJAX call to the SharePoint webservices to check their security. Or you could write a custom webpart that validates their role and then emits some JavaScript.
Use Infowise Smart List Lite, the free version of our Smart List Pro product. Your requirement is just one of its many features.
I have a profile weblog that contains all our users details (fields seperate from the membership).
These users can submit application forms with the use of a SAEF (stand alone entry form), which will be stored in an applications weblog. Inside this applications weblog, I have a relationship field which assigns a profile to an application.
Inside this application, radio buttons are contained to allow an admin to change the status of that application (an example, a judge views an application for Joe Bloggs and sets this application to “winner”).
What I essentially need to do is filter out all the profiles that have not been set to a number of status’. So if I apply for an application and the judge is yet to view this application, my profile should not appear in the search results. My idea of this is that I would somehow have to intertwine search results with a reverse related entry tag, and as my knowledge of the search module is limited I am at a complete loss if this is even possible.
As you can see, not only do I need to search by custom field, but the profiles that will be displayed should be determined on custom fields contained in the application entry.
I would suggest using the "status" option instead of the radio custom field.
Why? Because you can accomplish the same thing you want to do with the radio field and you can set what entries you want to return in your search results.
For example, you have a status group called: "Application", which is assigned to the that weblog/channel
Within the status group, you will have three options: Pending (waiting to be looked at), Loser (judge sets it to this because it is not a winner, or just as pending), Winner (judge considers that application a winner).
Then in the search tag, you would set what statuses it will return in the search results
so if you want to only return applications/profiles that were marked winner, you would set the status="status_id" (this will be the id of "Winner" status)
I'm trying to figure out a clean way to hide a custom field type from the list of available columns when a user goes to add a new column to a list. I only want this field type to show up when a given feature has been activated (the feature could be site, web, or web app scoped for my purposes).
One theory (haven't had a chance to try implementing this yet) is that I could set all the ShowOnListAuthoringPages (and similar) properties to "false" in the fldtypes_myfield.xml file, then programmatically set this value to true when a given feature is activated.
In XML file, please set
<Field Name="UserCreatable">FALSE</Field>
I't work with me
Are you sure that you are able to see the Publishing Fields Type in the List Create Column Only with Publishing Infrastructure feature activated. I have a MOSS 2007 Server and I Create a Site Collection based on the Team Site (In this Publishing Infrastructure was not active) but still I was able to see the Rich HTML Fields in the Create Site Column Page. I doubt Publishing Infrastructure controls this function. Your option is good one for this, I would say.
Custom Field Types Features are per definition Farm Scoped, since Custom Field Types have to be deployed farm wide.
You cannot "hide" them from users. A field in a list is based on a field type (bool, user etc.). You CAN hide fields, not the base types. So if a user wishes to create an entirely new (site) column, he or she 'll be able to see that field type.
So, it does look like the only way to do really hide the field times is with attributes in the fldtypes_myfield.xml file. There are a series of properties that affect it's visibility described in this MSDN page. In my particular case I ended up just using the UserCreatable property and marking it as false. This pretty much means the field type won't show up in the UI anywhere, so you'll need to make a feature or some kind of list/library template that you deploy that makes use of the type. I guess this is an area we can hope for improvement on in SP 2010 (perhaps along with a scoping mechanism for event receivers so they don't have to be "global" in the farm).