I created two report suites today, and in so doing, I noticed a behavior that I suspect is wrong and unintentional.
The first report suite was the development report suite, for which I entered in the "Report Suite Id" field "[reportsuitedev]". I configured it, and hit submit.
The page reloaded with the information I'd entered. I needed to create a duplicate, so I went ahead and removed the "dev" from the report suite ID and name, changed the base URL, and hit submit again -
and realized too late that instead of loading "[reportsuitedev]" into the field after I created the first report suite, the admin console appended the standard prefix and loaded "[compnyreportsuitedev]." Therefore, the production report suite's ID is [compnycompnyreportsuitedev].
Given that report suite IDs are permanent and cannot be changed, and report suites cannot be deleted and recreated, I think this is the worst possible behavior for this text box. I have done this in the past (thankfully in the opposite order, so only the dev suite got a bad ID), without realizing that the Admin Console facilitated my mistake.
I would accept any of the following solutions:
- prompt the user if it appears there is a duplicate prefix. This could be done in javascript in fifteen minutes.
- do not load the prefix into the "reportsuiteid" field after a suite is created.
- require the user to enter the prefix
- automatically remove duplicate prefixes
- show the results in read-only form fields so the user cannot submit incorrect data
- allow users to change report suite IDs, at least for new suites with no data
- allow users to delete and recreate report suites, at least for new suites with no data
Obviously, it doesn't matter that much - we put the report suite ID into a configuration file and leave well enough alone. But with a wrong-looking report suite id like this, there's always a possibility that some well-meaning person will "correct" it in the future, and cause data to be lost before the mistake is realized. (We have safeguards in place for that, too, but no safeguard is completely safe.)
My instructor in SiteCatalyst implementation training warned us about prefixes two years ago; with so many preferable and seemingly easy alternatives, I'm surprised it hasn't been fixed already. It's always preferable to help people avoid mistakes than to heedlessly allow them to make mistakes, but the behavior I'm reporting actively encourages and assists people in doing the wrong thing. I hope you can fix this in a release soon.
Thanks!
