We should take a close look at the code written for RHCMS and decide what, if anything, should be merged. From Scott Seago: Modifications which may be appropriate for core/cms 1) Created com.arsdigita.bebop.form.Button class: Generates an html input type=button (as opposed to type=submit). Not clear if this component is really necessary, though. Button is only useful w/ javascript, and with javascript, the onClick function can return 'false' which has the same effect as creating a button. 2) com.arsdigita.bebop.Paginator: access method for the Page Num selection model with getPageNumSelectionModel() 3) Javascript-based date widget (com.arsdigita.bebop.form.JSDate). This would be a useful alternative to the basic bebop date class, but a non-javascript fallback would need to be developed. 4) Misc. bebop components BodyAttributes, DynamicallyPrintable, JavaScript: possibly reusable for other purposes 5) Folder index item UI: already integrated 6) For /content/admin/item.jsp, redirect to login if the user is not logged in rather than throwing AccessDenied. This would be useful for cms checkin unless this code on the trunk has already been refactored to the point of this functionality no longer being necessary. 7) SortableDomainObjectPropertySheet: alternative to the exising DomainObjectPropertySheet component that allows sort keys to be added when adding components -- this allows subclasses to add items to arbitrary locations rather than just at the end. 8) added workflow task sort key to prevent item workflow steps from appearing out of order. I'm not sure if this is still a problem on the trunk or not. 9) Fixed a bug with renaming folders to make sure both live and draft folders were renamed at the same time. Not sure if this is still a problem on the trunk. 10) Modified publishing code to allow scheduled republishing. This was a fairly major modification which was never pulled back onto the trunk, as there were several requirements disagreements as to how this should really be done. This code will not be used in subsequent CMS releases -- however the RHCMS use cases have been considered in the ongoing CMS publishing/versioning redesign discussions. 11) Various MetaForm modifications/enhancements to deal with specific RHCMS authoring kit use cases. I'm not sure if this sort of thing would be appropriate as-is for checkin on the trunk 12) Picklist object types, classes, and UI: Developed a general framework for handling simple picklists of strings. This might be generally useful for other projects. 13) Link class for managing links from content items to either other content items or external sites. Has already been refactored along with DP link functionality into the content-types package for a new Link content type. 14) UI for item-item association searching. Has already been refactored and integrated into the trunk. 15) Enhanced UI for handling folder permissions so that customizing doesn't lose the initial defaults. this has already been integrated. 16) Modified /permissions UI to allow granting of site-wide admin permissions. Some variant of this would be appropriate to check in, but the RHCMS implementation was done more as a one-off and would need a better redesign for checking into the trunk. 17) Workflow notifications and folder-based workflow watches implemented. I think some variant of this functionality has already been added to cms. 18) "Publish all" functionality which publishes all items within a folder or subfolders without regard to workflow. This is probably not a desirable feature to add by default, although there has been at least one request for this feature apart from redhat.com
Closing old tickets