Joe Kaufman Bell Laboratories Inc Senior System Architect

The URL for updating the indexes does not look correct to me. First off, is your Organization ID really a GUID? Ours is just "1".

Next, you are not referencing a file cabinet, so I am not sure how that URL works. What I have used in the past would look more like:

https://my-site-test.docuware.cloud/DocuWare/FileCabinets/{file cabinet GUID}/Documents/{DocID}/Fields

You do not need the Account, Login, or Organization any longer because you are already authenticated. (Also, you have slashes doubled up between the site URL and "DocuWare".)

We then use XML post data for the indexes, a collection of Field nodes inside an enclosing DocumentIndexFields node. We use a POST.

My guess is that you are getting a successful result because that is the success of logging in. It is not actually trying to set the indexes because you have not told it which file cabinet you are operating on, and maybe because you are using a PUT and not a POST?

Good luck!

Thanks, Michael! 

In this case it was because we have Profiles set up on the file cabinet, and when you add a new field, it is not visible in any way under those Profiles. I was viewing the new field via the default Profile, which does display new fields by default, but I have to explicitly make the field viewable in those other more limited Profiles.

The field had already been made visible and moved to an appropriate location on all dialogs, that's why I could see it.

I actually had the same issue when adding a field to this cabinet about a year ago, but I had forgotten what I learned back then. Been a busy year.  *smile*

Thanks,

sutekh137

Hey all,

*** NEVER MIND! The file cabinet in question has some custom Profiles, and a new field needs to have various visibilities explicitly turned on. Forgot about that! ***

I just added a new field to a file cabinet, pretty standard stuff. I also moved the field to near the top on all dialogs. The field appears for me.

I am now getting reports that other people cannot see the new field. I have confirmed this on a different workstation. I have cleared browser cache on that machine and tried a different browser entirely -- the field still does not appear.

Is this a MS queuing issue? Do I need to bounce the DocuWare services on the server or something? Just bounce the web site in IIS?

There are no field-level permissions or profiles that I know of in play. Yet if I log into DocuWare (on my machine) using a different account, the new field does not appear in any dialogs where it has been made visible under that other username.

Thanks,
sutekh137

Dina,

Is a third-party custom application an option? You can use the API to gather all documents at once (as PDFs) then combine them into one PDF. We do such integrations via .NET/C# programming.

I am not sure about viewing all at once in native DocuWare. What if some documents are PDF, others are DOCX, and still others are XLSX? What would a "combined" document look like in the viewer?

If they are all PDF, though, they are relatively easy to combine by downloading all PDFs then combining them with Acrobat automation or a command-line tool such as PDFTK. A custom application could also "print" non-PDF documents to convert them to PDF and then combine.

Good luck!
Joe Kaufman

Sam,

You are most welcome!

Hope your DBA gets a nice listing back for you -- just glad someone has access to the data. Not sure what cloud folks end up doing when direct queries are required!

Thanks,
Joe Kaufman

Sam,

We are on 6.11, SQL Server, on premise. So, a query of the database gets us the information we need, at least the basic add, edit, view, and delete capabilities by user/group and file cabinet. The queries are fairly complicated, but here they are, run against the dwsystem database of your SQL Server:

For GROUP permissions:
 

SELECT G.Name AS GroupName, R.Name AS RoleName, FC.Name AS FileCabinetName, FCP.Name AS Permission
    FROM DWGroup G INNER JOIN DWGroupToRole GR ON G.gid = GR.gid
        INNER JOIN DWRoles R ON GR.rid = R.rid
        INNER JOIN DWFCProfileToRole FCPR ON R.rid = FCPR.rid
        INNER JOIN DWFCProfile FCP ON FCPR.fpid = FCP.fpid
        INNER JOIN DWFileCabinet FC ON FCP.fid = FC.fid
    WHERE G.oid = 1 AND G.type = 1 AND G.Active = 1
        AND R.type = 1 AND R.active = 1
        AND UPPER(FCP.Type) LIKE '%FCPROFILE%'
    ORDER BY G.Name, R.Name, FC.Name, FCP.Name

For USER permissions:
 

SELECT U.Name AS UserName, FC.Name AS FileCabinetName, FCP.Name AS Permission
    FROM DWUser U INNER JOIN DWFCProfileToUser FCPU ON U.uid = FCPU.Uid
        INNER JOIN DWFCProfile FCP ON FCPU.fpid = FCP.fpid
        INNER JOIN DWFileCabinet FC ON FCP.fid = FC.fid
    WHERE U.oid = 1 AND U.Active = 1
        AND UPPER(FCP.Type) LIKE '%FCPROFILE%'
    ORDER BY U.Name, FC.Name, FCP.Name

If you do not have access to the database, or if the structures have changed between 6.9 and 6.11, you may be out of luck. But these queries return a handy listing of groups and users and the permissions they have for file cabinets.

Do note that if your security setup is more convoluted (as in you use a lot of complex, custom-built Profiles) this data will probably be of less use to you. But if you keep things fairly vanilla, it generates a nice summary of what people can see.

Hope this helps!

Thanks,
Joe Kaufman
 

Pierre,

What platform are you running on? That is, do you have access to the underlying database server for DocuWare?

On version 6.11, on premise, I can go into the SQL Server database and check the fields:

DWLASTACCESSDATETIME
DWLASTACCESSUSER

and see who last viewed a document. I just viewed an old document and it updated those fields to the current date/time and my username.

Those fields also appear to be accessible via Platform SDK API queries as well as URL Integration, though I am not sure how you could expose them on a regular search dialog. What you could do is add a field of your own that uses a "Predefined entry" of "Access date" and "Access user" (short or long name). Then you could search by access date and access user. I do not think there is any other way to expose those system entries on a standard Search dialog.

Good luck!

Thanks,
Joe Kaufman
 

Simon,

Don't worry about the late response -- you came through! I got this working!

I had previously noticed that the final URL (that displays in the browser once the document comes up) shows the query "in the clear". But any time I tried to use that URL with an unfound document, it displayed a very nasty system message I did not want users to see that (and I assumed the URL just wasn't working right). But when I switched out "Document" in the URL for "Result" (like in your example), it works to display a nice screen whether a document is found or not. In other words, instead of going directly for the document, it went for the Result List.

And by utilizing displayOneDoc=True in the URL I can make the viewer appear immediately, which is ultimately what I want (this integration works with one document at a time).

This is a much more straightforward integration once one figures out the escaped characters in the URL. And it turns out our ERP system displays the DocuWare viewer right inside its own frame (it is pseudo-browser-based), so it looks much more seamless and doesn;t fire up a new browser tab for every viewed document.

Thanks so much!

Joe Kaufman

Fabian,

I really cannot thank you enough for triggering this idea -- we now have integration working via an application that serves up integration functionality via command line programs! I don't when (if ever) I would have had that idea if not for your web service comment!

Have a great weekend!

Thanks,
Joe Kaufman

Fabian,

Thanks for the response and the web service idea. We aren't exactly equipped to start writing web services, so I was hoping for a different answer. But it is what it is. 

I actually already have a WinForms application that I write little command-line snippets for, so perhaps I could use that to pass parameters to and generate a URL to execute on the client side. Same idea as a web service, just an application service. So, I appreciate you sparking the idea for that!

Thanks,
Joe Kaufman