nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Content Expiration

Nicholas

I would like to know, why some standard features not introduced for content expiration in TeamSite as this is a very common requirement.

-- Nicholas

Find more posts tagged with

Comments

gzevin

I would like to know, why some standard features not introduced for content expiration in TeamSite as this is a very common requirement.

-- Nicholas

I would also like to know why the snow is white.

Nicholas

I would also like to know why the snow is white.

This is fine, TeamSite provides the ability to customize it but my question is why not something default?

gzevin

This is fine, TeamSite provides the ability to customize it but my question is why not something default?

what would you wanted to see as default? give me an example...

Nicholas

You might be looking this as just a small thing in perspective to set a expiration date along with the default title, author, description in metadata DCT. But if you thing this to relate with the the Search, you might find this useful. Let me explain here, how this could be helpful: Giving something default feature in TeamSite for Content Expiration could give advantage to the search index to drop the content if it is out of date (content whose expiration date is in the past, will not displayed in the search results). Think something related to "Expiration date based search". If TeamSite has this ability then other side of coin (Search) could be extended/provide more features those could be very helpful.

Hope it make sence.

Thanks Nicholas

gzevin

You might be looking this as just a small thing in perspective to set a expiration date along with the default title, author, description in metadata DCT

believe me, I understand what you are talking about. However, my point is that there are zillions of things that should/could have been productised, and they are still not. E.g. - calendar controls in both WFT and DCTs, any vpath-capable directory/file browsers, etc, etc.

At least having an extra EA as 'expiration date' and some little customisation will do many tricks. And, IMo, this makes sense, as, depending on the requirements, there could be different uses for that attribute. BTW, I would never drop expired content from search, but again, this depends on type of search you would want.

Nicholas

believe me, I understand what you are talking about. However, my point is that there are zillions of things that should/could have been productised, and they are still not. E.g. - calendar controls in both WFT and DCTs, any vpath-capable directory/file browsers, etc, etc.

At least having an extra EA as 'expiration date' and some little customisation will do many tricks. And, IMo, this makes sense, as, depending on the requirements, there could be different uses for that attribute. BTW, I would never drop expired content from search, but again, this depends on type of search you would want.

Which is fast, searching a records from 10K or 100K?. Giving a option to user to make his/her search on the basis of Expired OR Live OR All, I think, you must be agree that if a user looking for a record which in live and making search on for example last one year record will give results fast or searching in last 5 years record. And just think, if content size is 500GB/more then how this feature could effect to save time and money.

HomeFolder.PNG

gzevin

Which is fast, searching a records from 10K or 100K?. Giving a option to user to make his/her search on the basis of Expired OR Live OR All, I think, you must be agree that if a user looking for a record which in live and making search on for example last one year record will give results fast or searching in last 5 years record. And just think, if content size is 500GB/more then how this feature could effect to save time and money.

I do not want to start discussing the pros and cons of that partucular attribute. As I said, there could be many uses, one of them is search, another one (that is more useful, in my opinion) - nightly scans with reports, etc.

My point was that this is one the feature that you want to have productised. And my answer is that it's relatively easy to implement as a customisation. What's more, I would myself not want this particular feature productised.

Whereas there are heaps of other good features that beg to be implemented, much ahead of this one.

Nicholas

As I said, there could be many uses, one of them is search, another one (that is more useful, in my opinion) - nightly scans with reports, etc.

Thanks for adding one more reason to implement this feature. more good if you can eloborate "etc"

Well, you are right, it is personal view to support some feature and I will not mind if you do not like this one much. But as I have started this thread so my responsibility to eloborate and discuss as much as I can and you epecially asked to give an example.

Thanks for your view BTW.

-- Nicholas

gzevin

Thanks for adding one more reason to implement this feature. more good if you can eloborate "etc"

Well, you are right, it is personal view to support some feature and I will not mind if you do not like this one much. But as I have started this thread so my responsibility to eloborate and discuss as much as I can and you epecially asked to give an example.

Thanks for your view BTW.

-- Nicholas

etc means many other uses, as the requirements differ. One customer might ask for an email, another will make you launch a workflow. Or both. I am talking about existing real life scenarios, BTW.

sure, I am not stopping you from any discussions, I was just expressing my opinion, that this is one of the least desirable feature to be productised, on MY priority list.

Nicholas

Here I am summurizing discussed benefit of this feature:

1. Send email when some specific content expires, so user will be notified when content expires.
4. Launch a workflow, if some operations.
2. Nightly scans with reports.
3. Helpful to extend/improve search performance in many ways.

Someone have any other reason to add this?

Thanks Nicholas

Nicholas

Stellent provides this feature to manage expire content.

In, Vignette, expiration can be included in content life cycle, someone could confirm this?

nipper

It is very easy to expire content when you serve the content as well as manage it. TS does not do that. OOTB TS will allow you to set an EA for the expiration date. After that is it custom. My current project is a mostly flat HTML sight. Expiring content would be difficult since you need to keep reference counts or just do a parent page regen.

Every customers needs are different. TS allows you to easily customize it to address those needs. A common request I get is to implemenet a search and email the owner of page that it is "old" and should be removed or updated. That takes what ? 15 minutes to script ?

$SOAPBOX=OFF;

Andy

Adam Stoller

Here I am summurizing discussed benefit of this feature:

1. Send email when some specific content expires, so user will be notified when content expires.
4. Launch a workflow, if some operations.
2. Nightly scans with reports.
3. Helpful to extend/improve search performance in many ways.

Someone have any other reason to add this?

Thanks Nicholas

The ideal (IMO) would be to provide some basic OOTB functionality that can easily be customized to fit the needs of the particular customer.

That being said - I've seen launch dates and expiration dates used for a variety of reasons with a variety of different effects (some use it to move content into an 'archive' directory, some use it to move content into an 'archive' branch, some use it to remove content, and some use it to send out notifications for some user to take action to do one of the previous actions or some other action as desired).

The point being that there is no one-size-fits-all solution / usage for content expiration information so having Interwoven productize it has limited benefits (especially if doing so changes some other behavior - intentionally or otherwise).

From a consultant perspective - it's reasonable to build up a library of approaches to dealing with content expiration so that you can easily imlement one for your customers.

From a customer perspective - it's reasonable to find someone who either has such a library, or can easily design and implement a solution to match their needs.

I'd agree with Greg here - given the various things that would be nice to see fixed and/or added to the product - an OOTB implementation for content expiration would probably be pretty low on my list too - because it's far to easy for it be impede the development of a custom solution.

Instead - I'd suggest a means of expanding the search mechanism (if needed? I have not played with it at all) such that you can build up a complex query that could limit the search results to content which has not reached its expiration date. Note - for a reasonable database (i.e. not the OOTB stuff) - it shouldn't matter too much whether you're dealing with 10K or 100K / 1 year or 5 years. True, at some point there's likely to be some response degredation, but I imagine that would be a pretty large amount of data.

gzevin

It is very easy to expire content when you serve the content as well as manage it.

actually, LiveSite with a run-time component is the first candidate to get this feature implemented (unless it's already there, I am not into LiveSite...).

Nicholas

It is very easy to expire content when you serve the content as well as manage it. TS does not do that. OOTB TS will allow you to set an EA for the expiration date. After that is it custom. My current project is a mostly flat HTML sight. Expiring content would be difficult since you need to keep reference counts or just do a parent page regen.

Every customers needs are different. TS allows you to easily customize it to address those needs. A common request I get is to implemenet a search and email the owner of page that it is "old" and should be removed or updated. That takes what ? 15 minutes to script ?

$SOAPBOX=OFF;

Andy

Thanks for your response Andy. From a excellent coder perspective it could be 15 min to script but this will be in days if add, time that was taken while product evalution for a feature and if you find this is a OOTB then its implementation possibilities, OOTB designing etc.

Nicholas

The ideal (IMO) would be to provide some basic OOTB functionality that can easily be customized to fit the needs of the particular customer.

That being said - I've seen launch dates and expiration dates used for a variety of reasons with a variety of different effects (some use it to move content into an 'archive' directory, some use it to move content into an 'archive' branch, some use it to remove content, and some use it to send out notifications for some user to take action to do one of the previous actions or some other action as desired).

The point being that there is no one-size-fits-all solution / usage for content expiration information so having Interwoven productize it has limited benefits (especially if doing so changes some other behavior - intentionally or otherwise).

From a consultant perspective - it's reasonable to build up a library of approaches to dealing with content expiration so that you can easily imlement one for your customers.

From a customer perspective - it's reasonable to find someone who either has such a library, or can easily design and implement a solution to match their needs.

I'd agree with Greg here - given the various things that would be nice to see fixed and/or added to the product - an OOTB implementation for content expiration would probably be pretty low on my list too - because it's far to easy for it be impede the development of a custom solution.

Instead - I'd suggest a means of expanding the search mechanism (if needed? I have not played with it at all) such that you can build up a complex query that could limit the search results to content which has not reached its expiration date. Note - for a reasonable database (i.e. not the OOTB stuff) - it shouldn't matter too much whether you're dealing with 10K or 100K / 1 year or 5 years. True, at some point there's likely to be some response degredation, but I imagine that would be a pretty large amount of data.

This is good that TeamSite provides OOTB and it could be developed as per the requirement but my interest was to know why not something initially available as this feature is available in other popular tools.

thanks for your response.

-- Nicholas