I use a UserProperty to store custom specific information in an Outlook AppointmentItem. Now my question is whether this information is being transferred to the recipients of the AppointmentItem when the invitation is being sent?
If this is NOT sent with the AppointmentItem, how can I transfer custom info with the invitation and how can I code this in the AppointmentItem (or the object needed for that?)
Best regards
Hannes
Most likely not. Keep in mind that AppointmentItem is never sent. When you call AppointmentItem.Send, it creates a new MeetingItem object and sends it instead.
You can trap the Application.ItemSend event, check that you are processing a MeetingItem object, retrieve the corresponding AppointmentItem object using MeetingItem.GetAssociatedAppointment, then copy the user properties from AppointmentItem to MeetingItem. Keep in mind that user properties (which are stored as named MAPI properties) will only persist if the MeetingItem is sent in the TNEF format, e.g. between two Exchange mailboxes in the same domain. If it is converted to the iCal format, named properties will be gone.
Related
I currently have a requirement to implement security on Document objects (non-existing, yet to be added) based on a property of type String/list in which based on the value chosen, the security of the object should change (security is role based). Please note that once the document is created this security-specifier property does not change
I had two approaches in mind. The first approach is that I Create a custom event handler to be triggered on create event, in the event handler, I instantiate a pre-created security policy and apply it to the object.
The second approach is using security proxy objects, so that each Role/ACL is represented by an object, and through the event handler I would assign this security proxy to the document object
My question is, does filenet content foundation 5.2.1 provide any out of the box functionality that covers this without customization?
Out-of-the-box facility to enforce security based on some property value is Markings. You should carefully study the documentation as there is some specifics and limitations to their use. For example, one cannot have markings on a property with choice list.
I have an Outlook COM add-in (C#, Visual Studio 2012) that extends the standard form with additional message properties. The add-in works with Outlook 2010, 2013 and 2016.
The requirements for the add-in dictate that it supports reading and writing a set of properties in namespace PS_INTERNET_HEADERS. I follow the guidelines in http://blogs.technet.com/b/exchange/archive/2009/04/06/3407221.aspx to have such headers on incoming messages promoted to MAPI properties.
But as I understand it, all such headers will become MAPI string properties, right?! But several of these headers actually have more natural types. One the headers is an RFC5322 date-time header and will have a value like 'Wed, 28 Sep 2016 06:27:00 GMT'. Having such a header mapped to a MAPI property of type PT_UNICODE is not optimal as you cannot sort messages based on it, you cannot really use it in searches, etc.
Is there a good solution to this problem?
The only idea I have is to do some kind of mapping from properties in namespace PS_INTERNET_HEADERS to properties in namespace PS_PUBLIC_STRINGS. That would would also have the nice side-effect that properties will be included when printing messages. But if I have to go down that road, I need some kind of hook for doing the mapping. I can of course loop through all messages in a message store, listen for new messages coming in, listen for changed messages, etc - but it does not feel like a good solution. I guess I could also write an Exchange Transport Agent, but I would really like to keep logic on the client side.
Any suggestions?
Edit after Dmitry's comment:
For outgoing messages, I have to use properties in namespace PS_INTERNET_HEADERS since such messages are eventually transported by SMTP (outside Exchange) to other systems. In detail, I have to adhere to https://www.rfc-editor.org/rfc/rfc6477. As a side-effect, Exchange will for incoming messages promote such headers to properties in namespace PS_INTERNET_HEADERS. And that's all working fine.
But even in that case, I would like to follow your suggestion to extract properties explicitly in my code and write some new ones in namespace PS_PUBLIC_STRINGS. The challenge as I see it is which hook to use for running that code. Users should be able to use the mapped properties as columns in views, for sorting, for filtering, for search, inbox rules, etc. I can sweep entire message stores to do that mapping, I can listen for various Outlook object model events, but in the end I have a hard time seeing how I can avoid users to temporarily see messages that my code haven't treated yet.
I have an old add-in written in C++ using Extended MAPI with a similar challenge. On start-up, for each inbox in each IMsgStore it sweeps the entire inbox (potentially a quite expensive operation) and then subscribes to changes using IMAPIFolder::GetContentsTable and then IMAPITable::Advise. But my experience is that I will get table notifications TABLE_ERROR or TABLE_RELOAD now and then and will have to do another sweep. For IMsgStore::Advise I guess similar challenges are present?! In a C# context, I could use the events in Redemption class RDOStore (e.g. OnMessageModified) , but I assume that class uses IMsgStore::Advise?!
No, the property type will never to converted. It always stay as a string. Why not read the internet headers from the PR_TRANSPORT_MESSAGE_HEADERS property (DASL name http://schemas.microsoft.com/mapi/proptag/0x007D001F) and extract the properties explicitly in your code? You will have full control over which properties are extracted and how they are converted.
I have two COM objects (let's call them Control and Job). Control is CoCreatable, Job objects are created by Control.NewJob().
Control has a method Control.Start(job) that makes the specified job the current job. It remains the current job as long as no other job is set.
Now for the client the following behavior appears reasonable for these particular controls:
as long as one of its Jobs exist, Control exists
(trivial: Job holds strong ref to the Control it created)
As long as the client has either a reference to Control or its CurrentJob, neither gets destroyed
("trivial": CurrentJob is a strong ref)
Client should not need to "clear" CurrentJob before releasing references
Now, I have a classic circular reference here, the condition to release it would be both objects not having external references.
I can solve this scenario by mucking around with ATL's InternalRelease implementation, but this is pretty ugly and isolated.
Any suggestions? Existing solutions?
as long as one of its Jobs exist, Control exists
No, fairly sure that this is the rule where you went wrong. Keep your eyes on the ball, the only reason you added the IControl::CreateJob() factory function is to give CJob (the implementation class, not the interface) a CControl* reference. This implies ownership, a particular IJob can only ever be associated with a particular Control instance. CControl should therefore keep a collection of CJobs that it owns.
It now becomes straight-forward:
The CControl instance is created as normal, there is only one AddRef() call, only the app owns the instance.
The IControl::CreateJob() implementation method creates a new CJob with the CJob(Control*) constructor, adds it to the collection and returns the IJob interface pointer. There is only one AddRef() call, only the client app owns the instance.
The CJob destructor calls a private CControl::RemoveJob() method to get itself removed from the collection, using the CControl* it got from its constructor if it is not null.
The CControl destructor iterates its collection, setting the CControl* that any remaining CJob maintains back to null. They are now un-owned.
The IControl::Start(IJob*) implementation method calls AddRef() to ensure the job stays alive. Release when the job is done or is replaced or the CControl object is destructed. Note that an error check is required, the method needs to iterate the collection to find the matching CJob object. So the client cannot start a job that was created by another Control instance. And allowing you to keep a CJob* as the CControl::currentJob private variable.
I don't think ATL has out of the box solution since the behavior in question is sensitive to specific requirements.
As long as the client has either a reference to Control or its CurrentJob, neither gets destroyed ("trivial": CurrentJob is a strong ref)
This requirement assumes that an external strong reference to Control exists from the side of the current Job, since control needs to stay alive with client to job reference only. That is, both control and job have strong references one to another. And then control+job combination needs to correctly handle release of all external references. For instance, this can be achieved the following way.
Job's (and the same way Control's?) CComObjectRootEx::InternalRelease is overridden and it checks whether the only external reference remained is the control's one. If this is the case, the job is initiating termination check - it calls certain control's method to check its references. If job's reference is the only reference control sees on itself, then both release references one to the other (and terminate).
I have an Objective-c class MyClass that subscribes to MyNSNotification. There are multiple instances of MyClass in my application. Hence multiple objects receive the notification. Is there a way to "filter" notifications for a particular object?
I imagine doing a check in the selector. I'm just not sure how to set it up.
Use userInfo for that purpose issuing notification. Recieving one check userInfo to decide if this notification targeted here or not. Sometimes enough to know who sent notification. Use object property for that. Consult class reference http://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSNotification_Class/Reference/Reference.html
We need to create a transactioscope object in our WCF request. We want to add a check that only one object of TransactionScope should be created for a request. So, before creating 'TransactionScope ' object, we want to check if the object is already created or not. If its already created, then we will not create the object.
For implementing this, we want to attach TransactionScope object with OperationContext.Current so that we can add check before creating any object. Kinldy help/guide us regarding attaching the 'TransactionScope' object with OperationContext.Current object. Thanks
You can use the TransactionScopeRequired property of the OperationBehavior attribute: http://msdn.microsoft.com/en-us/library/system.servicemodel.operationbehaviorattribute.transactionscoperequired.aspx
Set it to true to force the creation of a TransactionScope for the operation even if the transaction is not initiated by the client.