Open
Bug 12185
Opened 25 years ago
Updated 2 years ago
MAPIFindNext implementation ignores input flags
Categories
(MailNews Core :: Simple MAPI, enhancement)
Tracking
(Not tracked)
NEW
People
(Reporter: phil, Unassigned)
References
Details
(Keywords: helpwanted)
MAPI.H gives a number of flags which can be passed in to MAPIFindNext: #define MAPI_UNREAD_ONLY 0x00000020 /* Only unread messages */ #define MAPI_GUARANTEE_FIFO 0x00000100 /* use date order */ #define MAPI_LONG_MSGID 0x00004000 /* allow 512 char returned ID */ In 4.x, we ignore these flags, which is a bug. At the moment, we don't have a plan to do MAPI in 5.0, but I'll enter this bug for us to come back to later.
Reporter | ||
Updated•25 years ago
|
Depends on: 11057
Summary: MAPIFindNext implementation ignores input flags → [HELP WANTED] MAPIFindNext implementation ignores input flags
Whiteboard: HELP WANTED
Reporter | ||
Updated•25 years ago
|
Severity: normal → enhancement
Target Milestone: M15
Reporter | ||
Comment 1•25 years ago
|
||
Bulk-resolving requests for enhancement as "later" to get them off the Seamonkey bug tracking radar. Even though these bugs are not "open" in bugzilla, we welcome fixes and improvements in these areas at any time. Mail/news RFEs continue to be tracked on http://www.mozilla.org/mailnews/jobs.html
Updated•25 years ago
|
Status: RESOLVED → REOPENED
Comment 2•25 years ago
|
||
Going to try and reopen in an attempt to assign to myself
Updated•25 years ago
|
Assignee: phil → cwhite7
Status: REOPENED → NEW
Reporter | ||
Comment 4•25 years ago
|
||
Reopen mail/news HELP WANTED bugs and reassign to nobody@mozilla.org
Updated•25 years ago
|
Assignee: nobody → cwhite7
Updated•25 years ago
|
Status: NEW → ASSIGNED
Updated•25 years ago
|
Keywords: helpwanted
Reporter | ||
Updated•25 years ago
|
Summary: [HELP WANTED] MAPIFindNext implementation ignores input flags → MAPIFindNext implementation ignores input flags
Whiteboard: HELP WANTED
Target Milestone: M15
Comment 5•25 years ago
|
||
Not much progress has been made, going to re-assign to nobody so that I am not sitting on these issues. Will probably pick up again in a month or two if they are still open issues when I have time and I can actually make some progress first.
Assignee: cwhite7 → nobody
Status: ASSIGNED → NEW
Comment 7•23 years ago
|
||
MAPIFindNext will be implemented sometime after the end of September this year. Not a concern right now. Will revisit around the end of September.
Updated•20 years ago
|
Product: Browser → Seamonkey
Updated•16 years ago
|
Assignee: rdayal → mail
Priority: P3 → --
QA Contact: nobody → search
Comment 9•15 years ago
|
||
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
Status: NEW → UNCONFIRMED
Comment 10•15 years ago
|
||
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 11•15 years ago
|
||
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 12•15 years ago
|
||
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 13•15 years ago
|
||
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 14•15 years ago
|
||
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
Updated•15 years ago
|
Assignee: mail → nobody
QA Contact: search → message-display
Comment 15•14 years ago
|
||
Believe this is still an isssue in 3.04. In fact I can't get MAPIFindNext to return anything other than error code 16 (No more messages) regardless of the input params.
Updated•14 years ago
|
Component: MailNews: Message Display → Import
Product: SeaMonkey → MailNews Core
QA Contact: message-display → import
Comment 16•14 years ago
|
||
Neil, any status recommendation?
Comment 17•14 years ago
|
||
Sorry, I've never used MAPI; bienvenu might know?
Component: Import → Simple MAPI
QA Contact: import → simple-mapi
Comment 18•14 years ago
|
||
looking at MsgMapiListContext::GetNext, we do ignore the flags. I don't know if anyone cares. But the code looks like it basically works, though it ignores imap messages w/ no body in the offline store.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•