Tickets :: Comment on [#7739] Folders tree not updated after an add (new) folder action

* Your Email Address
* Spam protection	Enter the letters below: . .\ /.__ . __ \ / >< [__) \|/ ` \/ / \[__)\__\|\__.
Comment	> Installation infos : horde-webmail-1.2 ; php-5.2.6 ; debian etch > > Tested web browsers : Mozilla firefox 2.0.0.18, IE7, Safari 3.2 for > windows (all on OS windows XP SP3) > > > > By Dimp interface, after the creation of a new folder, I don't see > the new folder dynamically added to the folders tree. > > I need to refresh the page to see the new folder in the folders tree. > > > > I remarked that this behaviour doesn't occur when I have another > virtual folder in addition to the virtual inbox. > > > > For instance, I try to create the folder "foo". > > If I have no other virtual folder but the virtual inbox, then : > > - I get the message 'The folder "foo" was successfully created'. > > But : > > - The folder "foo" doesn't appear in the folders tree. > > > > Setting the javascript debugging and using dimp/js/src produces an alert : > > with Firefox 2.0.0.18 : > > doActionComplete callback: TypeError-$(elt) has no properties > > with IE7 > > doActionComplete callback: TypeError-'null' is null or not an object > > > > Refreshing the page corrects the situation : > > - The folder "foo" appears successfully in the folders tree. > > > > So, if I have created a virtual folder by Imp interface, then when I > connect to the webmail by Dimp interface, a new created folder > dynamically appears in the folders tree without refreshing the page. > > > > I don't know if it's due to my configuration (admin config ? or user > config ?). > > > > I tried to understand and it seems to be caused by the virtual folders. > > The getFolderResponse (horde/dimp/lib/DIMP.php) result contains the > new folder in the array a but the "Virtual Folders%" in the array c > too. > > Then it makes the _folderCallback function > (horde/dimp/js/src/DimpBase.js) fails when it manages the changed > folders. And it doesn't continue managing the added folders. > > More precisely : > > _folderCallback calls > > changeFolder which calls > > deleteFolderElt sets f to null by the instruction > > var f = $(fid); (because there is no fldVirtual_Folders_) then calls > > DimpCore.removeMouseEvents(f) which wraps > > DimpBase._removeMouseEvents which fails on the instruction > > var d, id = $(elt).readAttribute('id'); with elt that is null > > > > I think that it is linked to the re-creation of the virtual folders. > After the deletion of the virtual inbox, its parent folder is empty. > So during the re-creation of the virtual inbox, its parent is marked > "changed" and it finishes to appear in the changed folders. > > > > If I am not on a wrong trail, a part of the calls is : > > with Folder as horde/imp/lib/Folder.php, Search as > horde/imp/lib/Search.php, Tree as horde/imp/lib/IMAP/Tree.php > > Folder.create calls > > Search.sessionSetup(true) which calls > > Search.createVINBOXFolder which calls > > Search.addVFolder (by the else branch of if (empty($vinbox_id)) > ) which calls > > Search._updateIMPTree(add... which calls > > Tree.insertVFolders which calls > > Tree.insert which calls > > Tree._insertElt which sets > > $this-->_eltdiff[$elt['p']]['changed'] = true; > (because its parent is empty) > > > > I tried a modification to prevent the getFolderResponse result to > contain the virtual folders in the changed folders array c. > > I modified horde/dimp/lib/DIMP.php (v1.110.2.32) : > > please see attached patch dimp_addfolder.patch. > > > > It corrects the problem : without any other virtual folders but the > virtual inbox, the creation of a new folder is dynamically added to > the folders tree with Dimp interface. > > It works on all the tested web browsers mentionned above. > > > > Moreover, during my tries, I remarked in horde/imp/lib/IMAP/Tree.php > (v 1.25.2.60), the function delete uses the instruction : > > $vfolder_base = ($id == IMPTREE_VFOLDER_LABEL); > > but shouldn't it be ? > > $vfolder_base = ($id == IMPTREE_VFOLDER_KEY); > > Because when I logged the function, it seems to be the key and not > the label that was used. > > > > Thanks for reading and help.
Attachment
Watch this ticket

Saved Queries