What I'm trying to do is send an email when a particular content type is created in Orchard.
What I did was create a workflow that detects when a "Practice" type is created and send an email.
Initially I hard coded everything (email address, subject and body). I am getting an email every time a "Practice" type is created.
I then tried using tokens to get real values. Initially I tried..
{Content.ContentType} and
{Content.Id}
Those seem to be working. The ContentType is "Practice" and the Id is the correct value.
The Practice type has a field called "ContactEmail", but I can't seem to get that value to show up. Here are the different variations I've tried...
{Content.Fields.Practice.ContactEmail}
{Content.ContactEmail}
{Content.Practice.ContactEmail}
but it's always blank (testing by putting these fields in the email body).
Any suggestions on how to the the "ContactEmail" value from a Practice?
Thanks!
Additional info...
The Practice part is created from a module (i.e. migration, model, etc.). What I think I may have to do is create a token provider for the Practice part. Does that sound right?
Related
I am required to create a Java Script but unable to figure on how to proceed as I don't have that much of coding idea in OIM, can someone assist(below I have mentioned the scenario)
Scenario:
In OIM User Attribute Page, there is a User Field: 'Job Code' now we have experienced that there are some issues we are facing.
From the trusted source we are getting the correct data but as soon as it reaches OIM for few users we are getting random incorrect value. Value should be numbers (123456) which is present in the Database too and valid but for few we are receiving values like E?401#q something like this.
We are required to place a check to find users who are having these invalid Job Code entry.
Once detected, we need to trigger a email to the concerned team based on the User Type (Employee or Contractor) for employee it should trigger an email to a respective team and for Contractor we have to trigger to a different team to take action.
So, I believe we have to place two conditions here, can someone assist.
If you believe it only happens during trusted source reconciliation, then you can create Post-Process Handler on User Create/Modify operation to check the value which was posted into the DB as a result of recon event.
From this handler you can do all the things you need to do: mailing, fixing, etc.
For notification purposes I'd recommend to use built-in NotificationService, though it might be bit daunting, if you have little experience in OIM development. As an alternative you can do java mailing.
If you are not sure about the moment, when this "spoiling" happens, you can create a scheduled task, to be executed periodically, which will check JobCode values, to report invalid ones.
Working in Nintex, I have a workflow that is kicked off when a form is saved. The workflow generates a PDF version of the Nintex form (we need actual signatures - digital in the future, fingers crossed). This is done by updating a word template, then converting to PDF.
When the word document is updated, the 'assigned to:' field is getting an AD account name instead of the user's First, Last name (which is expected). Now I'm trying to format it so it's more appropriate to the Hard Copy (in the Nintex form, it shows as Last, First).
I used a Query User Profile action, passed it the same variable I was using to hold the form's 'assigned to' value, and then used the drop down menu to choose the user profile variables I wanted (First, Last, also: username, account name, Distinguish name). All values are generating empty strings.
I've incrementally tried handing the values to variables that are of type String, Person, or Collection. I also handed it my username instead of the variable and set my account info for the login. I've always selected values, so I don't think it's a typo.
I'm at a loss... the workflow emails the user at the end, so it's getting the data. I hope that's enough info, I'm new to SP/Nintex so it could be a rookie mistake. Any help is appreciated.
Thank you!
I've seen issues where the User Profile Service properties have not been configured adequately, which leads to a lot of empty variables when running an LDAP Query action for AD attributes.
If this is the case, then one approach is to get the Farm admin (if you don't have access) to take a look at Manage User Profiles in Central Admin and see what AD attributes are mapped to the user profile. If mappings are changed you'll need to run a full sync to bring over the values. It can be inconsistent in my experience as well.
I have some javascript code attached to the accounts entity. This code sets the requirement level of the primary contact attribute based on the value of a custom option set field showing various account types. This was developed on one server, where it worked, and so the solution was imported into another organisation where it now doesnt work.
It seems to be only on this field as i have changed the code to look at another field and that works fine. The error it gives is that the "Object doesn't support this property or method". Also what is strange is that the field doesn't appear in the list under the entity within the solution despite it being a system field.
The code i'm using is:
Xrm.Page.getAttribute("primarycontactid").setRequiredLevel("required");
Can anyone help me figure out what it's doing?
Thanks
EDIT: Found that the code is actually making the field required despite the error, but it's not displaying the * next to it. Also if I make the field required in it's settings then it does the same thing
I work in a development/support team which has a shared Lotus Notes mailbox. We need to be able to associate an issue ID with each email. We started by adding this ID to the subject line (eg. "Something doesn't work [ID12345]"). For performance reasons, our IT dept don't allow indexing of shared mailboxes, so it takes a long time to search for a particular ID.
I decided to add a new ID field, which can be shown as a sortable column in views and folders. I put this field to the visible header (just below 'Subject') in the ($All) view and the ($Inbox) folder, and copied the ($Inbox) design to all the other folders in the database. That much was easy.
My problem is that when we reply or forward, this custom field is not carried over to the new memo, so we have to manually add it again before sending. And of course when the user responds, the field is again missing and must be manually added. I have searched the docs and the internet and haven't found any information on this. Either I have to declare this field as something which persists across replies and forwards, or I have to add a line somewhere which explicitly copies the field contents to the new memo.
fsw,
We do exactly this with our complaint system however our database is indexed although this should not be an issue to you. We created a view that is sorted by ID by extracting just the ID from the subject line, order it by ID and then by date descending. Base it on the $ALL folder view so you get both incoming and sent emails.
We then altered the memo form to include an embedded view single category of the new view that sits above the body which shows all other documents linked to the ticket.
This should avoid having to delve to far into the very complex mail template any further. One thing is to make sure you have a copy of the changes you made and a bit of doco re deploying as you can guarantee that one day your template will be completely overwritten in an upgrade and all your good work will be gone.
As the additional field would have to incorporated into all Memo forms in mail templates in your corporation and as these fields do not easily travel via SMTP, you should stick with the ID in the subject.
What you could do is to parse the subject (#Mid, #Right, ...) in the column formula in the view and only display the ID there (like you did with the additional field).
The other option I envision if having a field is required is to have an agent that processes the incoming message(reply) to have it parse out the issue ID from the subject and write it to the field. You could also do that with queryopen or postopen if running an agent is not possible
I'm building a SharePoint (MOSS) publishing site for employee information on my company website. I have an employee content type and am using the Contact E-Mail Address site column to store an employee's email address.
Want I'd like is the ability to encode email addresses at runtime to prevent the real email address from being harvested by spammers. This would be decoded when a user clicks the email hyperlink e.g. the following HTML would be sent to the browser:
Email Jonny
I already have the javascript methods for encoding/decoding a text value from the meaningless string above, but am not too sure as to how to approach this with SharePoint in mind. I'm thinking a custom control and/or custom J-Query?
Any help would be much appreciated!
Jonny
In the case that you are unable to put the users into AD, a custom field control will give you the ability to include the custom rendering (jquery) you require as well as the ability to enter the data as "normal" text.
The custom field, once defined "just works" wherever you need to display the field.
Given you are thinking of using JQuery, the issue then becomes one of making sure the jquery library is correctly linked whenever you need to us a field of this type.
If you make those employees members of the site, SharePoint takes care of this issue.
You can send emails to them, but the email address will only be used at send time, when you add a button to email someone, it will not show the email address, its handled at the backend.
SPUtility.SendEmail(SPContext.Current.Web, false, false,
[SPUser.Email][1], "E-mail title",
"E-mail body");
(source: msdn.com)
Two more options/approaches you can try:
(1) implement a custom TextField control, inheriting from Microsoft.SharePoint.WebControls.TextField and override RenderFieldForDisplay
Then in code - encode the field for display.
Add this control to safecontrols and use this in place of the normal TextField in the pagelayout.
(2) use the existing TextField control, but inject a button [Encode] using jQuery next to the TextField in editmode.
Use the JavaScript encode method to encode what the user has typed into an encoded value, replacing the existing TextField value. Which they can then save to into SharePoint.
I'd rate the approaches based on your deployment scenario - Nat's one is the cleanest but probably more involved for deploying, and the jQuery-only one seems very hackish but easy on deployment. The override TextField approach would probably sit somewhere in the middle.