HT/VT Reporting Website Overview

[marlattrj-p40]

[font=&quot]Also you might want to make the VisitType not visible even to the local admin after disabling it, other wise they could end up with a mile long list of options. Just put a delete button and when they click "delete" it just disables the VisitType making it appear deleted.

-Rich
[/font]

[The_Earl]

I think you would be ok if you allowed the text of the visit type to be changed for a given ID. The two types that you would not want to edit are 'Visited' and 'Not Visited'. I would disable editing of those, as any change to them would probably lead to confusion. You could add a "Power User" edit switch that would allow changes to the two if you wanted to, but anyone smart enough to want to change those could probably do it in the DB anyway.

As for the delete, I would still call the function delete, even if you just disabled the category.

Some systems, like Bugzilla do not allow you to delete an entry that is in use. It will allow you to move all of the entries for the ID that you are trying to remove to an existing entry. You could then really delete a type, but you would have to re-assign all of its records to another type.

In some of my apps, protected options get negative IDs. That allows me to quickly verify that certain operations are permitted on them, and add additional protected types quickly.

Just a few thoughts.

[brado426]

I think you would be ok if you allowed the text of the visit type to be changed for a given ID. The two types that you would not want to edit are 'Visited' and 'Not Visited'. I would disable editing of those, as any change to them would probably lead to confusion. You could add a "Power User" edit switch that would allow changes to the two if you wanted to, but anyone smart enough to want to change those could probably do it in the DB anyway.

The admin wouldn't have access to the DB.... the idea is that this is a centralized application that is only installed in one place.

So you're saying, have a mandatory "Visited" and "Not Visited" option where the text could be edited and then the ability to add custom Visit-Types. If we kept it absolutely clear in the administrative interface that the "Visited" text is for "Visited" and the "Not Visited" text is for "Not Visited," I think that might work.

Brad O.

[russellhltn]

I think people would want to change the phraseology, but allowing changes like that sets the user up to cause problems. Along the lines of your example, just think if someone changed "Visited" to "Not Visited." All the historical data would be completely wrong.

Right. Question: Would you ever want a change to the visit type table to affect the historical data? If not, then I'd be inclined to NOT link the visit type and historical tables and simply write the current values into the historical table when the month becomes "history". It's not the 60's where we have to squeeze every possible byte of space anymore.

That way you can change the visit schema, phraseology and how each type counts to visit/not visited without changing your old values. The visit type table only influences the "current" month.

While the suggestions of "deletes" only mark things inactive will work, that seems much more complex and seems far more likely to run into bugs or other strange things.

If by chance you see a need to change history, you can always run a "find and replace" type of operation.

[Mr. M-p40]

Here's a technical concern that I'm not sure how to solve....

Whenever a teacher reports, the system plugs the Visit-type ID into the "Results" database table. The VisitType ID in the VisitType table is joined with the VisitType ID in the Results table. If we allow the Visit Types to be modified/Deleted/Added in the "Visit-Types" table, what is going to happen to all the Visit Type relationships that were previously reported? If significant changes were made to the Visit-Types table, the reported visits would link to the wrong Visit-Type or possibly even link to nothing.

The system currently stores up to one year of historical data so that the "History" report can be generated.

It is almost as if we would need to allow the user to configure the Visit Types the first time they used the system but never allow it again. Either that or we would need to do an UPDATE of all the IDs that were previously submitted whenever a change was made to the VisitTypes table.

The more I think about this, the more complex it gets.

I'm not sure that there are any easy answers here. Please enlighten me.

Brad O.

Rule of thumb...never delete...only supress. I would recommend you supress the old type and have a new one created. It's like setting a type to inavtive or active. This way you never lose db integrity. You can also update the old types to the new value or you can just use the new value moving forward and consider the other legacy.

That's my 2 cents...

[Mr. M-p40]

The admin wouldn't have access to the DB.... the idea is that this is a centralized application that is only installed in one place.

So you're saying, have a mandatory "Visited" and "Not Visited" option where the text could be edited and then the ability to add custom Visit-Types. If we kept it absolutely clear in the administrative interface that the "Visited" text is for "Visited" and the "Not Visited" text is for "Not Visited," I think that might work.

Brad O.

Won't work...think international...

Visitamos...No Visitamos...

I say you give us correct principles and let us govern ourselves...in the end I could see someone creating all their own anyway and never using visited and not visited. That's what I would do as a work around and that would render this particular solution useles..

[brado426]

Won't work...think international...

Visitamos...No Visitamos...

What I meant was that the administrative dialog box for Visited and Not Visited would be mandatory and allow the user to enter whatever text they wanted for each (even in Spanish.) Can't we assume that all groups will at least need a "Visited" and "Not Visited" option?

Brad O.

[marlattrj-p40]

What I meant was that the administrative dialog box for Visited and Not Visited would be mandatory and allow the user to enter whatever text they wanted for each (even in Spanish.) Can't we assume that all groups will at least need a "Visited" and "Not Visited" option?

Brad O.

I agree. What we could do is have a field that says Visited" and "Not Visited" and another one next to it that has the custom visit types. So if some one was to select "Visited" they could have some options as to what visit type they can select and if they select "Not Visited" they will be given choices like "Called to check up" or "Mailed a letter".

This would allow for different types of reporting but still keep with the basic visited/not visited.

Rich Marlatt

[The_Earl]

It does not matter what we call the two categories, what is important is that we have to aggregate all other types into 'visited / not visited' for reporting.

For some instances, you would change the display of these two categories, but you CANNOT change the underlying meaning. Changes to the meaning of these two categories would make the aggregation / reporting information useless.

My point earlier was that this change would only make sense at install time, and only for the installer / maintainer to make. You would never allow a user to modify these unless you could be sure that the user understood the implications of changing them. You would not allow these entries to be removed or inactivated.

If changes only make sense during installation, you can safely assume that the installer has full control over the data store and the software configuration. You could allow the installer to modify these in the DB, or in a config file, but it does not make sense to allow changes of ANY type to these on a regular basis. At most, I would require full admin privileges, and two separate confirmed steps to change these types.

One of my Palm applications has a 'dangerous' mode that allows operations that could really mess things up. You have to enable 'dangerous' mode to see the options, then there is a confirmation dialog for the dangerous operations that specifies the bad things that can happen if you perform those operations.

Again, I think you can safely assume that the installer can get into the DB and modify the 'visited / not visited' text, and that they have the required knowledge to do so. After that, I can't see a reason to change those two categories.

[marlattrj-p40]

I agree. What we could do is have a field that says Visited" and "Not Visited" and another one next to it that has the custom visit types. So if some one was to select "Visited" they could have some options as to what visit type they can select and if they select "Not Visited" they will be given choices like "Called to check up" or "Mailed a letter".

This would allow for different types of reporting but still keep with the basic visited/not visited.

Rich Marlatt

Here is an example of what I mean: http://marlattfamily.org/ht/test.html

This would require people to report Visited or not visited but also give them the option to report what type of visit/non-visit they did.