'Microsoft.SharePoint.MailMessage' is inaccessible due to its protection level
On this code:
MailMessage mail = new MailMessage();
mail.From = "myemail#xxxxx.edu";
mail.To = "myemail#xxxx.edu";
mail.Subject = "Testing Code";
mail.BodyText = what;
mail.Priority = MailPriority.High;
Smtp.Send(mail, "smtp.xxxxx.edu");
How can remidy this? changes to web.config? Any way to circumvent in code?
This error is saying that MailMessage does not have public constructor. Most likely, it is for internal SharePoint use only.
Actually, in most cases in SharePoint you need to use SPUtility.SendEmail method to send mail with SharePoint. It is very simple:
SPUtility.SendEmail(SPContext.Current.Web, false, false, "myemail#xxxxx.edu", "Testing Code", what);
See MSDN for details on this method:
http://msdn.microsoft.com/en-us/library/ms411989.aspx
If you need to send email under ordinary user accounts, you should use SPSecurity.RunWithElevatedPrivilegies method to provide elevated privilegies.
Only disadvantage is that SPUtility does not support attachments. If you need attach some files to your letter, please use System.Net.Mail.
I know a good post from Edwin Vriethoff, which provide detailed information about sending email with attachments, with default SharePoint SMTP settings (they are configured through Central Administration):
http://edwin.vriethoff.net/2007/10/02/how-to-send-an-e-mail-with-attachment-from-sharepoint/
Related
Is there a way to prevent an external recipient from replying to an email, we need them to update our portal. In the ReplyTo Field we add "please update our portal with your response" but many users ignore it by changing the ReplyTo Field.
We create the problem as we add a full description of our customer update in the body rather than just adding a link. I don't really wish to remove this additional information as it is more user friendly. Access to the portal and their 'ticket' is extremely user friendly, one click, it is just people being lazy.
This is how the email is generated.
Many thanks for any suggestions.
var recipient = document1.getItemValueString("emailField");
var sendergroup = "support#ourcompany.co.uk";
var memo = database.createDocument();
memo.appendItemValue("Form","Memo");
//memo.appendItemValue("Principal","Support Request#NotesDomain");// Don't use.
memo.appendItemValue("From",sendergroup);
memo.appendItemValue("INetFrom",sendergroup);
memo.appendItemValue("ReplyTo","... please update our portal with your response.");
memo.appendItemValue("DisplaySent",sendergroup);
memo.appendItemValue("SMTPOriginator",sendergroup);
memo.appendItemValue("Subject", Our references here ");
var rtitem:NotesRichTextItem = memo.createRichTextItem("Body");
var rtStyle:NotesRichTextStyle = session.createRichTextStyle();
rtitem.addNewLine();
rtitem.appendText("Hi "+firstname+",");
rtitem.addNewLine();
rtitem.appendText("Details of the request in here..");
rtitem.addNewLine();
rtitem.appendText("https://link to their document in here");
memo.send(recipient);
As far as I know you cannot control what happens at the recipient's mail system....
However, you could use a sender/reply address where the mail goes to a mailin database where you could have an agent send them a reply stating that their reply is ignored and that they will have to open the link....
Not ideal - but then at least they know :-)
If you use the properties in EmailSettings to change the reply email address, do you also need to assign a value to the reply name override property? If you don't, what does it use for the name?
From the legacy official REST documentation, the replyEmailNameOverride is NOT required.
While the documentation doesn't mention this, if you don't specify it, it seems that it will reuse the name of the original recipient it was sent to.
See my example below in C#:
EmailSettings settings = new EmailSettings
{
ReplyEmailAddressOverride = "otherUserThanTheSende#fakeemail.com"
};
docuSignEnvelope.EmailSettings = settings;
To go further, if you look at the DocuSign recipient email source, you can see that they assign the recipient name to the reply email as below :
I'm looking for sample script that resets the default permissions on an external spreadsheet based on the email address and DocumentID passed to the script. I intent to create a script that can parse information from an email message to acquire the DocumentID and email, execute the permission change from default to anyone with a link, then email the passed address with that link.
It appears that perms are controlled by the DocList API and I'm not finding samples of GAS interacting with that API.
At Google I/O 2013, DriveApp was launched. This allows developers to build use cases like Sharing to Anyone with link
https://developers.google.com/apps-script/reference/drive/
Sample code -
var quizTemplate = DriveApp.getFileById(QUIZ_TEMPLATE_ID);
quizTemplate.setSharing(DriveApp.Access.DOMAIN_WITH_LINK, DriveApp.Permission.VIEW);
or
var openFile = DriveApp.getFileById(WIDE_OPEN_ID)
openFile.setSharing(DriveApp.Access.ANYONE_WITH_LINK, DriveApp.Permission.COMMENT);
AFAIK DocsList Services does not have a function to change the sharing mode, between private/anyone with a link/public, only to add/remove editors and viewers. But we can still achieve this by previously setting manually the share settings of a specific folder to "anyone with a link". Then, we have just to add the file to that folder to have it shared.
A script to do that is particularly simple. e.g.
function shareWithAnyoneAndEmail(documentID,email) {
var sharedFolder = DocsList.getFolderById('id-to-your-previously-shared-folder');
var file = DocsList.getFileById(documentID);
file.addToFolder(sharedFolder);
MailApp.sendEmail(email, 'Here is your file', file.getName()+'\n'+file.getUrl());
}
I've created a custom workflow which creates a task item when the workflow is kicked off.
alt text http://img19.imageshack.us/img19/2862/screenshot310200942100p.png
I've also created a few custom content types for the document library and task list.
For the document library:
First, I add a document library and configure it to allow custom content types. Then I add my content type, which is based off the document content type. After, I add a workflow under workflow settings. Here, I select my custom workflow, give it a name and tell sharepoint to create a New task list to store the tasks in.
For the task list:
Now that I have a sharepoint created task list, I go there and allow custom content types and make sure "Send e-mail when ownership is assigned?" is set to Yes. Then I add my two custom content types which are both based off a workflow task content type. Thats all I should do.
When I start my workflow, it does add the approval task (I'm using a CreateTaskWithContentType activity which is named createApprovalTask), but no email is sent out for the created task.
The code I'm using in the createApprovalTask activity is:
// make a new GUID for this task
createApprovalTask_TaskId = Guid.NewGuid();
// set simple properties of task
createApprovalTask.TaskProperties.AssignedTo = "a valid domain\user";
createApprovalTask.TaskProperties.Title = "Review Contract: " + approvalWorkflowActivated_WorkflowProperties.Item.DisplayName;
createApprovalTask.TaskProperties.SendEmailNotification = true;
If I create a document library and use one of Sharepoint's built-in workflows (Approval for example), and tell it to create a task list for it, when an item is added to that list, it sends out the email correctly. So, the setting for the outgoing mail server are correct, as we're receiving other emails just fine.
I'm using a SendEmail activity right after the createApprovalTask activity to send an email back to the submitter telling them we've received their approval request. The code for that is something similar to:
sendApprovalRecievedEmail.Body = emailBody;
sendApprovalRecievedEmail.Subject = emailSubject;
sendApprovalRecievedEmail.To = emailTo;
sendApprovalRecievedEmail.From = emailFrom;
This works, so the submitter receives their custom email, but the task owner never receives the task item email.
Unfortunately, our mail servers were blocking the emails for some reason. I wasted a good 2 1/2 days searching around for this problem...and it turns out our IT department didn't have their sh*t together.
Thanks everyone.
you have to make sharepoint outgoing email settings properly.
example is shown in below link
http://sharepoint-amila.blogspot.com/2008/02/outgoin-email-settings.html
if you need to send an email through the c#.net code you can use below method to send emails in custom workflows.
SPUtility.SendEmail Method (Microsoft.SharePoint.Utilities)
example is shown in below link
http://www.sharepoint-amila.blogspot.com/
Is it possible to point out a SharePoint user by "domain\user" like you do with createApprovalTask.TaskProperties.AssignedTo? Isnt the ID required?
"id;#domain\username"
I'm Trying to login with dotNetOpenId to GMail accounts. It works but I'm not able to retrieve any claims. I know I could retrieve email addresses or user names as well, but no claims are being returned only the ClaimedIdentifier is available. Anyone know how to retrieve this data from Gmail accounts? If you could please provide me an example of ClaimsRequest configuration I would be grateful.
Thanks
// Either you're creating this already or you can get to it in
// the LoggingIn event of the control you're using.
IAuthenticationRequest request;
// Add the AX request that says Email address is required.
var fetch = new FetchRequest();
fetch.Attributes.Add(
new AttributeRequest(WellKnownAttributes.Contact.Email, true));
request.AddExtension(fetch);
Google then authenticates the user and returns the email address, which you can get with:
var fetch = openid.Response.GetExtension<FetchResponse>();
if (fetch != null)
{
IList<string> emailAddresses = fetch.GetAttribute(
WellKnownAttributes.Contact.Email).Values;
string email = emailAddresses.Count > 0 ? emailAddresses[0] : null;
}
You can see my blog post on the subject for a bit more information. The important thing to note here is that Google will only tell you the user's email address if you mark it as required (as I have done in the above snippet). But this also means that if the user does not want to share his email address, he cannot log in at all. Sorry, that's the way Google set it up. Other Providers that people use have different behaviors, unfortunately.