Hello,
I extended the Recruitment application in order to capture internal
mailing-lists in our office into xwiki pages and objects (Topics and
Messages, with a set of fields captured including content and attachments).
Each mail generates a Message page & object, each thread is captured in a
Topic page & object. Topics can display messages in 3 views (forum-like,
threads-tree, table).
Mails are pushed from a particular folder in my mailbox, of course a generic
mailbox can be used.
I'd like to post it to the community since a long time, but I still did not
find time to update the application so it can be posted. I need to remove my
own login/password ( :) ), make it a little bit more generic ... You should
notice also that it has only been tested with mails coming from an Exchange
server, so there might be some tricks with headers when used with Gmail or
other mailers. For example my algorithm is trapped if someone breaks threads
(replies to a mail to start a new topic), because sometimes people just add
"RESOLVED" in subject and I wanted to keep the same thread in this case.
This might not be the best for every use-cases.
But it's a good start maybe !
By the way the app also have some categories (using configurable patterns in
mail subject), type (message, newsletter or delivery, these are hard-coded
for now), and a statistics page (top posters, categories dispatch, etc).
Internally it works well for some months now.
Best regards,
Jeremie
2011/3/5 Paul Libbrecht <paul(a)hoplahup.net>
I agree that XWiki remains a mail client.
I agree that XWiki should define listeners and default behaviours to such
listeners (such as create a page, add a comment, or update a page).
I misread Sergiu's post in a funny manner:
fire events when new mails are deleted in the
mailbox
(as opposed to detected in the mailbox).
What's funny here is that using an IMAP (and not POP) client, one could
indeed maintain some xwiki pages (update, delete, rename). It'd be cute I
find.
paul
Le 5 mars 2011 à 16:31, Sergiu Dumitriu a écrit :
It's
a bit comple to be a mail server as it creates administration
issues and requires a specific subdomain and routing.
An alternate solution is a mailbox and a scheduler job which pools the
mailbox. All the APIs are already there for that.
+1, XWiki itself should NOT be a mailserver. It should indeed be
configured to read an external mailbox, fire events when new mails are
detected in the mailbox, and then components can do what they want with
the new emails: convert them into wiki pages, notify users, send a
reply, etc.
> What's necessary is define a convention of where the content goes based
> on what is in the email (subject or specific marker or alias target
> address).
>
> I've aleady of few cases where we load emails. On our intranet we load
> job posting in our Recruitment application.
>
> However there is no generic loading mecanism for all of XWiki. I agree
> it could be interesting.
> I'm very interested in a feature that would allow an email discussion
> that is captured as comments in the wiki.
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users