107671 - Custom Hdr: Need handling for filter based on deleted custom hdr

Status: RESOLVED EXPIRED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[laurel]

Using oct30 commercial trunk build

We need handling for deletion of custom headers which are involved in existing
filters.  I need to do more detailed test, but so far I've seen a couple things
which are bothersome.  Since the custom header ui is accessible on a
profile-wide basis from both filter and search ui, it might be fairly easy to
womp a custom header involved with a filter.

From what I've seen so far, 4.x warns the user when they edit a filter based on
a custom header which no longer exists.  The alert informs them of the missing
header and offers the option for the user to add it back... alert dialog
screenshot will be attached.

In the current build, here's what I've seen so far in a couple scenarios (like I
said, I haven't gotten to a lot of scenarios yet):


Scene #1:
1.  I delete a custom header from search ui which a filter is based on, confirm
the deletion.
2.  I then go to the filter ui and check/edit the filter I see the filter has
been reset to Subject criteria and the operator/2nd criteria dropdown is blank
and unusable until I reselect the first criteria dropdown.  No warning, no
obvious handling.
3.  If I exit then come back and check/edit that filter, a custom header dialog
is launched (with no explanation). If I cancel that dialog the filter rules
dialog appears.  (Again, I haven't tested all possibilities like adding in
another instance of the missing header, etc.)

Scene #2:
1. I delete a custom header from search ui which a filter is based on, then add
another, confirm the changes.
2. I then go to the filter ui and check/edit the filter I see the filter has
been reset to use the newly added custom header as the criteria.  No warning, no
obvious handling.

Will report other scenarios' results as found...

Maybe a filter check similar to that done when we rename or delete a filter
destination folder could be done with custom headers?  Maybe not a current
priority, but eventually.

Comment 1

[laurel]

Attachment: 4.x alert when edit filter

Comment 2

[Navin Gupta]

I know about this one. Even though the ui is messed up because the headers are not
in pref, but filters will still work.

Comment 3

[Navin Gupta]

ya, I could easily add an alert, if others are happy w/ it.

Comment 4

[(not reading, please use [e-mail] instead)]

mass re-assign.

Comment 5

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 6

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 7

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 8

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 9

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420