[development] Moderation bit behavior

[Earl Miles]

Gerhard Killesreiter wrote:
> Mark Fredrickson wrote:
>> On the subject of bits on nodes, I would advocate for the least 
>> number of hard wired fields as possible. Hardwired data conflicts 
>> with user configurable systems and makes administration harder and 
>> more confusing for end users. Instead, I would advocate for 
>> dynamically added data (from modules) where needed.
>>
>> In more specific terms, let me argue for removing a large portion of 
>> the current node object (feel free to disagree):
>>
>>  From the node table:
>> nid  - keep
>> vid  - keep
>> type  - keep
>> title  - remove. Titles should be set by node modules (and stored 
>> where the body and teaser are), not stored in the node table.
>
>
> This was a design decision. We often only need the title of a node 
> (for link lists for example). If we do a join on the node_revisions 
> table, we lose a lot of time. We are contemplating to add the author's 
> name for the same reason (save join on user table).
>
>> uid   - keep
>> status  - remove. Let a module like workflow control the state of the 
>> node. Or, don't have a state. Let the admin decide. Node_access is a 
>> better solution than an all or nothing published state, in my opinion.
>> created - keep.
>> changed - keep
>> comment - remove. Why would I want this data if I don't allow 
>> comments? Spareness should be avoided if we can help it.
>> promote - remove. Let's move nodequeue into core and make a default 
>> "front page" queue. This more extensible.
>> moderate - remove. As this thread shows, no one is sure exactly what 
>> moderate should do. Let a moderation system control node moderation.
>> sticky - remove. Again, let the nodequeue system decide what is first 
>> in the order.
>
> I'd be in favour of a more flexible bitfield instead of all the single 
> fields.
I'd be in favor of something along these lines:

node_flag('moderate') -- returns the name of the flag used for 
'moderate' or NULL if there isn't one.
node_flag_register('moderate') -- register the flag during .install, 
returns the real fieldname. Returns NULL if no flags are available.
node_flag_list() -- return an array of all existing flags

Modules can then register their flags which are directly put in the node 
table. We can pick some number of these; we could add a method to add 
more flags;

Queries simply use node_flag('moderate') instead of 'moderate' if they 
care about it. They never need to know the field's true name.

Cons: database names won't be transparent because it will just be 
'flag1', 'flag2' or whatever, and some kind of translation may need to 
be done for things that look at a node as a whole. Also, 'flag1' on one 
Drupal install will have a completely different meaning from 'flag1' on 
another. I think both of these cons are quite minor; they allow us to 
kind of do away with the moderate flag without actually doing away with 
it. Modules which need to set flags can.