• Check-in with other names

  • Help us to improve OpenKM! Be part of the Open Source Community.
Help us to improve OpenKM! Be part of the Open Source Community.
Forum rules: Please, before asking something see the documentation wiki or use the forum search function.
 #7382  by artofnois
 
At check-in, if the file name does not match (with chdk-out filename) gives me the opportunity to do the check-in and changed his name and that the note put the actual file name. So I can have locally several versions (drafts) but only one published in Openkm and know wich version is publised.

LOCAL________|OpwenKM Doc_|Checked-in by_|NOTE
name_doc_01__|Name_Doc____|user1________|Original:name_doc_01
copy_name_doc|Name_Doc____|user2________|Original:copy_name_do
name_doc_20__|Name_Doc____|user1________|Original:name_doc_20
 #7393  by jllort
 
I want understanding it better.

We could develop easilly a checkbox for disabling these feature ( check name at check-in), but I want to understanding the scenario.

First imagine we're working on physical papers, not electronic. Some pager goes among user tables, the user works on it and sends to other table other user takes it and works on it. That's the real world case, that we emulating in OpenKM with electronic documents. Electronic document is like a a token that is traveling to several users that make changes, only one user at same time can edit document, but the document can not change.

Change file name is so dangerous, for example .doc and for some error you uploading .txt file ... that might never happens ( reason why in version 4.1 we started with feature name restriction ).

Explain me better your case, and why is needed to you uploading a new version with different name ( that's not the same than uploading a filename and then increment some number etc... that could be automatic procedure .... but it's not the idea you're proposing ).

The idea is all the draft are too in OpenKM -> that the reason why there's historical document, and you can return to older versions.
 #7448  by artofnois
 
The scenario for me and my environment is that nearly all the documents we created are in a electonic way (.doc, .xls, .pdf) and shared, updated, downloaded, corrected and appended for several people in a working group. I think this is the main difference: all of us are capable to change the original document.
Theese are documents not only for reading but for active changing.

And of couse, we also have others like manuals, procedures, etc that we share in a "Read-only" way.
 #7482  by jllort
 
The "major" idea on all DMS is that only one user can take the ( token ) document to change, that's one of the major goals of any DMS, it must not be changed for severals users at same time, then it'll not be a consistent content. That's the idea ! the main idea ! If some user wants to change some document and is edited by other must told him, to cancel editing or uploading the changes and then continue changing ... that's the basis of any DMS.

In your scenario or others, must be some rules ... DMS is application that limits these rules ... and you must take advantage on it. The goal you follow is consolidate editing ( on a simply way ... only one user can edit at same time the document ).

If you're on a different scenario ... then you might create several documents at same time, edit ( with same logic ) and via some workflow ... try somebody integrate it ... if you've not thinking on this direction you'll got a several documents with severals versions all incompleted.
 #8363  by mahamad
 
Hi,

I have a similar question.

At the moment, we are using openKM as our document management service for an application we are building. So all files, are being stored in openkm rather than working with the application file system. We decided to do this, to allow us to leverage the power of openkm in terms of:
* Securing the files more easily
* Allowing easy maintenance of files straight from the openKM view
* Version Control
* easy search facility

Now, let's say that a user uploads his profile photo, we keep this information in openkm and upload it through a web service. This works all fine and dandy, but our problem lies in that, what happens if once a user uploaded a file called profile_photo.JPG and the next time, he uploads a photo called profile_photo.PNG, the file still serves the same purpose although it's still a different picture. I'd like to be able to track the version control for this file, to know that this person has changed his profile photo twice.

Is there anyway of doing this in OpenKM? Is there a workaround maybe?

Regards

Moe
 #8379  by jllort
 
You must test before trying to uploading a document if the document exist ( by webservices ) if the document exist must execute a checkout, and a checkin in case not exist must execute the normal create, that's the idea.
 #8384  by pavila
 
mahamad wrote:Now, let's say that a user uploads his profile photo, we keep this information in openkm and upload it through a web service. This works all fine and dandy, but our problem lies in that, what happens if once a user uploaded a file called profile_photo.JPG and the next time, he uploads a photo called profile_photo.PNG, the file still serves the same purpose although it's still a different picture. I'd like to be able to track the version control for this file, to know that this person has changed his profile photo twice.

Is there anyway of doing this in OpenKM? Is there a workaround maybe?
From a DMS, profile_photo.JPG and profile_photo.PNG are two different files: same name but different extension. The same when you store these files in your local filesystem. If you want, you can make a relation between both files using the stapling extension, for example.

About Us

OpenKM is part of the management software. A management software is a program that facilitates the accomplishment of administrative tasks. OpenKM is a document management system that allows you to manage business content and workflow in a more efficient way. Document managers guarantee data protection by establishing information security for business content.