Basic idea:
An API that allows to save user level settings, identified by a string.
Stuff to think about:
- Also store the default value in that table, for example by using the (u)id 0
- Allow multiple levels of defaults, for example for roles.
- How much of the default handling could the get function handle automatically? Maybe default to check for uid < role ids < global default and optionally allow to pass in a type => array(keys) mapping which overrides the default?
Two API functions:
privatemsg_get_setting()
privatemsg_set_setting()
The arguments depend on what this supports, most basic version:
get ($setting, $uid = NULL)
set($setting, $value, $uid = NULL)
To support the suggestion above, it could look like this:
get($setting, $ids)
$ids would per default be like this:
array(
'user' => array($account->uid),
'role' => array_keys($account->roles)
'global' => array(0)
)
We can also rely on our query builder for special cases.
set($setting, $value, $type, $id)
Schema:
pm_settings
uid, int (maybe type + id instead to support different levels of defaults)
setting, varchar
value, int (or do we want a serialized string, similar to {variable}?)
Thoughts, suggestions, ideas?
Comment | File | Size | Author |
---|---|---|---|
#17 | defaults_and_upgrade2.patch | 5.83 KB | Berdir |
#15 | defaults_and_upgrade.patch | 5.8 KB | Berdir |
#12 | privatemsg_user_settings4.patch | 14.51 KB | Berdir |
#11 | privatemsg_user_settings3.patch | 14.51 KB | Berdir |
#8 | privatemsg_user_settings2.patch | 14 KB | Berdir |
Comments
Comment #1
BerdirOk, here is a first patch, i implemented the fancy version...
API functions:
The first three should be obvious, the last extracts the default ids off a user object (defaults to the current user and privatemsg_get_setting() does too).
Here is an extract from the tests to see how it can be used.
What is implemented:
- The API :)
- A rather intelligent (I hope) and well tested (I think) static cache mechanism that works like this: 1. Look in cache for most specific type (first in array), 2. try to load not-yet-loaded settings for all types/ids, 3. go through all types/ids and return the first match. This means that the order of types in the $ids array indicates their weight/importance.
- Schema including update functions
- Disabled is ported to this API (There is still privatemsg_is_disabled() because that one does the user_load() and permission check). Existing disabled settings are not being ported yet.
- There are rather good tests for it.
TODO/Questions:
- Api docs
- Would it be useful to make the implementation configurable? (think cache.inc)
- Currently, only integers are supported, should we switch to serialized string instead? (Might make it possible to port more configurations like the role-based blocking rules to it but would slow it down)
- I forgot all other questions I had, too tired.
Please test and review!
Comment #2
litwol CreditAttribution: litwol commentedWhy &_privatemsg_setting_static_cache() and not &drupal_static('pmsg_static_cache_key', array()) ?
Comment #3
BerdirBecause this is Drupal 6 :)
Comment #4
litwol CreditAttribution: litwol commentedimho new features need to be developed against latest and the greatest (d7) and back-ported if necessary. Not the other way around. not to mention as i already pointed out some tools are already implemented in d7, by working on new features there you have the luxury of learning of the new tools first rather than reinventing :). Not saying you didn't, i'm saying others might not be as thorough.
Comment #5
BerdirYou are right, but...
- 7.x-1.x is stable. To add new features to 7.x, I first need to start a 7.x-2.x branch. Therefore, I'm currently using 6.x-2.x as the development branch.
- This feature is a dependency for #967164: E-mails not sent if message was sent to role members, which is currently targeted against 6.x-2.x too
I will start a 7.x-2.x branch sooner or later, not sure about the process yet (not the technical part...)
Comment #6
BenK CreditAttribution: BenK commentedSubscribing to help with testing.
Comment #7
BenK CreditAttribution: BenK commentedI tried applying the patch in #1 using "git apply" but it didn't work. Error said:
error: patch failed: privatemsg.module:2763
error: privatemsg.module: patch does not apply
Does this need a re-roll?
--Ben
Comment #8
BerdirComment #9
BenK CreditAttribution: BenK commentedHey Berdir,
I'm not exactly sure how to test this patch, but I applied it successfully. However, when browsing around the site, I'm now getting the following notice:
user warning: Table 'd6tod7.pm_setting' doesn't exist query: SELECT pms.type, pms.id, pms.value FROM pm_setting pms WHERE (pms.setting = 'disabled') AND ((pms.type = 'user' AND pms.id IN (1)) OR (pms.type = 'role' AND pms.id IN (2)) OR (pms.type = 'global' AND pms.id IN (0))) in /Users/benkaplan/git/drupal-6.20dev/sites/all/modules/privatemsg/privatemsg.module on line 2925.
Also, update.php didn't indicate any updates to run.
Let me know what else you need in the way of testing. As I understand it, most of what we need this patch for is in other issues (like the e-mail notifications for messages to roles).
--Ben
Comment #10
BerdirThere is an update function with the number 6205(). It is possible that an update with this name was already run when you tested another issue (most likely the pm_thread one, which adds update functions too).
So to be able to test this patch, you need to directly set back the schema_version information in {system} to 6204 for privatemsg. The following query should work:
UPDATE system SET schema_version = 6204 WHERE name = 'privatemsg'
Comment #11
BerdirOk, can you retry the update with this patch?
Remember that you probably will have to re-run the update query from above.
Comment #12
BerdirForgot the update the schema definition in the update function.
Comment #13
BenK CreditAttribution: BenK commentedLatest patch worked great so this is RTBC! :-)
--Ben
Comment #14
BerdirOk, commited!
I'm not sure if I will do a straight port of this to D7 or instead make this a separate module.
Comment #15
BerdirUpdated patch for 6.x-2.x.
Contains support for a default argument and variable_get() fallback. Also contains the update function to migrate existing settings, which I forgot above.
Comment #17
BerdirBugfix for the above patch, this should work.
Comment #18
BerdirCommited, ack to 7.x-2.x!
Comment #19
BerdirCommited to 7.x-2.x.