Hello! On the train the other day I had some ideas about the way data
input could work for a "last verified" field for OpenGuides. I drew a
This would result in three pieces of data, which will be stored if and
only if the "re-confirm existence?" tickybox is ticked:
- the date on which the existence of the business described was last checked
(it should be possible to give either a specific day or just the month)
- the method by which it was checked (free text, e.g. "phoned them up", but
with a tickybox or two to make it easy to give standard reasons such as
"went past and saw it open" - a tick in this box would be turned into
text by the code before storing in the database)
- the person who checked it (not explicitly entered on the form, but taken
from the username of the person performing the edit - see above, this
only happens if they explicitly choose to "re-confirm existence")
Anyone got any thoughts on the above?
Regarding the backend, here is some previous discussion on the point:
Dom points out in that post that there are two ways of doing it:
- as Wiki::Toolkit metadata
- as a new field in the node/content tables
Advantages of doing it as metadata:
- No need to change Wiki::Toolkit databases in a way that is irrelevant to
- The "method of checking" data is really OpenGuides-specific, so should go
in the metadata table, and then it would be nice to have the "date of
checking" in there as well. Also, the "person who checked" data needs
go somewhere (this isn't always the same as the "person who last
Then again, we already have a small inconsistency in that "date last edited"
and "person who last edited" are in different tables.
Advantages of doing it in the node/content tables:
- We can store it as a proper date type, which saves some fiddling around
in terms of actually using the data.
Actually it strikes me that a third possibility would be to use plugins:
though the Wiki::Toolkit plugin system never really got fully developed,
and this might be an overcomplicated way of doing it for little benefit.