Adding a shared folder & getting the folder ID

crankshaft

If I understand correctly, Public Folders which are visible through webapp and IMAP can also be made visible to z-push and then ultimately outlook via the connector.

Previously using zarafa 7, public folders did appear for outlook users without any special setup.

So I believe that you share a public folder for z-push with:

z-push-admin -a addshared -u SYSTEM -n "Support" -o "SYSTEM" -t "email" -f "XXXX"

Where XXXX is the ID of the Folder in the main kopano store ?

But how do I find the ID of the Folder in the store ??

fbartels

@crankshaft the id can for example be retrieved with the listfolders.php script.

The whole system is documented at https://wiki.z-hub.io/display/ZP/Sharing+folders+and+Read-only. Additionally hints in https://stash.z-hub.io/projects/ZP/repos/z-push/browse/src/config.php#369-384.

crankshaft

@fbartels - Thanks, I already tried that before posting, that appears to list the z-push folders and not the main store folders, unless my syntax is wrong ??

php7.0 /usr/share/z-push/backend/kopano/listfolders.php -l system
Available folders in store 'system':
--------------------------------------------------

This shows no folders, however there are existing Public Folders !

fbartels

@crankshaft works for me:

$ php listfolders.php -l system
Available folders in store 'system':
--------------------------------------------------
Folder name:    Kontakte Public
Folder ID:      9fff4aaa33ec4131bee5975920f72684270200000000
Type:           SYNC_FOLDER_TYPE_USER_CONTACT

With the amount of questions you have at the moment I have the feeling that it would be beneficial for you to get in direct contact with our support. That should be more efficient as this is here.

crankshaft

Thanks Felix, but I am almost there now.

This is the final stage to get existing ZARAFA 7.1 OUTLOOK users working on Kopano 8, and then we will go live.

Until 1 day ago I was using the standard 8.7.0 repos that are available on Debian 10, but decided instead to use the official kopano repos and hence all the questions regarding installing via the official supported repos.

This is the Public Folder structure:

Public Folders ( \\Public Folders) 
    Support ( \\Public Folders\Public Folders )
        amk (\\Public Folders\Public Folders\Support)

I have applied permission to all 3 folders to Everyone > Full Control and the folder type is “mail and post items”

Is there some other property of the public folders that may be preventing them from being shown ?

I can see them both in webapp and in thunderbird and OSX mail app (all IMAP), so this has to be related to z-sync ?!

This is a screenshot of the folders to prove they are there !!!

Pub Folders

crankshaft

This post is deleted!

crankshaft

OK, the problem is with this condition:

// handle some special folders
if ((strtoupper($user) != 'SYSTEM') &&
    ((isset($inboxProps[PR_SOURCE_KEY]) && $folder[PR_SOURCE_KEY] == $inboxProps[PR_SOURCE_KEY]) ||
    $folder[PR_ENTRYID] == $storeProps[PR_IPM_SENTMAIL_ENTRYID] ||
    $folder[PR_ENTRYID] == $storeProps[PR_IPM_WASTEBASKET_ENTRYID])) {

        $folder[PR_CONTAINER_CLASS] = "IPF.Note";
}

If I append immediately below:

$folder[PR_CONTAINER_CLASS] = "IPF.Note";

Then all the folders are listed:

# php7.0 listfolders.php -l SYSTEM
Available folders in store 'SYSTEM':
--------------------------------------------------
Folder name:	AMK
Folder ID:	7d495544bfdf418fa67ea1031c5b94daa30000000000
Type:		SYNC_FOLDER_TYPE_USER_MAIL
PR_CONTAINER_CLASS:907214878
Folder name:	Support
Folder ID:	7d495544bfdf418fa67ea1031c5b94daa20000000000
Type:		SYNC_FOLDER_TYPE_USER_MAIL
PR_CONTAINER_CLASS:907214878
Folder name:	Zarafa 1
Folder ID:	7d495544bfdf418fa67ea1031c5b94da9f0000000000
Type:		SYNC_FOLDER_TYPE_USER_MAIL
PR_CONTAINER_CLASS:907214878
Folder name:	SCHEDULE+ FREE BUSY
Folder ID:	7d495544bfdf418fa67ea1031c5b94da9e0000000000
Type:		SYNC_FOLDER_TYPE_USER_MAIL
PR_CONTAINER_CLASS:907214878
Folder name:	FINDER_ROOT
Folder ID:	7d495544bfdf418fa67ea1031c5b94da9d0000000000
Type:		SYNC_FOLDER_TYPE_USER_MAIL
PR_CONTAINER_CLASS:907214878
Folder name:	NON_IPM_SUBTREE
Folder ID:	7d495544bfdf418fa67ea1031c5b94da9c0000000000
Type:		SYNC_FOLDER_TYPE_USER_MAIL
PR_CONTAINER_CLASS:907214878
Folder name:	IPM_SUBTREE
Folder ID:	7d495544bfdf418fa67ea1031c5b94da9b0000000000
Type:		SYNC_FOLDER_TYPE_USER_MAIL
PR_CONTAINER_CLASS:907214878

This is only a debug hack and not the solution, but I am curious as to why the conditional check does not identify the folder type.

I also echoed the PR_CONTAINER_CLASS in this output, not sure if that is helpful.

Manfred

Hi crankshaft,

@crankshaft said in Adding a shared folder & getting the folder ID:

OK, the problem is with this condition:

// handle some special folders
if ((strtoupper($user) != 'SYSTEM') &&
    ((isset($inboxProps[PR_SOURCE_KEY]) && $folder[PR_SOURCE_KEY] == $inboxProps[PR_SOURCE_KEY]) ||
    $folder[PR_ENTRYID] == $storeProps[PR_IPM_SENTMAIL_ENTRYID] ||
    $folder[PR_ENTRYID] == $storeProps[PR_IPM_WASTEBASKET_ENTRYID])) {

        $folder[PR_CONTAINER_CLASS] = "IPF.Note";
}

No, it’s not. You’re running the listfolders for SYSTEM, so it’s not even supposed to go into this condition. Public folders don’t have sent items or wastebasket system folders, so it only make sense for regular users.

If I append immediately below:

$folder[PR_CONTAINER_CLASS] = "IPF.Note";

Then all the folders are listed:

# php7.0 listfolders.php -l SYSTEM
Available folders in store 'SYSTEM':
--------------------------------------------------
Folder name:	AMK
Folder ID:	7d495544bfdf418fa67ea1031c5b94daa30000000000
Type:		SYNC_FOLDER_TYPE_USER_MAIL
PR_CONTAINER_CLASS:907214878
Folder name:	Support
Folder ID:	7d495544bfdf418fa67ea1031c5b94daa20000000000
Type:		SYNC_FOLDER_TYPE_USER_MAIL
PR_CONTAINER_CLASS:907214878
Folder name:	Zarafa 1
Folder ID:	7d495544bfdf418fa67ea1031c5b94da9f0000000000
Type:		SYNC_FOLDER_TYPE_USER_MAIL
PR_CONTAINER_CLASS:907214878
Folder name:	SCHEDULE+ FREE BUSY
Folder ID:	7d495544bfdf418fa67ea1031c5b94da9e0000000000
Type:		SYNC_FOLDER_TYPE_USER_MAIL
PR_CONTAINER_CLASS:907214878
Folder name:	FINDER_ROOT
Folder ID:	7d495544bfdf418fa67ea1031c5b94da9d0000000000
Type:		SYNC_FOLDER_TYPE_USER_MAIL
PR_CONTAINER_CLASS:907214878
Folder name:	NON_IPM_SUBTREE
Folder ID:	7d495544bfdf418fa67ea1031c5b94da9c0000000000
Type:		SYNC_FOLDER_TYPE_USER_MAIL
PR_CONTAINER_CLASS:907214878
Folder name:	IPM_SUBTREE
Folder ID:	7d495544bfdf418fa67ea1031c5b94da9b0000000000
Type:		SYNC_FOLDER_TYPE_USER_MAIL
PR_CONTAINER_CLASS:907214878

This is only a debug hack and not the solution, but I am curious as to why the conditional check does not identify the folder type.

The problem is that your public folders don’t have PR_CONTAINER_CLASS property set. Kopano support has a script which fixes the issue: https://forum.kopano.io/post/1571.

I also echoed the PR_CONTAINER_CLASS in this output, not sure if that is helpful.

PR_CONTAINER_CLASS is just a property name with value 907214878 or 0x3613001E. Fortunately I’m able to see the post you’ve deleted and saw the “Undefined offset: 907214878” warnings you’ve got which helped to figure out what’s going on.

Manfred

crankshaft

@Manfred - thanks so much.

OK, the folder was created by using the -C option of dagent, as what I need to do (same as with zarafa 7) is to forward certain email addresses (not associated with a user) to public folders.

If I delete the folders and then add them back using webapp, then the folder is listed in the listfolders.php.

So this is from postfix master.cf

kopano-public  unix  -       n       n       -       10       pipe
  flags=DORX user=kopano argv=/usr/sbin/kopano-dagent -P ${nexthop} -C vmail

As you can see it will attempt to forward email addresses where transport is set to “kopano-public” to public folders using dagent and if the folder does not exist then it will create it.

Unless these public folders are available to our MS outlook users, then kopano can no longer be used, as these public folders contain support emails from our customers, one folder per customer, and are read by everyone.

This setup has been working fine using zarafa 7.1 since 2012, and I would like to migrate to the latest stable version of kopano hence these issues.

Is it possible to pass an argument to dagent to add the PR_CONTAINER_CLASS when it creates the folders ? - I don’t see any option in the dagent --help that might help with this ?

fbartels

Hi @crankshaft,

@crankshaft said in Adding a shared folder & getting the folder ID:

As you can see it will attempt to forward email addresses where transport is set to “kopano-public” to public folders using dagent and if the folder does not exist then it will create it.

Can you get in contact with our support so that they can reproduce the issue and create a ticket for it? Thanks

@crankshaft said in Adding a shared folder & getting the folder ID:

This setup has been working fine using zarafa 7.1 since 2012

We have since back then moved away from Outlook being our primary client (which was also signaled with the name change). Nowadays our primary client is WebApp (accompanied by our DeskApp for users that want a more desktop application feel). In these applications the described workflow should not post a problem.

On the other hand with Outlook you cannot have mail delivered into dynamically created folders and have them directly show up for the user. Primarily because users have to actively add these folders to their client.