nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Cannot set the Created Date field using CreateDocument service

Stephane_Cote

Salut

The CreatedDate and the ModifiedDate fields are set in the Attachment object. I use the CreateDocument service provided by the Document Management client.

No matter what date value I put in those fields it is always being overight at the service level with the current time stamp.

Is there a setting that i'm missing for it to alow these dates to be modified...if so where is it.

Merci

Stef

Find more posts tagged with

Comments

Stephane_Cote

Well got my anwser reading a bunch of old post...this cannot be done...this is not very good for clients who want to keep historical dates for audit when migrating...

I guess the only sollution is to long the information and so a seperate sql call on the table.

The Attachment object should now allow these properties to be set and should then only be read only...would make it easier for coders to understand.

Stef

Chris Meyer

Hi Stephane: This could be done with a LAPI call (UpdateObjectInfo) after uploading the document with Web Services.

Ferdinand Prantl

If only the audit from the original system should be preserved, it is possible to register and add custom audit entries. I'm not sure if there's a WS method for it, though. AGA uses this feature to transfer the SharePoint audit log when a document is archived.

If the original creation date should be shown in a column, it doesn't come cheap. It can be stored in a category attribute and put to a column but it is a question if there's a real benefit to justify it.

The creation and last modification dates are system properties which reflect what has happened with the object in Livelink. You'll have easier maintenance of your installation if you find a solution which doesn't need tampering with them.

Dave_Kinchlea

I'd argue that Migrations should actually have the createdate/modifydate as CS is doing, those represent the action of first storing the migrated content within the new system and, because they are the same, proof that they were not altered after being migrated. I would include in the migration a category that described the migrated from document (at least the two times and some sort of data checksum/hash code validating the contents are the same from both systems).

I do understand how, from a business perspective, this might seem like the wrong information but my feeling is that if it is possible to alter this information then there is no guarantee of data integrity in the new system after the migration. Though there would be an audit trail of some sort for any call, it may not be sufficiently detailed to catch incorrect use.

Unfortunately, as my friend Chris Meyers points out, some old LAPI calls do allow this (ab)use of controlled content, so perhaps there is a way if you do want to continue down that path but I believe LAPI is officially deprecated now so hopefully that loophole is closed.

sıɹɥɔ

Hi Stephane,

The values that you're specifying are actually not being overwritten; they are stored and available for later retrieval.

Just to review, there are 3 creation dates: the date that the Document is created; the date that the Version is created; the date of the file (Attachment).

Content Server maintains the Document date and Version date, setting them to the value of the system clock at the time of the item's creation. The file date however, the date that you're setting for the Attachment, is under your control as a web services developer providing the Attachment information.

You can see the date that you specified by opening the Specific tab of a Version that was created by your program in the browser interface to Content Server.

Hope this helps,

-chris

Vanderpoel_Rob

Hi there,

We've undertaken many imports using Object Importer and almost always the customer wants the original creation date and last modifed date retained.

With OI, setting creation date is a standard tag, and a configuration setting also allows setting the modify date. So OT's standard migration tool does allow these dates to be set.

When using web services, any business rule around modification of these dates can easily be codified into the application so that provides protection against modifying these dates inappropriately.

I would expect that, from a Records Management perspective, setting these dates to the original dates would be required for managing disposition correctly.

Also, with facets, setting the modify date creates a true reflection within the Modify Date facet.

And, of course, the date of import into Content Server is readily available via the audit trail anyway.

Cheers

Rob

Dave_Kinchlea

Reasonable people can disagree, but there is, in my mind, a big difference between the highly controlled use of OI and the "I'm just another CS client" that is CWS. One might argue that the CWS should provide such abilities to administrative users and if it did then I'd agree it was similar to OI but only similar. It still lacks one important security feature, access to the file system where the OI import script is located. That requirement (usually) limits who and what circumstances such dangerous commands can be utilized. It still seems wrong to me, it is making claims that are patently untrue, however at least it is feasible to control its use.

I don't doubt that your clients want it, what I'm arguing is that if an ordinary CS client can change those dates then it is very difficult to guarantee data integrity. The audit trails exist, things could be forensically determined, however, I'm sure you'll agree that using the audit tables for ordinary transactions is not the way to a nice, fast, CS experience. The point is that you wouldn't find out that create/modify dates had been changed by CWS because nobody (well, perhaps some do but I've never met them) nobody audits the audit trails in a way that would find that proactively, everybody will just assume the dates are correct. It isn't too difficult to envision scenarios where nefarious changes to dates could hide a truth (or speak an untruth).

This is the classic false sense of security and, for my money at least, CWS gets this right.

I do very much appreciate your modify facet argument however, and don't have a better answer than you deploy.

Dave

Stephane_Cote

A lot of great comments here so thank you so much.

- Yes in every case the client will want the original creation and modified date for proper disposition.

- I do understand that there needs to be control regarding web service for proper data integraty.

- Don't have date under the "Specific" tab so might be a configuration thing

- I'm not using OT migration (document dump; xml etc) so can't mofify does dates.

- The API way seems like a good aproach but someone mention that its deprecated and I'm not sure how much time i want to invest in it.

With all of this said.

The application that I wrote (C#) will migrate RDims to GCdocs (OT) with all proper mapping (app / owner / metadata / rights / file plan etc). On the rdims side I'm using API calls; web services on the GCdocs (OT) side. You specify what you're mgrating; break it down into blocks so it can be run on multiple machines / process. All transfers are logged into the database. As for the create and modify date; I guess I'll log the entries and do a direct sql call to update the fields.

thank you all.

Stef

eLink User

You seem like an informed person and so I am just giving this as a fair warning.

"As for the create and modify date; Iguess I'll log the entries and do a direct sql call to update the fields."

As far as my knowledge and experience goes I have always resisted the urge to touch the livelink database.This is because when you seemingly think that all OT is changing is doing something on that field several other things (events,callbacks or even things) may not get fired so you will see livelink code do stack crawls and stuff like that which may not be all apparent until it is in a mess.

Christopher Meyer said that the old LAPI methods allow this so why could you not use it? Or if you are a oscript programmer you could look at the OI code and see how they do it perhaps expose that function as a new call you can do from your client code.Or even pay OT to make it available.Even that lapi call could be traced to do what you want.

I do not want to get into why some tools from ot does it and does it not but mostly livelink resembles a file system so I would choose what windows does or unix does when you put files that you get in email. I also do not know the rules of RM as Dave and others are saying.My only intention is to tell you that as developers try not to cross that line that OT says.Surprised that David Templeton or Kyle Swidrowich is not putting their thoughts on this "direct sql update that you are gonna choose"

At least put connect logs and see which tables are getting updated when you do it with lapi or OI for the completeness

Good luck with your coding...

..Appu

I wonder how one could debug livelink if Fiddler, Wireshark and Softerra LDAP browser was not invented and not free

Stephane_Cote

Yep I'm an informed person but not afraid to listen and know when i'm probably wrong.

Good point; you never know what's going on in the backend and doing an direct sql could open up a bunch of problems....I'll find other sollutions and also look at LAPI.

Thanks for the wake up.

Stef

Stephane_Cote

I'm I right in seing that the SDK needs a 64 bit machine to be installed on...time for a new machine.

They mention to use the previous livelink version for 32 bit dev work but there SDK link is broken.

Stef