| Previous · Next | |
| User | Message |
|
martink
|
Date: 1/7/2010 4:21 am · Subject: Custom useraccount states · Rating: 0
Hi,For a project I'm about to work on, it's desirable to use custom values user account status in addition to the currently existing 'Active', 'Deactivated' and 'Selfdestructed'. Think along the lines of 'CRM', 'EmailOnly' and stuff like that. Accounts that have such a custom status would still be disabled, ie. still only accounts with status Active are enabled. As far as I can see, inserting custom states into the user table is no problem API wise. isEnabled checks for Active, and status can be easily change to an arbitrary value using WG::User->update. However the API docs state that only the three aforementioned statuses are valid. So, my first question is if I can safely use custom statuses for user accounts and ignore that specific part of the API docs? The only problem I see is in editing user accounts through op=editUser. There, the statuses available from the select list are hardcoded, and thus if a user account with a custom state is edited through that interface it's would not retain its custom state and change to Active. My idea to solve this problem is to fetch the status that are in the db and add those to the status select list. Would that be ok? Martin |
| Back to Top |
Rate [ | ]
|
|
patspam
|
Date: 1/7/2010 4:41 am · Subject: Re: Custom useraccount states · Rating: 0
It wouldn't be future-safe. Even if you make it work perfectly now, who's to say that future core code won't make assumptions about what values are valid and break as a result? I'd use the User Profiling system to add a custom field for the additional info. Patrick On Thu, Jan 7, 2010 at 9:21 PM, <martin@oqapi.nl> wrote: martink wrote: |
| Back to Top |
Rate [ | ]
|
|
martink
|
Date: 1/7/2010 5:01 am · Subject: Re: Custom useraccount states · Rating: 0
Hi Pat,I know that it isn't future safe, which is why I was asking the question in the first place =). Maybe I should have asked whether it is possible to change the docs to 'WebGUI uses these states, but you are also allowed to add your own custom states which always make an account disabled.' or something along the lines of that. Concerning the profile field: I actually considered that at first, but found it less desirable than using a custom account status for three reasons: 1) The 'enabledness' of an account and its custom state, would reside in two seperate parts (or screens) 2) More importantly, it's possible to activate accounts that have one of the custom states in the profilefield, which are mutually exclusive (eg. user.status=Active and userProfile.accountStatus='CRM' is not a valid combination ) 3) What if WebGUI would add something like a default workflow to purge accounts that have been Deactivated for some time? The profile field would not prevent my 'custom' accounts from being wiped. Martin dev@webgui.org wrote: > patspam wrote: > > It wouldn't be future-safe. Even if you make it work perfectly now, > who's to say that future core code won't make assumptions about what > values are valid and break as a result? > I'd use the User Profiling system to add a custom field for the > additional info. > Patrick > > On Thu, Jan 7, 2010 at 9:21 PM, > wrote: > > martink wrote: > > Hi, > > For a project I'm about to work on, it's desirable to use custom > values > user account status in addition to the currently existing 'Active', > 'Deactivated' and 'Selfdestructed'. Think along the lines of 'CRM', > 'EmailOnly' and stuff like that. > > Accounts that have such a custom status would still be disabled, ie. > still only accounts with status Active are enabled. > > As far as I can see, inserting custom states into the user table > is no > problem API wise. isEnabled checks for Active, and status can be > easily > change to an arbitrary value using WG::User->update. However the API > docs state that only the three aforementioned statuses are valid. > > So, my first question is if I can safely use custom statuses for user > accounts and ignore that specific part of the API docs? > > The only problem I see is in editing user accounts through > op=editUser. > There, the statuses available from the select list are hardcoded, and > thus if a user account with a custom state is edited through that > interface it's would not retain its custom state and change to Active. > > My idea to solve this problem is to fetch the status that are in > the db > and add those to the status select list. Would that be ok? > > Martin > > > > > http://www.webgui.org/forums/dev/custom-useraccount-states > > > -- > > WebGUI > http://www.webgui.org > > > > > http://www.webgui.org/forums/dev/custom-useraccount-states/1 > ------------------------------------------------------------------------ > > > > |
| Back to Top |
Rate [ | ]
|
|
fdillon
|
Date: 1/7/2010 7:22 am · Subject: Re: Custom useraccount states · Rating: 0
We do something similar for one of our clients. We accomplish it by using a custom profile field and a custom auth module. The auth module completely disregards WebGUI's status field and looks at the custom profile field for the purposes of login. All accounts are marked active in the WebGUI status field until such time that they are deleted. There are places in the core that will only return users with a status of "Active" so while adding your own status values to the database table may seem harmless, it will break certain functionality. |
| Back to Top |
Rate [ | ]
|
