Kaufman Joe Bell Laboratories Inc No longer there

Steve, yeah, I found that setting and was glad of it (I tihnk it is silly they make the more immediate save be the default -- "By user action" should be the default, IMO).

But I am still concerned that someone will stamp and save a document and then only upon returning to the result list realize they have stamped the wrong document. We all make mistakes like that at one point or another. In those cases, someone will have to go through a fair number of hoops to get the erroneous stamp removed.

Thanks,

Joe Kaufman

Joe,

DocuWare Desktop is pretty much already a service, and you can set up what is called an "import job" to pull in documents from a watched folder.

Install all the DocuWare Desktop tools and you should have an "Import" tab in the DocuWare desktop apps. Read the help on it and set up a job and you should be ready to go.

Thanks,

Joe Kaufman

Casey,

Thanks for the response and the idea on how to remove a stamp. Our stamp is large enough that most times it won't be in a clear area such that we can use the "virtual white-out" technique you describe. What you say about stamps being a bit more important than a random annotation is a good point, though if anyone has document editing capabilities it is very simple to print the page without annotations to a PDF file and then delete and re-insert the page...

I'd still love to hear from DW support about the permissions, too. If we add more stamps and need to control their visibility it is going to be a real pain to do that by username as turnaround in departments occurs.

Thanks,

Joe Kaufman

Hey all,

I have two questions about Stamps.

1. Permissions. It looks like you can assign Profiles to a stamp, or assign access by User. This is not very flexible. If I want to give access to a "VOID" stamp, say, just for Accounting, I want to be able to do that. And I kept security simple such that I assign Groups to Roles, and that is where we stop -- we don't really use Profiles for much. So, why can't I assign permissions to a stamp by Role instead of by Profile or User. Every other permission I have encounted in DocuWare has the ability to assign permissions by Role, which is why I never took security to the Profile level (and I don't want to). Please advise.
2. Removing a stamp. What if a user stamps and saves a document in error? I thought the stamp would be treated as an annotation such that it could be selected and removed (and it is treated as an annotation when it comes to printing), but that does not appear to be the case. I cannot select a stamp on a document even if I have not flattened it, and there does not appear to be any other stamp removal funcitonality. If someone made a mistake, we would have to save the page as a PDF without annotations and then replace the page via editing. That seems cumbersome. Any advice on removing a stamp placed in error?

Thanks,
Joe Kaufman

Phil,

Were you able to find anything out on this matter, including if something will change in a future version (if it hasn't already)?

Thanks,

Joe Kaufman

Benoit,

I have Fiddler up and running and it is showing me traffic to our DocuWare server (6.11 running on-premise, straight HTTP), but I am not seeing any XML. The XML pane is always empty, and instead, JSON is populated.

How are you getting the web client to communicate via XML when doing something like changing an index field? All I see is JSON...

Thanks,

Joe Kaufman

Benoit,

That is a great tip. I recall using something to try to see what the web client was doing, but now I cannot remember the tool. I will take a look at Fiddler.

Thanks,

Joe Kaufman

Konrad,

I have found XML construction to be a bit finickywhen I am using Visual Foxpro and the ServerXMLHTTP request object. In some XML I have that looks similar to yours (defining "Field" values), I use these two lines as my XML headers:

<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type="text/xsl" href="/DocuWare/Platform/Content/standard.xslt"?>

Let's see if I have a longer <Document> example...here's one:

<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type="text/xsl" href="/DocuWare/Platform/Content/standard.xslt"?>
<Document xmlns:s="http://dev.docuware.com/schema/public/services" xmlns="http://dev.docuware.com/schema/public/services/platform">
    <Fields>
        <Field FieldName="{fieldname}">
            <{fieldtype}>{value}</{fieldtype}>
        </Field>
    </Fields>
</Document>

It looks like you might be lacking the second line in the XML headers, the one that establishes stylesheet type?

If you are more familiar/comfortable with JSON, you might try that. It seems easier to construct, but I did not have much luck with it. But maybe I was not setting my request headers appropriately. JSON seems to be the thing a lot of web-based services are leaning towards, tohugh DocuWare still stores a LOT of stuff as XML in their back-end database (like embedded properties).

Hope this helps. Getting Playform Service stuff working in anything other than .NET has always been a struggle from what I see on the forums.

Thanks,

Joe Kaufman

Carolynn,

I wrote an expansive document on "power searching" involving wildcards, operators, and even arithmetic operators like "<" and ">".

I can't post documents, though, and do not want to publicly post the document and link it here.

If you are on LinkedIn (or something) can you let me know how to reach you there? We can exchange email addresses at that point and I can send you the document. It might be of help to you...

Thanks,

Joe Kaufman

Phil,

It would definitely be nice to know the outcome of this. In my opinion, if two out of three indexing spots hide the functionality on multi-cabinet results (even if the selected document is from the "primary" search dialog), then it should be hidden everywhere. The fact that it works for the primary but not for the others makes it all the more confusing, and just shouldn't be allowed now that we understand how a multi-cabinet result list is really sort of a nebulous. user-driven concept. To keep security intact and prevent confusion, it would be better if changing such indexes was not allowed across the board.

Alternately, if multi-cabinet searches could be created at the configuration level (not user by user), then dialogs could be created and assigned privileges and everything would work as it should. However, it appears to be pretty ingrained (especially with regard to Platform SDK resource entry points) that dialogs are under a single file cabinet. My guess is that configuring multi-cabinet searches as persistent dialogs is not in the cards for a loooong time.

Thanks,

Joe Kaufman