A Big Problem With Printed Docs

john

I have just had a major problem. This could obviously be me, but I wondered if you could offer some help?

I have a situation where one of my system users (Called Agency) is required to submit worker information to us over the web. We have about thirty Agencies using the system so far. The information they submit includes Bank Details so is obvioulsy quite sensitive.

The BO they submit is called Temp. This has a field called AgencyCode which when created is automatically set to the Agency login Name:

If Temp IS NEW Then
Temp.AgencyCode=LoggedInAgency.LoginName

Is the basics of how this rule is put together. There is then a Read Protect Rule that stops the Agencies seing each others Temps:

If NOT(Temp IS NEW) AND LoggedInSystemUser.LoginName <> Temp.AgencyCode Then
READ PROTECT Temp FROM Agency

This all works fine.

Now when an Agency submits a new Temp to us they are required to print out the information they have just submitted. Now due to the fact that they are able to create several different types of temps this is achieved by a Process. All the processes are pretty much the same except it presents the user with a different form when a different temp type is selected. The process runs as follows:

RULE 1 (Enter Details)
Enter NEW Temp WITH Temp.CatagoryGrade='PAYE' USING PAYE
(Different processes include different WITH information)

RULE 2 (Message)
DISPLAY MESSAGE 'Warning: You Are Advised To Print This Form And Have Your Temp Sign It For Your Records'

RULE 3 (DisplayDoc)
DISPLAY DOCUMENT PrintedNewStarterFormPAYE

The user inputs a temp, a message is generated advising them to print the temp and then a document is generated based on the information they have just put in. This has worked great for a long time with no reported problems.

However today I have juat received a call from an Agency telling me that when they have gone to print there temp, they have been presented with the information that another Agency has just submitted. Obvioulsy this is very bad and has scared me a little.

Based on what I have said I hope you can see what I am trying to achieve here. Could you offer some assistance on the best way to do this. I am looking at it and thinking that the two Agencies must have clicked create at almost exactly the same time for this to happen but I still hoped my read protect rule would of prevented this.

Could you help

Regards
John

greg

John,

Am I correct to assume as the name implies that your Temp object is not persisted? I think that in this case the object is NEW until it is discarded and your protection rule will not work. The other agency had probably created their Temp shortly after the first one and it was the one retrieved in the first agency document.

Greg

john

Thanks for the reply. No the Temp record IS persisted in the normal Derby Database.

Admitadley this does appear to be a very rare occurance but was slightly worrying. Is there anything glaringly wrong with my rules, or are there any better ways to achieve this.

If not I may resort in taking away the option for the Agencies to print the newly created records but the problem here is the forms are normally filled in while the temp is sat with them. When the records do eventually get submitted to our staff there is a turn around time before they actually become visible to the Agency again as they are checked and imported into our payroll system before the Agencies can actually access the records again

Regards
John

john

As a further note the word TEMP means temporary worker in the recruitment industry (in my system). These records belong to the Agencies and are used by them later to generate what we call an Assignment Sheet which is basically a simplified list of Timesheets which again will be imported into our payroll system

Regards
John

tford

Hi John,

I wonder if this has anything to do with your issue:

In your rule:

If NOT(Temp IS NEW) AND LoggedInSystemUser.LoginName <> Temp.AgencyCode Then
READ PROTECT Temp FROM Agency

I'm trying to understand why you have "NOT(Temp IS NEW)" in it. Don't you want to READ PROTECT all TEMP instances from a different agency seeing them? Why would it matter if the instance is new or not?

Tom

john

Hello agian

Regarding your last post I would like to refer to the post:
Extended Searches (Unwanted Query Links)

As this was a long time ago it does appear a little vague to me now. I believe the problem with using:

If Temp IS NEW AND LoggedInSystemUser.LoginName <> Temp.AgencyCode Then
READ PROTECT Temp FROM Agency

without the NOT statement included meant that the Agencies were denied access to create NEW instances of "TEMP", probably because in the NEW state the AgencyCode IS undefined.

As I say this solution was given to me in the post I mentioned and I do remember having issues with it at the time.

I hope this answers the question.

Once the create button is hit though I would assume the temp is not NEW anymore even if it is part of a process. I am trying to visualise how this could happed.

If Agency1 and Agency2 are entering temps at the same time, before either hit "create" it is theoretically possible for one to see the other, but there is no option for them to do this. Once Agency1 hits "create" that record is no longer NEW so should only be printable by Agency1. Before Agency2 has the ability to print a Temp he also has to hit "create" (due to the RULE order in the Process), meaning that even if the original Temp details were freely accessible for some reason, that Temp would no longer be in the context, so Agency2 would only be able to see the temp they just created. . . .

However, (during writing that this just came to me). If Agency1 didnt print the temp out Immediately after hitting create and Agency2 hit create during this time, then the Agency2 temp would now be in the Context and therefore printable by both (maybe??). So even though neither Temps are NEW anymore, (if this is whats happened) it woul appear that the READ Protec RULE doesnt extend to the printed DOCS.

Am I right in saying that at the point where the system displays:
"Please Click Here To See The Document"
The document has already been generated which would kind of facilitate what I have tried to say?

Does that sound possible???

Regards
John

tford

John,

Consider trying this:

1- Eliminate rule: If Temp IS NEW Then
Temp.AgencyCode=LoggedInAgency.LoginName

2- Change READ PROTECT to: If LoggedInSystemUser.LoginName <> Temp.AgencyCode Then
READ PROTECT Temp FROM Agency

3- Change RULE 1 (Enter Details) to:
Enter NEW Temp WITH Temp.CatagoryGrade='PAYE',Temp.AgencyCode=LoggedInAgency.LoginName USING PAYE

Tom

john

Hi Tom

Thanks for your help. That was very concise. I can see what your saying and I will give this a try.

If what I have said above is true though I am wondering if it will actually have any affect. The reason I say this is at the stage of the document being printed the temp is no loger NEW anyway so taking out the reference to the temp being "new" or not wouldn't have any affect?

I suppose what I am saying is if both Agencies arrive at the:
"Please Click Here To See The Document" at the same time there will be only one document ready to print (which will be the last Temp that was passed to it), as I now assume this link only references a static web page (the printed doc) that has already been generated

I hope that makes sense. Could Support offer some more assistance on this?

Thanks again for your help Tom
Regards
John

tford

John,

Hope you don't mind 1 more question.

In your: RULE 3 (DisplayDoc)
DISPLAY DOCUMENT PrintedNewStarterFormPAYE

Is that "Determined at run time" or is a query specified? If a query, what are it's parameters?

Thanks,
Tom

john

Ah ha. . .

I can see what your getting at here. Yes in fact my documents are defined at runtime.

Now if I had an index that was concurrent for the Agency I could force the document to be generated based on the MAX index for that Agency which would always be the temp they have just created. . .

Thanks so much for making that spring to mind!!

Regards
John

tford

John,

You could also add a "Printed" attribute (yes/no type -- default to No) to the Temp BO & have your document run a query like:

FIND Temp WHERE Temp.AgencyCode=LoggedInAgency.LoginName AND Temp.Printed="No"

After the printing step in your process, you would turn the Temp.Printed flag to "Yes".

Tom

john

Fabulous

That is another good idea. I am actually shocked I never thought of these myself now. They seem rather obvious when you think about it!

Thanks again
John

john

Hello,

I think I need to re-visit this.

I have tried to re-create the problem and I think maybe I may have been slightly wrong in the first place. I now believe that the killer Forward and Back buttons on the users web browser may have been involved somewhere along the line. Understandably the Support stance on browser buttons is normally, "the browser buttons shouldn't be used as they can generate abnormal results". However, even if I attempt to control the users Window (which being a novice I would require the users to be redirected from another page - which sometimes causes problems with popup blockers) I cannot guarantee the way all users will access my system. Any computer savy person could realise that the actual link for the login screen itself can be bookmarked, rather than the link I give them to access the system. As I say because the information is sensitive I have to be sure on this.

Now I have tried to use a fool proof (I think) query to generate the document. I dont think in this case it will make any difference as (I believe) the query is run BEFORE the message pops up to say:
"Please Click Here To See The Document"
so I dont see how this is any different from letting the document be generated at Run time as each session would generate a seperate document if Run time doc was imlemented?

My problem is (if I am right) that once a document is generated it becomes static, so all it takes for the user to see somebody elses information is to use the Browser buttons a couple of times?

If the document was generated on the fly, this wouldn't be a problem as the query would run again everytime the user presses the:
"Please Click Here To See The Document" Link.....
(I HOPE THAT MAKES SENSE)

Now I am sure some of what I have said could be technically wrong but this is my understanding of it so far. Could someone possibly confirm or correct me on this because I am a little concerned about this and will probably have to re-think the whole thing.

As a side note (and this is going to sound very NEWBEE) how is it on some secure websites when you attempt to use the browser buttons the previous pages expire? This would potentially solve the problem, but as I say I probably need to understand more of the fundamentals to really get a grasp of how the system works!

Regards and thanks for all your help
John

aware_support

This could be a bug in the system, but we need to confirm the circumstances when a wrong document is printed. Can you succinctly detail the steps required to reproduce the problem?

This is unlikely to be caused by Back and Forward buttons.

What is the type of the document being created - Doc, Excel, HTML, other?

john

Thanks Support for getting back to me.

During my messing about it would appear something is very wrong here, either with my coding (explained above) or as you say, some sort of bug . . .

The document type is HTML. You were right, the forward and back buttons dont necesserily have to be involved. I will try to explain what happens.

Agency1 creates a temp
(but for some reason doesnt click "HERE" immediately)

Agency2 creates a temp
(then clicks "HERE" straight away)

Agency1 then hits print and is presented with Agency2 temp!

It gets more strange. Upon closing both of the printed docs. If Agency1 clicks "HERE" then Agency2 clicks "HERE" both Agencies are then presented with Agency1 information. Upon closiing them both again, if Agency2 clicks "HERE" then Agency1 clicks "HERE" both Agencies are presented with the Agency2 temp again?????

As a further note, during my playing. When I went to print one of the temps again, I was presented with a totally different temp all together. Now weather or not another Agency had actually been submitting temps whilst I was doing this I dont know, but it is worth pointing out that I am doing my testing in the TEST system and our Agencies are using the live system.

I think for now I am going to take this ability off because it just appears to Random.

As I say thanks for getting back to me

Regards
John

john

I have just discovered as a further note, the information displayed to users is not even fixed between what is in testing and what is in live.

Whilst I was re-creating this problem in "Testing Mode" I received a call from an Agency at the other end of the country telling me they had attempted to print a Temp form and was presented the information I had just put in. They work in "Live Mode" and I was testing in "Testing". I am definate about this as the info I put in was just gumph:
"hfohogd
gdfghg
ghfghg" etc

and this is what she saw, she actually called because she thought the system had crashed!

I was under the impression that the info in the Test DB and the Live DB were totally seperate?

Anyway I wanted to pass this information on as I thought it may help

Thanks again for taking the time to help

Regards
John

aware_support

Indeed, there appears to be a bug with HTML documents, whereby a document generated for one user can be overwritten by a document for another user. We will fix it asap.

In the meantime can you use a different type of document as a workaround?

john

Yes, I have already started to work on using PDF docs instead which appears to be working better although I may get some complaints about the speed it appears better than the alternative and the forms look prettier!!!

Regards
John