Please submit your ideas on how to improve Cascade Server.
-
Asset Recycling Bin
It would be great to have a more robust asset recycling bin to prevent users from accidentally deleting items that can’t be recovered by administrators.
-
Unpublish asset when renamed or moved to another folder upon expiration
This idea is a continuation of the feature request located here: http://support.hannonhill.com/browse/CSNEW-77
Sometimes the asset’s end date will trigger a move to another folder
for “expired” content. The asset should probably be unpublished before
it is moved.
The same can be said for assets that are renamed. Currently, when
an asset is renamed, the old asset remains on the server and does not
get unpublished.
-
Export from one instance of Cascade/ Import to another
Our developers work in our test instance of Cascade which publishes to our test web servers. We would like an easy way to export assets from one Cascade instance (test) so that we would import them into another Cascade instance (prod). We need 2 Cascade instances in order to OS and software upgrades etc -
Ajaxify Publisher Status
Instead of refreshing the entire page, use ajax to update publisher status. In addition, possibly include a publisher status for each user at the top right to allow them to keep working while still knowing the status of their last publish.
-
Login as user
I would like the abilty as an administrator to login as a user so that I can check their access -
Destinations not all checked by default
Do not check all publishing destinations by default. Perhaps when setting up a destination, have an option to say “Check by default”. This way, if users have the option to publish to a staging server before publishing to their live site, they don’t accidently publish to the live site.
-
getting around slow publishing jobs
It would be nice if we could pause a big publish job to let other smaller jobs through, and then resume it later.
Alternatively, we’d like to be able to set a “width” on the publish queue, or have multiple queues, so more than one job could publish at a time. -
Add "date" version of "datetime" field, add both to Dynamic Metadata
I love using the “datetime” type on Data Definitions, but I find myself using it a lot when I just want the date part of it, and not the time part. Add a “date” type that just has the date function.
Also, give the ability to add “datetime” and “date” to Dynamic Metadata so we can have a differently-named date/datetime field in the dynamic metadata (without having to use “Start Date”, “End Date”, or “Review Date”).
-
Copy/move assets from one site to another
Now that Cascade supports sites, it would be very helpful if there was the ability to copy or move assets from one site to another.
-
Data Definitions in Blocks
I would like to attach data definitions to blocks. The metadata sets are usually limited with fields such as no WYSIWYG editor and no date chooser.
-
Ability to Supply Different TinyMCE Configurations
This is a continuation of the feature request located here.
Would like the ability to have control over:
* buttons
* content validation (allowed/disallowed content)
* plugins
Buttons
Allow control over which buttons can be used in the WYSIWYG editor.
Content Validation
TinyMCE has a right language for disallowing/allowing certain types of contents that could be used, for example, to enforce XHTML strict content in the WYSIWYG if the user so desired or even a smaller subset of a just a few tags/attributes.
Plugins
Allow arbitrary plugins to be included.
This one is a really tough call, because there are tons and tons of plugins out there. The support implications are the main concern.
Solutions
The easiest mechanism for doing this would be to allow CMS administrators to supply their own JSON object containing the configuration of TinyMCE that is passed when TinyMCE is initialized. However, Hannon Hill would need to figure out its support policy with respect to various configurations as there is a high risk of crippling the WYSIWYG or causing significant behavior changes -
Don't Allow Publish Dupes
Although I continue to tell my Web editors not to keep clicking publish and to view the queue, some of them repeatedly publish the same assets because they don’t see the change on their website. I suggest showing the user an error message that says something like: This asset was just published by you and is still in the publish queue.
I’m not sure if it should allow them to publish it again or make them wait. Or maybe they’ll need to cancel the previous publish job.
All I know is that I hate seeing a dozen publish jobs for the same folder, slowing down publishing for everyone. -
Height and width attributes of image type files in index blocks and data definitions
It would be nice to have the CMS display the height and width of file
assets with particular extensions within system index blocks. This
would allow users to easily size their images in XSL stylesheets. -
Sites
A Site is a formal collection assets that includes:
- own set of Page Configuration Sets, Content Types, Metadata Sets, Asset Factories, Data Definitions, Publish Sets, Workflow Definitions- NO targets, but a collection of destinations to which assets publish- users/groups members of the SiteSites will allow for:- Roles that are local to that siteTarget properties that will be moved:- Serialization Type (to the Page Configuration)- Output Extension (to the Page Configuration)- CSS Classes/File (to the Site) -
System option for removing empty folders on unpublish request
Currently, unpublish will remove assets from various destinations.
However, if it removes the last file in a particular folder, it will
not try to remove the folder. Either a system option or an accompanying
option on the publish screen to remove empty folders on unpublish,
would be in order. -
A method to send administrative messages to active users
It would be nice if you could somehow send a message (a noticable
message, not to the users’ inboxes) to the active users so that they
can be notified that, for example, the system is going down for
maintenance at a specified time. This would smooth out the process of
doing all of these upgrades by helping to eliminate the need for admins
to contact each user individually, or just kick them out of the system
and risk lost work. -
Administrators should be able to review all publish reports
It would be nice if Administrators are able to view all the publish messages that are sent out in a central location. The current alternative is to parse logs, though this does not indicate who initiated the publish.
This issue originated as an idea in our JIRA.
-
Allow publishing of non-xml pages
Cascade users would like the ability to publish non-xml pages. -
Insert Form Elements through WYSIWYG Editor
We have users who need to create their own online web based forms. I would like to see the editing tool be given the ability to insert form elements (accessibly, of course).
-
Restore Data by Site
It would be great to be able to restore data on a site-by-site basis.
For installations in which there are several sites in one installation,
if one site’s data is somehow corrupted, or they have data that needs
to be restored, you have to restore the entire database, which rolls all
sites back to the condition in the restored data. Restoring site-by-site would be ideal.
* Note - To input code samples, click the pencil icon (this will remove the WYSIWYG) then be sure to start and end code sections with @@@ (three '@' signs). For more information on textile markup, click here.
