iNotes Customization: Editing and saving a sent mail stores it as a Draft (Update 2015-03-12)

HCL Domino Domino Forum
1

I added another update as a response to this on 2015-03-12; it woud be very helpful if someone a) could confirm this and b) could also confirm that this must be a bug;

as - for whatever reason - screenshots don’t show up inside a response I add them here:

screenshot #1: ; screenshot #2: ; screenshot #3:

=====

Steps to reproduce:

  • open a sent mail from the Sent view
  • edit the mail using the “edit” button and apply some changes
  • open the “Save” drop-down button and click on “Save” (first child element from the sub-menu; second one is labelled “Save as draft”)
    Result:

changes are saved, but the mail has moved from “Sent” to “Draft”.

Looking at the edited mail doc using the Notes client I see that the “PostedDate” field is been removed, which is a main criteria for the doc now being shown in the Drafts view.

Weird thing is that I tried exactly the same a few weeks ago, but then it worked as expected:

  • Save >> Save would store the changes and leave PostedDate intact
  • Save >> Save as Draft would store the changes AND remove PostedDate
    I don’t know, what has changed; we installed IF1 for 9.0.1 FP2 recently but I can’t recall if that happened before or after my last tests regarding “Save” behaviour.

Main questions are:

  • is this possible a bug that got introduced recently?
  • anyone having an idea how to implement a workaround? Is it worth trying to restore PostedDate through a QuerySave agent? I’m afraid though that the field is removed AFTER the agent has done its job…
    Unfortunately this is critical for an iNotes customization project which is nearly completed.

Update 2014-11-24:

did some further testing:

  • if I open my own mailfile using iNotes >> Sent view, then edit and save a sent mail, everything is as described above
  • if I open another person’s mail using iNotes (being the owner’s delegate) >> Sent view, then edit: Now instead of the SAVE dropdown button i se a simple button labelled “SAVE AND CLOSE”, and This button doesn’t move the mail from SENT to DRAFT!
    So tried to add a custom button that behaves like the above mentioned SAVE AND SEND one, using the following code:

var btnSaveClose = [{
find_id: “save”,
before: true,
id: “customsaveandclose”,
title: “Speichern und Schliessen”,
action: “EbK{sAction: ‘a-saveandclose’}”,
help_text: “Speichern und Schliessen”
}];

addActionsLite(s_MenuID, true, btnSaveClose)

Now this indeed adds a different button, and using Firebug I see that the resulting element’s onclick event seems to be bound to the right action; indeed the memo is saved AND closed instead of remaining open.

BUT: the memo is still moved from SENT to DRAFT.

I would be very happy if someone could confirm that this is not the expectd behaviour; I mean, if in the standard situation I have the choice between SAVE and SAVE AS DRAFT we can expect some difference in behaviour, don’t we?

All the best,

Lothar

2

Subject: update on my original post: some more details

REMARK: had to move the screenshots to the original post; for some reason they don’t show up inside the response…

=====

this is becoming a huge problem in a customer’s project. Si did some more research on it and at least was able to find some weird workaround:

Usually when editing a sent mail it offers a cascaded set of “Save” buttons usually sitting between “Send & File” and “Delivery Options” (see first screenshot)

By chance I found that some sent mails in my test user’s mailfile showing a different button when opened in edit mode with aq “Save and Close” action at first position (2nd screen shot):

Other than with the cascaded Save button the “Save and Close” action does NOT remove the PostedDate field thus pushing the saved mail out of SENT into DRAFT!

Doing further research I found that difference is in an internal FROM field: if the sent memo’s FROM field contains a name differnet from the mailfile owner then it offers the “Send and Close” button, otherwise it’s the cascaded “Save” button set. And it gets even weirder:
Just by altereing the case of the FROM field’s content Domino thinks that the memo was sent by someone else and in consequence then shows the other button which DOES NOT remove the PostedDate field.

Steps to reproduce:

  • send a mail so that copy is stored in the SENT view

  • make sure that the sent memo’s FROM field contains the sending user’s NotesName (e.g. CN=SOP Autor3/O=edcom)

  • edit this memo using iNotes ==>

  • you should now see the cascaded Save button set;

  • using this button’s “Save” option saves the memo but doesn’t close it.

  • the memo is moved from SENT to DRAFTS

  • using some kind of scripting agent or other tool change the contents of the FROM field to an all-capital letter version (e.g. CN=SOP AUTOR3/O=EDCOM) ==>

  • at least using a Notes client this memo’s header part now shows an extra line “Sent by: SOP AUTOR3” below the standard “From: … SendTo” info block (3rd screen shot):

  • edit the memo again through iNotes ==>

  • you should now see the “Save and Close” button while the cascading button set is gone

  • clicking this button changes are saved, the memo tab is closed

  • the memo still is inside the SENT view
    ==============

Setup is as follows:

Domino 9.0.1 FP3 running on Windows Server 2008 R2 x64

reproducible on various similar Domino setups

Would be helpful if someone could at least confirm this behaviour