[ENH] EmailFolders

Email Folder is a new Tracker field type being able to hold a list of emails in flat format or imap folder-like structured support for Inbox/Sent/Trash folders. Emails are currently moved to tracker items via Cypht web interface. Cypht is used to display Tiki-stored messages and handle all relevant actions - read, reply, forward, copy, move, delete. Message could be moved/copied to another tracker item or to an IMAP folder.

assigned to @kroky

This PR should not be merged yet. Waiting for upstream changes from Cypht in order to prepare and merge...

marked this merge request as draft

https://github.com/jasonmunro/cypht/pull/495 - this is the PR we are waiting for.

It was merged.

added 8 commits

• daba9983...a85b85c0 - 7 commits from branch tikiwiki:master
• 41fe9219 - Merge branch 'master' into feature/email-folders

Compare with previous version

added 1 commit

• ea78f496 - [ENH] EmailFolders: update to most recent upstream Cypht

Compare with previous version

added 1 commit

• b6c2e986 - [FIX] EmailFolders - delete and copy/move fixes

Compare with previous version

resolved all threads

marked this merge request as ready

resolved all threads

merged

This commit is a giant step for https://dev.tiki.org/Email-as-a-first-class-citizen

I started the docs: https://doc.tiki.org/Email-folders-Tracker-Field

How emails can be copied or moved to the tracker via the Webmail interface ?

@eric-ampire You need to have at least 1 tracker item with this field, so there is a place to move emails to.

Don't forget to add new packages to doc/devtools/satis.json so they appear on composer.tiki.org

saw you added that, thanks @jonnybradley ! Just a note that we try to use version indicator with syntax "greater than or equal" (>=) in the satis.json, as restricting to version 1 will fail to include v2 later on when we move tiki to use another major version of the lib. It will simply be unavailable on composer.tiki.org.

Hmm, i'm not so sure that's the best thing... we should check with @jyhem who frequently points out the storage on composer.t.o isn't infinite but we keep adding new packages to it, so adding ones that we're not using might not be popular

I think we need a script of some sort to go through all the (supported) composer.json files and weed out unused packages from composer.tiki.org - or get him lots more storage! (probably cheaper ;)

Yes, it is eating a huge amount of storage space but we have just too many possible version conflicts to support... each single composer update makes (sometimes) dozens of new versions for a single Tiki version. Add back several Tiki versions we support. I am not even sure your other suggestion is feasible, sorry.