When a normal (non-admin) users click my custom-made ribbon button in a document library, I would like to write the document library's information to some persistent farm-wide store (or at least a content database-wide store). A farm admin could later view this information in a custom central admin page. Something like this:
// In a Document Library (can be anywhere in the farm)
if user clicks myRibbonButton in DocumentLibrary
PeristentStore["DocumentLibraries"].Add(this DocumentLibrary.ID);
// This is what a farm admin would see in a custom CA page
foreach entry in PeristentStore["DocumentLibraries"]
listBox.Add(entry); // list all saved document libraries' IDs in a list box
Is there an out-of-the-box way to store such information, or should I deploy a custom database?
I've read about numerous options SharePoint offers to store custom application data, however - assuming a least-privileged configuration - each has severe limitations:
SPPersistedObjects
would be perfect but can only be written by farm admins, which renders them useless for this purpose (as pointed out in this question);SPWeb
property bags can be used to achieve this, but they create a new problem: how would the central admin feature know whichSPWebs
to scan? So I'm back at the beginning: I'd need some farm-wide place to remember whichSPWebs
have had their properties filled with the desired information. Same is true if I create a list.- A custom database solves all this as one can simply read/write anything into it. However, it introduces a potential nightmare that are security/permissions, deployment and backup/restore inconsistencies. In my specific case, it would be enough to create a custom table in an already existing content database, but I don't believe this is a good idea (potential updates breaking everything etc.).
Am I missing something or does SharePoint really not offer anything to solve such a common problem?