I would like to use a jsr query to figure out what state a particular item is in (this is for an auto indexer). I would like the index to only include items in the public state. The fast forward examples don’t really show an example of this.
When doing a "Select * " on the JSR-170 test query page, I don’t see anything that I can use that can give me back the state of the content items. I would prefer not to have to rely on the sys_contentexpirydate. Is there another way to do this, or do I have to use the expiry date?
Update: I am doing a select * from nt:base (and also tried rx:rffgeneric to get just only that content type) to get a list of all properties, but that still doesn’t include rx:sys_folderid, so there must be something else going along because clearly i can get the folderid if i specifically query for that column name. Documentation (pg 188 on the implementation guide isn’t too forthcoming)
There’s no way to get the state of an item in a query.
A better way to do what you want to do is provide your own “item filter”. If that won’t work for you, you have to combine raw SQL and JCRQueries. I’ve done this (I had to add SQL methods to the PSOToolkit) but I don’t have a working example at hand.
Ah,
I was afraid of that. I was hoping that the solution was something simple I was missing. I think I will settle on using the expiry date and just rely on end user training to teach them that the expiry date must be set without any regard to the workflow state in order for the item not to show up in the auto indexer.
I am curious about the rx:sys_folderid column though…do you have a list of these “special” columns? (I call them special as, such as selecting the jcr:path column, while you don’t see it if you do a “select * from…”, you can still actually see the values of it specifying it directly like “select jcr:path from…”)
Yes, the jcr:path and rx:sys_folderid are “artificial” columns. They really are not present in the properties, but the Query engine knows how to produce them.
Yes, that is how i expected it to behave as well. However, this is not the case with items that have been forced to archive (ie. have no expiry date…if you are limiting by expiry date). I believe that you should be able to recreate this on a generic RX system (just force an item to archive and see if the jsr query returns that item…which in my case it does). I do note that it only returns those items that are in the public or archive state (and not draft or review).
I checked to make sure that the filter on the archive state was set to archive and it was. If the query only returned items that are in the public state, then I would not need to do this/would not have a question :D…
I vaguely recall something about it being best to only have one public (i.e. publishable=publish) state in any one workflow. But there are publishable=ignore (i.e. quick edit) states. You might want to de-prioritise items currently being modified, by listing them after items that are public, by sorting on the state.
I think we’re best off figuring out why the item filter is not working for you.
Can you tell me what the “Valid” flag in the Archive state is? If it is “n” or “u” the filter should remove these items.
There’s nothing wrong with having more than 1 “public” state, except that you have to be clear about what the “Quick Edit” path is. Most people don’t need more than one, of course.
I somehow doubt that the filter is the problem as if the item is on archive, it will be unpublished from the site. The issue arises on the auto indexer which still returns the item even after it has been unpublished. I have verified on the item filter that the flag is “u”. Our workflow is pretty straight forward with only one public state.
I have tried multiple jsr queries (without the expiry date of course), but they all include the public and archived items (and not in any other state). Are you saying that the auto indexer does not return items in the archive state by default (it would make sense if it did not…which is what i assumed would/should be how it works)?
Let’s be careful, as there are several components here.
If you just go to the JCR Query test page and execute a query, you will see ALL of the content that satisfies the query, including items in Draft, Public and Archive. This is the raw query with no item filter applied.
Similarly, if you preview the page that contains an autoindex (which uses the same query), the “preview” item filter is applied. By default (you can change the item filters in the workbench, but I don’t recommend it), the preview item filter shows all content and sets the revision to the “current revision”.
When you publish the same page, the item filter that you selected when you created the content list will be applied. Usually, this is the “public” item filter. By Default, this filter limits content to the public and quick edit content. Additionally, items in the quick edit (and similar states) are shown in the last public revision, not the current revision.
This item filter is applied to the contents of ALL slots, as well as to the content list itself.
If this is not consistent with what you are seeing, we’ll have to dig into to the specifics of your configuration (Tech Support should be able to help with this part).
If you are just looking at the query in the JCR Query test page, or previewing the item, it’s normal that you will see expired content, but this should not happen when you publish.
Dave,
Thanks for that information, that was the bit that I was missing / had forgotten. Now that I knew that my testing was flawed, I went back and tested the preview url and changed the item filter to public (from preview) instead of changing the sys_context to 301.
That worked and publishing also worked as advertised (ie. only the public items were shown). My problem stemmed from the fact that previewing the page showed (and still shows) items that are in the archive state, I didn’t think to change the item filter, and the JSR queries weren’t applying the item filters. It is difficult to tell the end users that previewing the page in the cms is supposed to be what is published, but not really…(as we want them to use the preview within the cms to test their pages as opposed to hitting publish now (for those that have it) and looking at the page, making a change and publishing again…).