Using caster it's very easy to send large emails of the entire report to everybody on the distribution list rather than the small portion of the burst data if you do not tick the 'burst' box.

This is a catastrophic event that can damage a products reputation within the company, but it is very easy to make the mistake.

So, if you are working with Caster and large burst, distribution lists, PLEASE TAKE A MENTAL CHECK TO TICK THE BURST BOX. REPORTCASTER WILL NOT ISSUE A WARNING THAT A DANGEROUS CONDITION MAY HAVE BEEN ENABLED.

IBI Reportcaster team: you might think about looking on the forum and getting some feedback and think about putting some vital usability into your product without it having to be painfully pointed out through NFR's.

A product that had been thought through or where the developers listened to feedback would have some kind of warning message built into it by now to avoid against this.

Although I support your request for such a warning, I also think that the individual who forgot to check the box has got some responsibility also. You just can't blame a product for anything that may go wrong, you sometimes have to take your responsibilities.
This warning you're requesting should only be issued if the distribution list selected has no or just 1 distinct burst value. After all, you can't burst if there are no burst values, can you?

GamP

I agree that it is not entirely the responsibility of the product, but I have to ask you - if you yourself write code that has the ability for a user to delete thousands of records, would you issue a warning first?

Consistently reportcaster does not behave in a logical manner (can provide the list if you like) and this is just one of a series of problems with that never seems to get fixed.

btw Here's what to do if you submit a caster job by mistake.

1. Log onto the wf client and goto services and kill 1st SMTP service and then kill caster.

2. If its a long running report then you can go to the server and do that but it is not crucial.

At the root of the problem is that the bursting flag does not appear on the distribution page of the caster menu.

A burst distribution list is different from a standard distribution list in that it is pairs of values (email, burstval) rather than a single value (email). Thus reportcaster should be quite capable of detecting the difference and warning of possible disaster.

In addition, I have scheduled report caster jobs for a distribution list where I DID NOT want it to be burst. ReportCaster has no way of knowing what the user wants in this case, nor can it detect what the job is going to do that is scheduled or whether is is large or small.

In your example of providing a notice when a job will delete records, you would know that you are running a job that is going to delete records and build in a safety mechanism. When you schedule an RC job, all RC knows how to do is run the job and distribute it as instructed - not what the job is going to do and that the user has given the wrong intructions for distribution.

Your suggestion of moving the bursting check box to the distribution page is an EXCELLENT idea. It seems more of a distribution function than a report property/function. That has annoyed me on many an occasion.

There really isn't any distinction between a bursting list and a standard list. It all depends what the purpose of the list is. Any you may want to sometimes use a "bursting" list for "standard" purposes. We actually do that in a few cases.

WF is a great product, but it really has not much in the way of artificial intelligence. It requires all the intelligence to be provided by the user, which has left me in a lurch sometimes

Whilst the location of the bursting checkbox is questionable in certain circumstances, it is the correct location for situations where you have many castered jobs, some of which you want burst and others that you do not want burst.

As is the case with a tool that has to cover all possible eventualities, there have to be compromises and the product is only as good as the design, initial or amended. If problems and errors are encountered during its use then they need to be raised with the product team.

Yes, I agree that there are some things that I do not like with RC and some of the layout is not necessarily intuitive, but if I find a problem or would like to see a change in use or functionality then I would raise a case direct with IB via Info Response.

And, yes, I think the raising of these perceived problems on the forum is a good idea. To discuss these things has to be good for the product and it also gives the opportunity to review these perceived problems from various different angles.

Remember, the product is used by many different companies in various different manners. Not all are compatible and so a compromise is required. A compromise that will not necessarily suit all campaigners.

T

Another useful idea is to liaise with your email team to have a proc that's ready to recall email in the event of an accidental 'cast for the distribution userid within a particular timeframe.

I assume this would be entirely possible for internally controlled mail servers but am not an expert in email.

Anyone out there with an recall distribution mail sent in error policy?

I think Tony A hit the nail on the head. We use caster for live reports here. In fact, the same report request is burst (bugs/nf requests burst by dept mgr) and not burst (bugs/NF of higher priorities for all groups to me and a set of other generalists).

How do we know that bursting must be enforced for a fex?

To me the compromise is a simple one- i think the potential for trouble is too great with no warning but having read other comments think a warning error message would obstruct a proportion of RC users.

I propose the prompt or field description text is changed to include:

"Warning. Distribution will go to entire list if Burst box is unchecked."

or something.

That way it will alert you to the potential danger but won't effect those users who are fully aware of the fact as it will be embedded as text into the existing process.

so yes i think a warning is neccesary but it shouldn't interupt the flow of working for others.

what do you guys think? a compromise to please all? (or the majority)

A compromise, and a good suggestion at that, imho.

I know of sites that have global circulation lists based on log in Ids, some more than 3000 items. Using this as the circulation list for a report that should be burst is dangerous if you inadvertently forget to check the burst box (and we all have the propensity to do that ). In this scenario a warning would be timely, especially in bold red font!

Other sites, and these would probably be the majority, use specific lists designed for specific jobs and the danger of not checking the circulation list is proportional to the length of the list. In this scenario a modal message requiring acknowledgment by a click may be perceived as an annoyance (a bit like Windows Vista!). However, included text in the dialog for the task, although bold and brash, could be accepted without question?

In all a good suggestion that I feel would encompass most situations?

A good example of how useful a discussion can be on the Point.

T

i think its a solution thats no-destructive to any existing ways of working so am glad you agree.

Bold, red fonts are a good idea and it means IB are covering themselves also.

Actually i can't see any negatives to such a compromise but would like to hear what others think and what any objections would be.

Issuing a warning if a Distribution List containing burst values is used with a task that has the burst flag unchecked is a good idea. This will be added in a service pack release.

Excellent, this is good news!

cheers

Nubi

Not only good news but a time for congratulations to Gerry and his team in recognising a reasoned enhancement!

T

Occassionally, you DO get what you ask for

Gerry

Thanks for taking our comments on board.

Look forward to seeing this in action soon.

John