If you upgraded your dnn install from a pre DotNetNuke 3.3.0/4.3.0 site, you will have noticed that the expiry date was removed from the announcement module, which might have lead to old announcements to be displayed again.
The ExpireDate column was removed in version 3.3.0 of the announcements module, which, quite frankly, should not have been done. At the same time, a new History (Days) setting was introduced in the module, offering a similar, but less granular control over display duration of announcements. Let me give you some insight of the reasoning behind all this, quoting Shaun Walker:
- You could set an expiry date and once the item expired, it would no longer be displayed in the list. This concept, although granular, imposed a lot of extra administration in managing lists of announcements. And the biggest issue was that once the item was expired, not even an Administrator could view the item to change the expiry date or delete - it was effectively orphaned within the database and could only be accessed via manual SQL queries.
- The new concept allows you to construct views where you can see subsets of announcements or all - simply by adding a module reference to another page and modifying the view settings. However this is still not very granular when you wish to expire a specific item. I would suggest an IsActive flag on items. However, the trick is that when an Admin is logged in, they need to be able see ALL items whether they are active or not - whereas regular users see just the active items. Personally, I believe that all modules should support a notion of IsActive - as hard deletes are far too permanent and destructive.
- You may also think that adding some criteria to the Announcements.ascx to allow the user to choose view settings would be good as well. And it would certainly provide flexibility. But it would do so at the expense of performance, as the module would no longer be able to participate in the module caching framework (which is a huge deal in an active site like dotnetnuke.com )
The reasoning is sound, however, i think we need to offer a smoother upgrade path for existing modules.
I just finished a new version of the module which will undo the deletion of the ExpireDate field (which means it won't be deleted anymore from upgraded modules, and will be added to 3.3.0+ modules. This wil not help the upgrades that already went haywire, but will solve the problem for when the big masses will embark on the upgrade adventure.....
The new version is being tested now, and should be released fairly soon (early next week)