Skip to main content
replaced http://sharepoint.stackexchange.com/ with https://sharepoint.stackexchange.com/
Source Link

This perfectly makes sense to me: as soon as you attach an email ER, your code is in charge of handling incoming emails for this doc lib, according to your own business rules.
So standard settings used by SharePoint when SharePoint does handle emails are not needed anymore in that case.
Your code will handle email management logic, with dedicated settings you are free to hard-code/store somewhere/etc.

[Note: glad to see you're reusing the code I had posted here httphttps://sharepoint.stackexchange.com/questions/164837/deploy-bind-event-receivers-to-lists-in-single-feature! :)]

EDIT - what's under the hood
I dug into the code of the page. The page that displays the incoming email settings for the doc lib is "EmailSettings.aspx". If you open it, you see that the bottom sections are visible only under certain conditions, for instance:

<%
if (ShowAttachmentFolders)
{
%>
    <wssuc:InputFormSection Title="<%$Resources:wss,emailsettings_attachments_title%>" runat="server">
        ...
    </wssuc:InputFormSection>
<%
}
%>

So, the section shows up only if ShowAttachmentFolders is true. Looking at the code for ShowAttachmentFolders in ILSpy (class Microsoft.SharePoint.ApplicationPages.EmailSettingsPage, you see:

protected bool ShowSaveAttachments
{
    get
    {
        return !this.HasExternalHandler && (...);
    }
}

And HasExternalHandler is:

protected bool HasExternalHandler
{
    get
    {
        bool result = false;
        foreach (SPEventReceiverDefinition sPEventReceiverDefinition in this.m_List.EventReceivers)
        {
            if (sPEventReceiverDefinition.Type == SPEventReceiverType.EmailReceived)
            {
                result = true;
            }
        }
        return result;
    }
}

So, basically, this confirms the behavior is made on purpose by Microsoft, and that as soon as you have one ER of type EmailReceived registered on the list, most of the configuration sections do not appear on the page.

This perfectly makes sense to me: as soon as you attach an email ER, your code is in charge of handling incoming emails for this doc lib, according to your own business rules.
So standard settings used by SharePoint when SharePoint does handle emails are not needed anymore in that case.
Your code will handle email management logic, with dedicated settings you are free to hard-code/store somewhere/etc.

[Note: glad to see you're reusing the code I had posted here http://sharepoint.stackexchange.com/questions/164837/deploy-bind-event-receivers-to-lists-in-single-feature! :)]

EDIT - what's under the hood
I dug into the code of the page. The page that displays the incoming email settings for the doc lib is "EmailSettings.aspx". If you open it, you see that the bottom sections are visible only under certain conditions, for instance:

<%
if (ShowAttachmentFolders)
{
%>
    <wssuc:InputFormSection Title="<%$Resources:wss,emailsettings_attachments_title%>" runat="server">
        ...
    </wssuc:InputFormSection>
<%
}
%>

So, the section shows up only if ShowAttachmentFolders is true. Looking at the code for ShowAttachmentFolders in ILSpy (class Microsoft.SharePoint.ApplicationPages.EmailSettingsPage, you see:

protected bool ShowSaveAttachments
{
    get
    {
        return !this.HasExternalHandler && (...);
    }
}

And HasExternalHandler is:

protected bool HasExternalHandler
{
    get
    {
        bool result = false;
        foreach (SPEventReceiverDefinition sPEventReceiverDefinition in this.m_List.EventReceivers)
        {
            if (sPEventReceiverDefinition.Type == SPEventReceiverType.EmailReceived)
            {
                result = true;
            }
        }
        return result;
    }
}

So, basically, this confirms the behavior is made on purpose by Microsoft, and that as soon as you have one ER of type EmailReceived registered on the list, most of the configuration sections do not appear on the page.

This perfectly makes sense to me: as soon as you attach an email ER, your code is in charge of handling incoming emails for this doc lib, according to your own business rules.
So standard settings used by SharePoint when SharePoint does handle emails are not needed anymore in that case.
Your code will handle email management logic, with dedicated settings you are free to hard-code/store somewhere/etc.

[Note: glad to see you're reusing the code I had posted here https://sharepoint.stackexchange.com/questions/164837/deploy-bind-event-receivers-to-lists-in-single-feature! :)]

EDIT - what's under the hood
I dug into the code of the page. The page that displays the incoming email settings for the doc lib is "EmailSettings.aspx". If you open it, you see that the bottom sections are visible only under certain conditions, for instance:

<%
if (ShowAttachmentFolders)
{
%>
    <wssuc:InputFormSection Title="<%$Resources:wss,emailsettings_attachments_title%>" runat="server">
        ...
    </wssuc:InputFormSection>
<%
}
%>

So, the section shows up only if ShowAttachmentFolders is true. Looking at the code for ShowAttachmentFolders in ILSpy (class Microsoft.SharePoint.ApplicationPages.EmailSettingsPage, you see:

protected bool ShowSaveAttachments
{
    get
    {
        return !this.HasExternalHandler && (...);
    }
}

And HasExternalHandler is:

protected bool HasExternalHandler
{
    get
    {
        bool result = false;
        foreach (SPEventReceiverDefinition sPEventReceiverDefinition in this.m_List.EventReceivers)
        {
            if (sPEventReceiverDefinition.Type == SPEventReceiverType.EmailReceived)
            {
                result = true;
            }
        }
        return result;
    }
}

So, basically, this confirms the behavior is made on purpose by Microsoft, and that as soon as you have one ER of type EmailReceived registered on the list, most of the configuration sections do not appear on the page.

added 1522 characters in body
Source Link
Evariste
  • 9.7k
  • 2
  • 21
  • 30

This perfectly makes sense to me: as soon as you attach an email ER, your code is in charge of handling incoming emails for this doc lib, according to your own business rules.
So standard settings used by SharePoint when SharePoint does handle emails are not needed anymore in that case.
Your code will handle email management logic, with dedicated settings you are free to hard-code/store somewhere/etc.

[Note: glad to see you're reusing the code I had posted here http://sharepoint.stackexchange.com/questions/164837/deploy-bind-event-receivers-to-lists-in-single-feature! :)]

EDIT - what's under the hood
I dug into the code of the page. The page that displays the incoming email settings for the doc lib is "EmailSettings.aspx". If you open it, you see that the bottom sections are visible only under certain conditions, for instance:

<%
if (ShowAttachmentFolders)
{
%>
    <wssuc:InputFormSection Title="<%$Resources:wss,emailsettings_attachments_title%>" runat="server">
        ...
    </wssuc:InputFormSection>
<%
}
%>

So, the section shows up only if ShowAttachmentFolders is true. Looking at the code for ShowAttachmentFolders in ILSpy (class Microsoft.SharePoint.ApplicationPages.EmailSettingsPage, you see:

protected bool ShowSaveAttachments
{
    get
    {
        return !this.HasExternalHandler && (...);
    }
}

And HasExternalHandler is:

protected bool HasExternalHandler
{
    get
    {
        bool result = false;
        foreach (SPEventReceiverDefinition sPEventReceiverDefinition in this.m_List.EventReceivers)
        {
            if (sPEventReceiverDefinition.Type == SPEventReceiverType.EmailReceived)
            {
                result = true;
            }
        }
        return result;
    }
}

So, basically, this confirms the behavior is made on purpose by Microsoft, and that as soon as you have one ER of type EmailReceived registered on the list, most of the configuration sections do not appear on the page.

This perfectly makes sense to me: as soon as you attach an email ER, your code is in charge of handling incoming emails for this doc lib, according to your own business rules.
So standard settings used by SharePoint when SharePoint does handle emails are not needed anymore in that case.
Your code will handle email management logic, with dedicated settings you are free to hard-code/store somewhere/etc.

[Note: glad to see you're reusing the code I had posted here http://sharepoint.stackexchange.com/questions/164837/deploy-bind-event-receivers-to-lists-in-single-feature! :)]

This perfectly makes sense to me: as soon as you attach an email ER, your code is in charge of handling incoming emails for this doc lib, according to your own business rules.
So standard settings used by SharePoint when SharePoint does handle emails are not needed anymore in that case.
Your code will handle email management logic, with dedicated settings you are free to hard-code/store somewhere/etc.

[Note: glad to see you're reusing the code I had posted here http://sharepoint.stackexchange.com/questions/164837/deploy-bind-event-receivers-to-lists-in-single-feature! :)]

EDIT - what's under the hood
I dug into the code of the page. The page that displays the incoming email settings for the doc lib is "EmailSettings.aspx". If you open it, you see that the bottom sections are visible only under certain conditions, for instance:

<%
if (ShowAttachmentFolders)
{
%>
    <wssuc:InputFormSection Title="<%$Resources:wss,emailsettings_attachments_title%>" runat="server">
        ...
    </wssuc:InputFormSection>
<%
}
%>

So, the section shows up only if ShowAttachmentFolders is true. Looking at the code for ShowAttachmentFolders in ILSpy (class Microsoft.SharePoint.ApplicationPages.EmailSettingsPage, you see:

protected bool ShowSaveAttachments
{
    get
    {
        return !this.HasExternalHandler && (...);
    }
}

And HasExternalHandler is:

protected bool HasExternalHandler
{
    get
    {
        bool result = false;
        foreach (SPEventReceiverDefinition sPEventReceiverDefinition in this.m_List.EventReceivers)
        {
            if (sPEventReceiverDefinition.Type == SPEventReceiverType.EmailReceived)
            {
                result = true;
            }
        }
        return result;
    }
}

So, basically, this confirms the behavior is made on purpose by Microsoft, and that as soon as you have one ER of type EmailReceived registered on the list, most of the configuration sections do not appear on the page.

added 6 characters in body
Source Link
Evariste
  • 9.7k
  • 2
  • 21
  • 30

This perfectly makes sense to me: as soon as you attach an email ER, your code is in charge of handling incoming emails for this doc lib, according to your own business rules.
So standard settings used by SharePoint when SharePoint does handle emails are not needed anymore in that case.
Your code will handle email management logic, with dedicated settings you are free to hard-code/store somewhere/etc.

[Note: glad to see you're reusing the code I had posted here http://sharepoint.stackexchange.com/questions/164837/deploy-bind-event-receivers-to-lists-in-single-feature! :)]

This perfectly makes sense to me: as soon as you attach an email ER, your code is in charge of handling incoming emails for this doc lib, according to your own business rules.
So standard settings used by SharePoint when SharePoint does handle emails are not needed anymore in that case.
Your code will handle email management logic, with dedicated settings you are free to hard-code/store somewhere/etc.

[Note: glad to see you're reusing the code posted here http://sharepoint.stackexchange.com/questions/164837/deploy-bind-event-receivers-to-lists-in-single-feature! :)]

This perfectly makes sense to me: as soon as you attach an email ER, your code is in charge of handling incoming emails for this doc lib, according to your own business rules.
So standard settings used by SharePoint when SharePoint does handle emails are not needed anymore in that case.
Your code will handle email management logic, with dedicated settings you are free to hard-code/store somewhere/etc.

[Note: glad to see you're reusing the code I had posted here http://sharepoint.stackexchange.com/questions/164837/deploy-bind-event-receivers-to-lists-in-single-feature! :)]

Source Link
Evariste
  • 9.7k
  • 2
  • 21
  • 30
Loading