Dear cmis-api maintainers,

I have been experiencing problems with the cmis_field submodule. When having multiple values (Number of Values e.g. unlimited) per cmis_field, the file picker in the node edit form will always overwrite all former values, as opposed to just the value of a single "CMIS File". Hence you cannot attach multiple CMIS Links to a single node.

Currently the CMIS Browser used in CMIS Fields is using a Javascript Popup and some Javascript in the cmis_field.js which solely relies on the class name used for the CMIS form fields.

I attached a patch, that resolves this issue by implementing the CMIS-Browser in a Drupal Overlay and using the Drupal Ajax Framework. It relies on a _widget id_ to be passed on opening the repository browser to make sure that Javascript-Calls will only work on the right field when the user has selected the correct CMIS-File.

Since I did not want to touch the current implementation of cmis_browser I reused parts of the theming code from it and added it to cmis_field. This is not very productive and I have seen similar implementations in cmis_views.

It would be great if one could simply reuse the functionality of cmis_browser in submodules and 3rd-party modules, currently this wasn't possible.

I hope you can integrate the changes I made and maybe, later on, merge the Drupal Overlay/Ajax Framework solution into cmis_browser (I offer my help on this).

Best regards,

Lennart

CommentFileSizeAuthor
#14 cmis-add_multifield_support-2122905-7.x.patch2.39 KBsouheil.mbarki
#11 fix-cmis-field-browser.patch14.29 KBLCM
#3 fix-cmis-field-browser.patch14.92 KBLCM
fix-cmis-field-browser.patch14.5 KBLCM

Comments

LCM’s picture

LCM commented

To avoid problems like these: https://drupal.org/node/2053839

I encoded the objectId in Drupals URLs via base64 and decoded it before sending it to the CMIS-Endpoint. It seems that especially Alfresco seemed to use the format:

workspace://SpacesStore/

which breaks Drupal's URL routing. Base64 is not nice but should be compatible with every kind of content CMIS-vendors put into their objectId.

The cmis_field browser now just uses these IDs and avoids paths. This way one can avoid having to manually parse arguments from the request as currently done in: cmis_browser.utils.inc -> _cmis_browser_content_object_from_request.

I hope this clarifies the changes.

LCM’s picture

LCM commented

Another thing I just realized is,
I am not using the Overlay by Drupal but relying on the jQuery.ui Dialog which is included in cmis_views.

Sorry, I'll have to update the patch to make it work without running cmis_views.

This still seems to be a better solution than opening a _real_ browser window via Javascript.

Best regards,

Lennart

LCM’s picture

LCM commented
StatusFileSize
new fix-cmis-field-browser.patch14.92 KB

Here's the updated patch which includes the ui.dialog js for correctly displaying the file browser dialog.

ellishettinga’s picture

ellishettinga commented

Unfortunately this problem still exists in version 1.6

$('.edit-field-cmis-field', window.opener.document).val(cmisname);
$('.edit-field-cmis-path', window.opener.document).val(cmispath);

replaces all CMIS fields in a node with the same value

LCM’s picture

LCM commented

Unfortunately this problem still exists in version 1.6

@ellishettinga

Yes, as the 1.6 Update just maintains compatibility with Alfresco Community Edition version 4.

My changes are a bit more drastical and I am unsure if they will be merged into the mainstream.

Until then you will have to apply the attached patch https://drupal.org/files/fix-cmis-field-browser_0.patch to your local version of the CMIS-Module in order to get a File Browser that does _not_ replace all fields on a node.

This is far from perfect and I'd love to have a working solution inside the mainline of the cmis module.

IanNorton’s picture

IanNorton commented

Hi Lennart,

Thanks very much for the work on this, I'll review and get it updated.

CMIS Broswer certainly needs a rewrite to allow it to be re-useable, if you're in a position to be able to help with that it would be great.

Regards,

Ian

IanNorton’s picture

IanNorton commented

I'm having problems applying that patch - could you post a git generated one?

Also - just interested in what it was generated by?

LCM’s picture

LCM commented

Um, it was generated via

git diff -p commit-sha^! > patchfile.patch

so I am unsure how this could be different from what you would expect.

Best regards,

Lennart

Edit:

If you are having problems regarding patch not finding the right files, maybe it is because the patched files are prefixed with on directory-level.

So it should be

patch -p 1 < patchfile.patch

LCM’s picture

LCM commented

Hi Ian,

regarding help on a rewrite and integration of the fixes I can supply I'll see if I have the capacity to work on it in the next three weeks.

As we are migrating multiple sites to Drupal and Alfresco this module will play a core role in our projects, so it is in our interest to not rely on our own fork of the mainline.

At first I would like to split the work into separate parts.

From what I have changed in the module this will boil down to these areas of work:

* decouple Ajax Repository-Browsing from implementation specific object ids (my current solution uses base64 encoded object ids which is safe to use in Drupal's routing)
* get rid of the JS popup window and the client side JS files unless needed. My current solution does not need cmis_field.js anymore which is where the problems arise
* figure out the best way to track the initiating form element through the _dialog_ to only replace values on the correct form field (currently form initiation carries the widget-id within the url and throughout the cmis repository navigation, far from perfect but I have no other solution up to now).
* documentation on how to extend cmis api module and make use of the _new_ browser implementation (CMIS Views is one of them)

These areas are interconnected so I am unsure if one can separate the work.

If you see problems or have additions to the list, please let me know.

Kindly,

Lennart

IanNorton’s picture

IanNorton commented

That's as I was trying

patch -p 1 < fix-cmis-field-browser_0.patch

I see:

patch: **** malformed patch at line 7: {+<?php+}

The parenthesis don't seem like a standard git patch

LCM’s picture

LCM commented
Issue summary: View changes
StatusFileSize
new fix-cmis-field-browser.patch14.29 KB

Um, sorry, I created the patch using my own customized git diff (using word-diff option which produces this kind of output). I attached the standard one which should be working.

IanNorton’s picture

IanNorton commented

Hi Lennart,

Just got the chance to have a look at this, it's looking nice. I get an error if I don't specify a root directory.

I think once that's fixed it's ready to roll into the 1.x and 2.x branches

LCM’s picture

LCM commented

Hi Ian,

I am having problems identifying the best way to handle the situation of a missing root directory.

In `cmis_browser.utils.inc:23` there's a fallback chain implemented for the root directory, though I am unsure how to move this kind of fallback handling into cmis_field.

What would be the best way to handle the situation, as one must expect that even the sitewide browser root directory may not be set.

Best regards,

Lennart

souheil.mbarki’s picture

souheil.mbarki commented
StatusFileSize
new cmis-add_multifield_support-2122905-7.x.patch2.39 KB

Here's a patch that resolve multiple field cmis bug

ainsofs’s picture

ainsofs commented

Does this patch work for anyone? D8 also has the same issue https://www.drupal.org/project/cmis/issues/3167229