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:
SPPersistedObjectswould be perfect but can only be written by farm admins, which renders them useless for this purpose (as pointed out in this question);
SPWebproperty bags can be used to achieve this, but they create a new problem: how would the central admin feature know which
SPWebsto scan? So I'm back at the beginning: I'd need some farm-wide place to remember which
SPWebshave 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?