I need help or sample code in VB.NET to read a specified outlook folder that is not the inbox or a subfolder of inbox
Say folder name is "foo", how can I rerieve emails with a LINQ query, possibly adding where clause(s) for the from, to, date, subject or body content.
Thanks :-)
No offense, but when you have a hammer, everything looks like a nail :-)
Why does it need to be LINQ? It might look neat in you source code, but it can bring your application down to its knees - if you need any kind of restriction, use the native methods whenever you can. In your case, that would be Items.Find/FindNext/Restrict.
If you need to access an arbitrary folder, use the Namespace.Folders collection – it contains top level folders from all stores.
If the folder is on the same level as the Inbox, use Inbox.Parent.Folders collection.
You can use the following.
http://www.nuget.org/packages/scipbe.common.office/
Add it to your project and you can use linq like syntax with outlook.
Also
http://programmersunlimited.wordpress.com/2011/01/08/linqqer-exposing-linq-extensions-on-non-ienumerableiqueriable-collections/
Related
Does anyone knows if the google folder id changes over time? Assuming, obviously, the folder is not deleted and recreated.
I'm trying to be limit the quota usage as much as possible, by storing the ID on our side.
Thanks
UPDATE (2015/09/01) Per 'BSEs' comment below.
Sorry, I assumed it is Android (being professionally distorted).
Anyway, to make sure, look at the ID string in question and compare it with the ID you get from drive.google.com > right click > Get link. You should see something like:
https://drive.google.com/open?id=0B1mqwertyasdfghZxCvbItM0E
If the id= string matches your resource ID, you're cool. Sorry for the confusion.
ORIGINAL (incorrect for .NET, applies to GooPlaySvcs/GDAA on Android)
I believe it does.
When testing the ResourceId availability here, I remember getting DriveId in one form immediately in the 'onResult()' callback. Later, when the 'onCompletion()' event occured, the DriveId of the same object looked very different (applies to both file and folder) .
Also, look at Daniel's comment here, it suggests that you should not rely on the value of the DriveId in any moment and use 'equals()'.
The ResourceId would be more appropriate ID to store, shuttle around, etc... DriveId is useless outside the GooPlaySvcs instance. And, based on some hints from Drive-Involved-Googlers, relying on a concrete value of DriveId is dangerous. That makes existence of 'encodeToString() / decodeFromString()' somewhat questionable, right?
Good Luck
I use Folder.WellKnownFolderName to detect folder type, but it was introduced only in Exchange 2013. Also it doesn't work with "Clutter" folder. Can i use another Folder property to determinate exchange folder type?
Take a look at the FolderClass property. That tells you the type of folder (Mail, Calendar, etc.).
Iterate through all the WellKnownFolderNames you care about, and fetch the corresponding Folders individually by passing Folder.Bind a FolderId created with the constructor that takes a WellKnownFolderName. The FolderId of the returned Folder will have its unique ID set. Then just keep track of the FolderId-to-WellKnownFolderName mapping.
I am trying to get started using viewpoint against EWS within Ruby, and it's not making a lot of sense at the moment. I am wondering where I can get some good example code, or some pointers? I am using 1.0.0-beta.
For example: I know the name of the calendar folder I want to use, so I could search for it, but how to access methods in that folder once I find it? What are the appropriate parameters, etc...
Any advice?
If you haven't read it yet I would recommend the README file in the repository. It has a couple of examples that should put you on the right path. Also, the generated API documentation should give you enough to work with.
http://rubydoc.info/github/WinRb/Viewpoint/frames
At a very basic level you can get all of your calendar events with the following code:
calendar = client.get_folder :calendar
events = calendar.items
I hope that gives you a little more to get started with.
Follow-up:
Again, I would point you to the API docs for concrete methods like #items. There are however dynamically added methods depending on the type that you can fetch with obj.ews_methods. In the case of CalendarItem one of those methods is #name so you can call obj.name to get the folder name. The dynamic methods are all backed by a formatted Hash based on the returned SOAP packet. You can see it in its raw format by issuing obj.ews_item
Cheers,
Dan
I am making a site for a client and decided i would use code igniter.
The site essentially has two backends, one for designers, and one for a sales team. So after logging in, the user will be redirected to either
mysite.com/sales/
mysite.com/design/
The sales team for example can view orders, containers, products, therefore i need a controller for each of these.
mysite.com/sales/orders/
The sales need to be able to view, edit, delete certain orders...
mysite.com/sales/orders/vieworder/235433
Basically my problem is i dont have enough url segments to play with.
My thoughts on solving my problem
removing the orders, containers, products classes and making ALL of their methods as methods of the sales class, although this would mean a large number of methods and loading all models so it seemed kind of pointless.
removing the sales/designer classes and controlling what each kind of user has access to based on a user type stored in session data.
a way of having an extra url segment?
I appreciate any advice, I just dont want to get 3 weeks into the project and realise i started wrong from the beginning!
Use folders.
If you make a subfolder in /application/ called sales you can put different controllers in there:
/application/
/sales/
orders.php /* Controller */
/design/
Then in orders.php you will put your vieworders($id) method and so on, and you will be able to acces it with domain.com/sales/orders/vieworders/id.
You can also make subfolders in the /models/ and /views/ to organize your files.
Now, Access Control is something apart and it depends more in the auth system you are using.
Give the user/designer a privilege, a column in the user table for example, check the permission of the user at the beginning of the function, then prevent or execute it.
This would be the exact way i would do it.
Seems like you should have a look into the routing class. Might be a dirty solution but rerouting the sales/(:any) to something like sales_$1 would mean you'd make controllers with names like sales_orders.
Same for the design part.
(FYI: $routing['sales/(:any)'] = 'sales_$1'; should do the trick; see application/config/routing.php).
Given the SPList.ID and a site collection (or an SPWeb with subwebs), how do I quickly find the document library with the given ID?
I can recursively enumerate through all webs and perform a web.Lists[guid] on each one of them, but there might be thousands of subwebs in my case, and I'm looking for a realtime solution.
If there is no way to do this quickly, any other suggestions on how to uniquely identify a document library? I could store the full path (url), but the identification will be publicly visible and I don't feel very comfortable giving away our exact SharePoint document structure like that. Should I resort to maintaining a manual ID <-> library mapping in a separate list?
I vote for the manual ID -> URL pair matching in a top-level, well-known list that's visible only to the elevated privileges account.
Since you are storing the ListID somewhere, you may also store the WebId. Lists are opened by the context SPWeb always, so if you go to:
http://toplevel/_layouts/ListGeneralSettings.aspx?ID={GUID1} // OK
http://toplevel/sub1/_layouts/ListGeneralSettings.aspx?ID={GUID1} // Wont Work (same Guid)
Having the WebId and ListId you can simply:
using(SPWeb subweb = (new SPSite("http://url")).OpenWeb(new Guid("{000...}")))
{
SPList list = subweb.Lists.GetList(new Guid("{111...}"), true);
// list logic
}
MS does not support this :)...
But take a look at this for giggles: http://weblogs.sqlteam.com/jhermiz/archive/2007/08/15/60288.aspx
If you have MOSS Search available, then it might help, depending on the lag you have between these lists getting created and needing to search for them. You could probably map list id as a managed property and do a quick search for list objects with the id in question.
For lots of classes of problems it seems like search is the fastest way to rip through huge sets of data. In fact if this approach worked for you, you really wouldn't even need to know the site collection up front. Don't have access to any of my MOSS environments at the moment, so can't verify this will work though.