I am unable to login on that page. So I could not see the demo.
However, you are right that while checking-in, the user must have to either
a) necessarily update the file, or
b) cancel check-in if he decides to update the file later, or
c) cancel the check-out if he decides that there was no need of checking out the file.
Following (a) should update the version and remove the check-out status.
Following (b) leaves the file in the same state: same version and checked-out
Following (c) should also leave the the file in the older version but should cancel the checked-out state.
Please comment. I can implement this, I guess.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can you elaborate (maybe give a real life example) on the need for both action b and C? If b) cancel check-in, shouldn't the file revert back to original state? Both should keep the same, unchanged version number.
Should a use be allowed to keep a file checked out even though they don't want to update it now? Couldn't they just choose not to check-in when they're not ready to update the file, rather than b) canceling their check-in to choose to update file later.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-08-13
Logged In: YES
user_id=1613613
Originator: NO
caitlyntw said: Can you elaborate (maybe give a real life example) on the need for both
action b and C? If b) cancel check-in, shouldn't the file revert back to
original state? Both should keep the same, unchanged version number.
my response: Checking-out a file is like putting a signboard for other users which says: "Changes under progress" or, maybe "Changes being considered". Thus cancelling a check-in implies that you do not want to perform this activity now. Perhaps, when you were going to checkin you were reminded at the last moment of some more changes needed in the file. So you would cancel check-in at that time and perform the activity later. The same is applicable when you would have chosen to check-in by mistake. However, after having checked out a file for some intended changes which you later realiza are not to be made, you would like to cancel the check-out operation. This would not change the version number and other users would now that the file's contents are uptodate after all
caitlyntw said: Couldn't they just choose not to check-in when
they're not ready to update the file, rather than b) canceling their
check-in to choose to update file later.
my response: yes, the user could do that. Probably, he should do that. But consider a case where i have uploaded a file which needs changes and I need the users to know to go by the contents only after I have made the changes which might take a couple of days. Rather than delete the file (which is clearly inappropriate) or hide it by altering permissions (which would deny the legitimate right to view the existing version), I would check-out and wait to check-in until all the changes have been made. Thus, the users can continue to peruse the existing file while being aware of the fact that the "work is in progress".
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ok I can see where you're coming from. We've modified our OWL so that check out and check in records are in the file log as well. That's why we wouldn't need the cancel check-in option.
However I'm sure a lot of people would be thrilled if you can code this feature into Owl as you've described.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is there any update (from development) on the status of this feature request? I requested it more than a year ago (1582620), and Caityln about 5 months ago. But no word.
Thanks
Jonathna
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry. Please ignore that comment I just posted. Just now saw all the discussion at the lower part of this page.
So where did this feature request get to? Is it going to be implemented?
Thanks. Jonathan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=1613613
Originator: NO
I am unable to login on that page. So I could not see the demo.
However, you are right that while checking-in, the user must have to either
a) necessarily update the file, or
b) cancel check-in if he decides to update the file later, or
c) cancel the check-out if he decides that there was no need of checking out the file.
Following (a) should update the version and remove the check-out status.
Following (b) leaves the file in the same state: same version and checked-out
Following (c) should also leave the the file in the older version but should cancel the checked-out state.
Please comment. I can implement this, I guess.
Logged In: YES
user_id=1776158
Originator: YES
You can also try the demo here: http://www.openkm.com/OpenKM/ (passwords at the bottom)
Can you elaborate (maybe give a real life example) on the need for both action b and C? If b) cancel check-in, shouldn't the file revert back to original state? Both should keep the same, unchanged version number.
Should a use be allowed to keep a file checked out even though they don't want to update it now? Couldn't they just choose not to check-in when they're not ready to update the file, rather than b) canceling their check-in to choose to update file later.
Logged In: YES
user_id=1613613
Originator: NO
caitlyntw said: Can you elaborate (maybe give a real life example) on the need for both
action b and C? If b) cancel check-in, shouldn't the file revert back to
original state? Both should keep the same, unchanged version number.
my response: Checking-out a file is like putting a signboard for other users which says: "Changes under progress" or, maybe "Changes being considered". Thus cancelling a check-in implies that you do not want to perform this activity now. Perhaps, when you were going to checkin you were reminded at the last moment of some more changes needed in the file. So you would cancel check-in at that time and perform the activity later. The same is applicable when you would have chosen to check-in by mistake. However, after having checked out a file for some intended changes which you later realiza are not to be made, you would like to cancel the check-out operation. This would not change the version number and other users would now that the file's contents are uptodate after all
caitlyntw said: Couldn't they just choose not to check-in when
they're not ready to update the file, rather than b) canceling their
check-in to choose to update file later.
my response: yes, the user could do that. Probably, he should do that. But consider a case where i have uploaded a file which needs changes and I need the users to know to go by the contents only after I have made the changes which might take a couple of days. Rather than delete the file (which is clearly inappropriate) or hide it by altering permissions (which would deny the legitimate right to view the existing version), I would check-out and wait to check-in until all the changes have been made. Thus, the users can continue to peruse the existing file while being aware of the fact that the "work is in progress".
Logged In: YES
user_id=1776158
Originator: YES
ok I can see where you're coming from. We've modified our OWL so that check out and check in records are in the file log as well. That's why we wouldn't need the cancel check-in option.
However I'm sure a lot of people would be thrilled if you can code this feature into Owl as you've described.
Logged In: YES
user_id=48654
Originator: NO
Is there any update (from development) on the status of this feature request? I requested it more than a year ago (1582620), and Caityln about 5 months ago. But no word.
Thanks
Jonathna
Logged In: YES
user_id=48654
Originator: NO
Sorry. Please ignore that comment I just posted. Just now saw all the discussion at the lower part of this page.
So where did this feature request get to? Is it going to be implemented?
Thanks. Jonathan