[quote user="Brian Fluet"]You are correct.  I did not test it with a Tray/Folder structure. Could you live with a flat structure and use prefixes in folder names? [/quote]

Now we understand us [:D] I assume that all subfolder structures, also of the additional added mailboxes, are being saved in user's own main hierarch file (user Pmail configuration files). That's why every single user is able to create it's own substructure for sorting the predefined (fix) mail folders into this own substructure which could differ from user to user. This could be understand as a feature [;)]

[quote user="Brian Fluet"]BTW, I hope you had an epiphany while sleeping.  I love when that happens.  Too bad it doesn't happen very often.
[/quote]

 I had to translate the term "epiphany" first. Never heard/used this word before. So I can learn every day. I try to remember this.  Nevertheless the epiphany stayed away. That's why I have opened a concurent thread regarding the direct delivery of Mercury into one public folder ( http://community.pmail.com/forums/thread/43370.aspx ). Accoring to the Mercury manual this should work.

But it seems we are alone in the dark, Brian. But we don't surrender.

Edit: Good Morning Brian, the Mercury delivery of new mails into a user defined public folder is solved. Please follow the a.m. link to the other thread if interested in.

Hi,

We are looking for an opportunity for simultaneous access of different local users to one local Pmail account. Presently we are using the standard installation (latest releases) of Pmail in connection with Mercury which works fine so far. But as soon as one user has access to an user account, this account is locked for any other user.

Presently I'm testing a solution with public folders (thanks for the hint to Brian). But it seems this is a little bit fishy (http://community.pmail.com/forums/thread/43320.aspx) and I'm not sure wheather this is the solution we are looking for.

Now I found another menu entry: Extra > IMAP Profile. Is it possible to additionally add an IMAP profile to another local user account (Mercury IMAP Server is running at the local LAN Server) while Pmail is still connected to the normal user account (standard user account assigned by Pmail start option -i user.) Finally that means that every user starts always its standard user mail account and additionally an IMAP Profile to a public local mail account where other guys are also working on.

Mercury I should be able to handle simultaneous account accesses by different users. The manual says:

"MercuryI allows simultaneous connections to the same mailbox: when simultaneous connections exist to the same mailbox only the first will typically incur any memory overhead - the other connections are essentially "free". During normal operation, Mercury I may consume significant amounts of disk space in the Windows temporary directory, so make sure that plenty (at least 100MB) is always available."

Has anybody experiences in this regard?

Just tried to connect to an additional IMAP account (simultaneously to the established standard Pmail - Mercury Connection). But it seems it doesn't work. I'm not able to connect "The IMAP Server returns an error message" was the one and only message I get back. It's a pity.

Mercury sets a lock file (MAILBOXM.LCK) during IMAP access which I assume causes the error on a simultaneous connection attempt.

This is clear, Brian. But I thought the lock is set to a mailbox and when I connect to another mailbox simultaneously this would work. (I'm also able to connect to public folders while I'm still connected to my own user mailbox)

We know that public folders work differently but what surprises me is that you can connect to a mailbox using the 'Add mailbox to list' function even when the local user is connected to it.  I have just tested opening the same message in both and they open just fine.  Additional testing shows message manipulation in one is reflected in the other provided the folder is refreshed (closed then opened).  The only thing that caused a problem in my brief test was changes at the folder level.  Adds and deletes of folders by the local user is not reflected in the added mailbox until the mailbox is refreshed.  Adds/deletes by the added mailbox do not show up for the local user until Pegasus Mail is restarted.

I think there is a little missunderstanding between us. I don't want to add the same (own) mailbox another time. Further "Add mailbox to" adds another standard Pmail/Mercury Mailbox to my mailbox tree in Peg with the same restrictions which I want to avoid.

Rather I would like to connect to ANOTHER local account via MercuryI (IMAP Server). Therefore I don't use "Add mailbox to" from the Folder menu but "IMAP Profile" from the Extras (German Version) menu. This is also not disabled. The idea was to additionally connect to an IMAP Server where different users can do the same with simultaneous access to that (IMAP) account. But connecting to the Mercury IMAP Server (while still connected to my own mailbox) returns the error message.

Nevertheless a small success at the public folder front line: To avoid the permanent expanded view of all public folders (we need about 40 folders here) under the public folder tree, you have to create subfolders. If you collaps those subfolders, they keep collapsed after a Peg restart, too. It seems that only the main folders of a public folder tree structure will be expanded every time you restart Peg.

Keep on testing 

Cheers

Joerg

There are two reason I thought of the 'Add mailbox to list' function:

1.  The mailbox can be added only by users who need access to it rather than showing up in every users folder list. 

2.  Behaviour is similar to working in your own mailbox.

[quote user="Brian Fluet"]

There are two reason I thought of the 'Add mailbox to list' function:

1.  The mailbox can be added only by users who need access to it rather than showing up in every users folder list. [/quote]

That would be good but collapsed public folders would be acceptable, too. But I didn't solve the problem with the Mercury delivery of new mails into one of the public folders. This would be my task of the next days.

[quote user="Brian Fluet"] 

2.  Behaviour is similar to working in your own mailbox.[/quote]

But the same Peg behaviour is not sufficient enough because of the access limitation. An IMAP server often grants simultaneous accesses of different users to one account. That's why I tried to connect via MercuryI. But it seems it doesn't work if Peg is already connected.

Finally I have the opinion to install an additional mail client like Thunderbird which connects to the "public account" via MercuryI. Of cource this is not so convenient for the users if they have to start another mail client for the access to the public account beside their standard Peg client. Will see... 

Greetings

Joerg 

I wonder if there remains misunderstanding because the added mailbox approach appears to solve the problem of concurrent access to the same mailbox by multiple users.  It also solves the problem of being visible to all user.  Finally, the added mailbox can be an actual user mailbox or a directory that you feed from Mercury.

That said, I agree that IMAP would be a better way to go if you can get it to work.

[quote user="Brian Fluet"]

I wonder if there remains misunderstanding because the added mailbox approach appears to solve the problem of concurrent access to the same mailbox by multiple users.  It also solves the problem of being visible to all user.  [/quote]

And I'm wondering that a second standard mailbox connection is showing another behaviour regarding the user accessability than the first (user's own) mailbox. Don't you get any error messages from Peg that the second mailbox is locked when trying to access to by different users? I have to permanently add this second (public) mailbox to approximately 4 users. That means 4 users are connecting on their Peg start with this public account (additionally to their own account). And you say that works?

Sorry, I didn't realize this from your previous posts. This would be of course my favorite solution. Now I'm at home, but tomorrow I will test this firstly.

Greetings

Joerg

[quote user="Joerg"]And I'm wondering that a second standard mailbox connection is showing

another behaviour regarding the user accessability than the first

(user's own) mailbox. Don't you get any error messages from Peg that the

second mailbox is locked when trying to access to by different users? I

have to permanently add this second (public) mailbox to approximately 4

users. That means 4 users are connecting on their Peg start with this

public account (additionally to their own account). And you say that

works?

Sorry, I didn't realize this from your previous posts. This would be of course my favorite solution. Now I'm at home, but tomorrow I will test this firstly.[/quote]

I was very surprised myself.  My test was to start a second instance of Pegasus Mail on my machine and connent as a different Peg user.  I then attached that mailbox to my user and ran some test.  The mailbox I tested from would have been easy to restore in the case of corruption but I saw no ill effects.  That is not to say that there won't be any.  We both know of the dire warnings about concurrent access to a mailbox and I can certainly see how hierarch.pm, state.pmj, and folstate.pm would be affected but maybe the mailstore is less susceptible.  I assume a reindex would never be triggered when as an added mailbox but don't know what would happen if a reindex occurred while someone else was connected via the added mailbox.  Lots of testing needed my friend.

[quote user="Brian Fluet"]My test was to start a second instance of Pegasus Mail on my machine and connect as a different Peg user. [/quote]

I would like to carry out some tests now. In past I used different computers because I'm not able to start two different instances with different user logins of Peg on one machine. Now you wrote that this is possible.

If I try to start Peg a second time on my machine, the already running Peg window is being shown only.

Add the -MS switch to the command line.  eg: H:\Pmail\winpm-32.exe -A -MS -I user -ID identity1

Know that the instance that is started last is the one that responds to mailto links.

I know, I know "read the fucking manual". I'm sorry Brian, but writing a post is so much easier than looking for answers by myself. [:$]

I come through when discovering any news in this regard.

Thanks

Joerg

Experience 1:

If user 1 creates yellow subfolders (no mail folder) within the new added account, the yellow folder structure will not be shown when user 2 has opened this additional account. It seems folder structures will be saved in user's own hirarch file and not handed over to user 2 hirarch file.

This is not so good. We are supporting different shipping companies with a lot of ships. One yellow subfolder has to be created for each ship where the mailfolders for different tasks are arranged thereunder.

Changes at the folder level is an issue I mentioned previously.  In my test, the changes eventually show up for all users but require a refresh when being accessed as an added mailbox and a restart when being accessed by the mailbox user.

It will be a challenge while the folder structure evolves but should be less of a problem once the folder structure in more static.  Once you get the folder level behavior figured out you should be able to provide guidance to users.  Hopefully it will only require a refresh on a regular basis.

Folder Structures and their actuality does not only depends on a Peg refresh.

If you have e.g. a "user 1" and "user 2" with their own accounts. Additionally you create a "user public" and an account "public". When logged in as "user Public" to the account "public" you could create a folder structure which will be shown when other users are connecting to that box.

But in case user 1 has additionally connected to box "public" and he is changing the folder structure for box "public", nobody else will see those changes! The changed folder structure is being saved in his (user 1) hierarch file only! User 2 or User Public can refresh and restart Peg as much as they want - without getting the changed structure made by user 1 for box "public". But this concerns to yellow subfolders only and not to standard mail folders (envelope). They could, of course, be renamed and appear with all users after a refresh/restart.

Sorry!  I thought you were referring to added mailboxes.

[quote user="Brian Fluet"]Sorry!  I thought you were referring to added mailboxes.[/quote]

Yes, I'm refering to.

User 1 has added an additional mailbox "public". User 2 has also added the same additional mailbox "public" to his mailbox tree. But when user 1 is creating/changing anything on the yellow subfolder structure (of the additionally added public mailbox), user 2 will never see this, also not after a restart. He only see all simple mailfolders in a row but without yellow subfolder structure.

Every user has to create the same subfolder structure in the additionally added public mailbox. Otherwise he see only the plain mail folders in a row without any sub structure.