Protecting Archived Files from Delete at Console

[Fujilives]

We have a Fiery print server connected to a very nice Konica Minolta printer. We've been using the Archive feature in Fiery Command Workstation to preserve pre-configured jobs as a means of eliminating complex setup of some jobs and speed up reprinting when employees need documents (product manuals that get folded and stapled are one example of jobs that can get complex to print at times).

The archive utility also has the added benefit of allowing non-computer savvy & factory employees without a workstation the ability to print what they want on demand by simply walking up to the printer and using the touch screen, following step-by-step instructions we have placed on a post-board directly behind the machine.

Well... occasionally, usually once a week or so, someone will manage to delete a job from the archive when using the printer. This means I have to find the file on our network, ensure it's the latest version, reconfigure the job, wait for the job to print, then add the job back to the archive again when done. This gets to be tedious and frustrating, as it defeats much of the purpose this was set up for.

Is there a way to "protect" the archived jobs so no one can accidentally remove / delete them from the touch-screen interface connected to the printer itself? If not, is there a better solution to this problem? I keep reading about how people are using hot folders... would a hot folder (perhaps with an old machine set up as a printing kiosk) be a better solution for non-computer users to print their own documents, while ensuring they don't accidentally get deleted by people? If so, is there a guide/tutorial/reccomendations from people who have gone through similar issues I could use to help set something up that resolves this issue 'once-and-for-all'?

Thank you very much for any time you can dedicate to answering this / reading my wall of text.

[adam1991]

hmmmm. If you're archiving on the Fiery itself, you risk losing absolutely everything. One should never, EVER archive on the Fiery itself without carefully evaluating the risks vs reward.

Archive instead to a remote location--say, a server. You know, you could archive to a server, then have something running on that server to automatically and invisibly copy that archive folder to somewhere else for backup/restore purposes. Should someone delete something from the visible archive list, you can easily go to your backup and retrieve it and put it back.

Archive is very valuable, for all the reasons you outline. Leaving archives on the server is just plain bad. It's not a matter of if the server needs reloaded from scratch, it's a matter of when.

[Fujilives]

Yes, I keep a copy of my archive on a windows server. I've even tried manually over-riding folder permissions to prevent delete by the user that creates the archive, which does keep the file on the windows server should someone manually delete the job from the console or within Command workstation, but it still allows the deletion from command workstation and the console, removing the entry from the list. The workaround afterwards is that I can import the job again from the same location within command workstation, but this creates a second archive job in the folder instead of re-using the existing one - so it's far from elegant.

I've also done the regular backup method (which happens with my current archive method as well, I always keep backups), but often I don't know when a file was removed as some files go a month without getting re-printed, so it results in someone suddenly missing a file from who-knows-when, and me sifting through backups trying to find one where a file might still exist, and if it exceeds the backup retention period, the job is lost and must be re-created... messy.

So again, I feel like there should be some method (possibly something I'm overlooking, or some hidden feature) that prevents archive deletion from the printer itself. I.E, is there a User or Group associated with the printer's attached monitor? Something I can adjust/disable permissions for from Command Workstation perhaps, so the problem where people delete the file is effectively eliminated?

If not, again, is there a hot folder setup that would make more sense for this? I've not dabbled with hot folders so I'm unsure of all their capabilities, but I've been reading some of the guides and it sounds like there may be a way to prevent deletion of jobs through hot folders, but also allow automated printing through them.

The archive method is super convenient, it's just also ultra incredibly frustrating that any idiot can come up and delete the job and there's no way for me to stop them from doing that, it seems like such an obvious glaring oversight I can't believe an entire league of fiery programmers could overlook it.

[adam1991]

hmmmmm, so logging in to CWS as operator instead of administrator still allows the deletion of files?

[Fujilives]

hmmmmm, so logging in to CWS as operator instead of administrator still allows the deletion of files?

Hi, thanks for your response. Yes, Operators when logged into CWS can delete jobs, as far as I know there is no way to change this as it is a basic permission for a basic role (2 of the three role-defining checkboxes are "grayed out" so I cannot deselect them). Regardless, I'm not sure where you are going with this... is the operator role tied to the touch-enabled interface directly attached to the printer?

The reason I ask, is that no one is logging into CWS (except myself); instead they are interfacing directly with the physical printer, walking up to it, and using the touch screen on an arm attached to print / delete etc, so unless one of the existing default role groups (administrators/guests/operators/scan users/standard users) has an effect on the ability to do that, it shouldn't have any impact on this.

Is there perhaps a role-maintenance of some kind outside of the CWS "Users & Groups" area that has an effect?

[adam1991]

No, unfortunately the Fiery has only the three roles, and those apply to CWS and the copier interface (which is just a specially-formatted instance of CWS).

The Fiery is not the tool to solve this particular workflow issue. There are other ways to handle this, but those methods would be outside the Fiery itself.