Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Arantor
4921
Features / Re: New revs
« on February 13th, 2012, 01:59 PM »
(5 modified, 6KB)
Revision: 1332
Author: arantor
Date: 13 February 2012 12:58:38
Message:
! Add ability for 'multi_select' types in the standardised admin panel pages, in a style similar to that of the inline permissions dialogues. (ManageServer.php, Admin.template.php, Admin language file)
! Provide the admin with the ability to choose who receives notifications of new members, rather than everyone who is an admin, and/or global moderator. (ManageRegistration.php, Subs-Post.php)
----
Modified : /trunk/Sources/ManageRegistration.php
Modified : /trunk/Sources/ManageServer.php
Modified : /trunk/Sources/Subs-Post.php
Modified : /trunk/Themes/default/Admin.template.php
Modified : /trunk/Themes/default/languages/Admin.english.php
Revision: 1332
Author: arantor
Date: 13 February 2012 12:58:38
Message:
! Add ability for 'multi_select' types in the standardised admin panel pages, in a style similar to that of the inline permissions dialogues. (ManageServer.php, Admin.template.php, Admin language file)
! Provide the admin with the ability to choose who receives notifications of new members, rather than everyone who is an admin, and/or global moderator. (ManageRegistration.php, Subs-Post.php)
----
Modified : /trunk/Sources/ManageRegistration.php
Modified : /trunk/Sources/ManageServer.php
Modified : /trunk/Sources/Subs-Post.php
Modified : /trunk/Themes/default/Admin.template.php
Modified : /trunk/Themes/default/languages/Admin.english.php
4922
Features / Re: Selectbox
« on February 13th, 2012, 01:53 PM »
Eh, don't worry about it, more my fault for not double checking, and as it happens, I've already reimplemented my code.
In my case it's not the avatar selection I have in mind, but doing something with the notify-on-registration lark. Specifically, I wanted to have it so that you could select users who would be notified on a new registration rather than 'everyone who can approve registrations', but I can make use of it in other places, too.
In my case it's not the avatar selection I have in mind, but doing something with the notify-on-registration lark. Specifically, I wanted to have it so that you could select users who would be notified on a new registration rather than 'everyone who can approve registrations', but I can make use of it in other places, too.
4923
Features / Re: Selectbox
« on February 13th, 2012, 01:22 PM »
Oh... I thought it did something neat, and it seems my revert was a little too hasty. Oh well >_<
(I'm really not a fan of the classic Ctrl-click selector, I find it very irritating to use.)
(I'm really not a fan of the classic Ctrl-click selector, I find it very irritating to use.)
4924
Features / Re: Selectbox
« on February 13th, 2012, 01:16 PM »
Wish I'd have known that earlier >_< That'll teach me not to remember every nuance of the code :P
Since the JS selectbox is much better than what I was working, I'll run with that instead.
Since the JS selectbox is much better than what I was working, I'll run with that instead.
4925
Features / Re: Selectbox
« on February 13th, 2012, 12:18 PM »
In other news I have incidentally found functionality that is broken by this feature, but that probably needed rewriting anyway.
The admin pages that use prepareDBSettingContext theoretically support select with multiple items (i.e. that ghastly situation where you have to ctrl-click to select items from a listbox), but the new selectbox doesn't support this.
Not a real problem, since select-multiple is not actually used anywhere in Wedge (nor, I think, in SMF but included out of thoroughness) so what I'll do is remove multiple support, and replace it with a new type for multi-selections.
The admin pages that use prepareDBSettingContext theoretically support select with multiple items (i.e. that ghastly situation where you have to ctrl-click to select items from a listbox), but the new selectbox doesn't support this.
Not a real problem, since select-multiple is not actually used anywhere in Wedge (nor, I think, in SMF but included out of thoroughness) so what I'll do is remove multiple support, and replace it with a new type for multi-selections.
4926
Features / Re: Disallowing edits to posts
« on February 13th, 2012, 11:55 AM »Suggesting to simply check for modified_member when deleting a member, and if found, unserialize data and serialize with last known member name.
4927
Features / Re: Disallowing edits to posts
« on February 13th, 2012, 11:39 AM »but I think modified_name could go, because, technically, we're never updating the name as it's being changed/deleted... Are we?
4928
The Pub / Re: Quick moderation
« on February 13th, 2012, 11:00 AM »
Yes it is. banPermissions() in Security.php currently sets it up regardless of the user.
But yeah, it was something that I figured might as well be done :)
But yeah, it was something that I figured might as well be done :)
4929
Features / Re: Disallowing edits to posts
« on February 13th, 2012, 10:58 AM »
I agree that a data field is necessary but care *must* be taken about what goes in it. Modifier name/poster name for example shouldn't, because if the related account gets deleted, bad stuff is going to happen because there's no way to update it easily in MySQL (as it doesn't have any notion of serialize)
4930
Features / Re: Disallowing edits to posts
« on February 13th, 2012, 09:20 AM »Is that the case here? Can admods just say "don't edit that again or you're banned / put into a group that cannot edit"?
I'm now seeing more of a balanced approach being required, so perhaps this should be left alone for a while and turned into a plugin rather than a core feature (and if people like it, we can make it core)
4931
Features / Re: Disallowing edits to posts
« on February 13th, 2012, 02:44 AM »
...this is a totally new feature that doesn't yet exist in Wedge, not something that just needs enabling.
4932
Features / Re: Disallowing edits to posts
« on February 13th, 2012, 02:28 AM »
That's exactly my thinking - and now we can actively offer the choice to block it. So... if that were an option, would you enable it? Would you prefer it to be default?
(The whole matter of the linked thread, of whether it should be displayed or not, that's another matter entirely but I have some ideas on that too.)
(The whole matter of the linked thread, of whether it should be displayed or not, that's another matter entirely but I have some ideas on that too.)
4933
Features / Re: Disallowing edits to posts
« on February 13th, 2012, 02:17 AM »
Sort of, although you completely missed the post of what I was asking :/
Whether we display who edited something is absolutely irrelevant at this point in time. Right now, the fact is that we now actually track *who* edited it, rather than just the name of the editor.
The point I was getting at here is that if a moderator edits someone's post, should we prevent the person whose post it is from being able to edit it back?
Essentially it is implementing http://wedge.org/pub/feats/6966/storing-the-modified-post-user-id/
Whether we display who edited something is absolutely irrelevant at this point in time. Right now, the fact is that we now actually track *who* edited it, rather than just the name of the editor.
The point I was getting at here is that if a moderator edits someone's post, should we prevent the person whose post it is from being able to edit it back?
Posted: February 13th, 2012, 02:14 AM
Essentially it is implementing http://wedge.org/pub/feats/6966/storing-the-modified-post-user-id/
4934
Features / Re: New revs
« on February 13th, 2012, 02:17 AM »
(2 files, 3KB)
Revision: 1330
Author: arantor
Date: 13 February 2012 01:16:46
Message:
! Add the number of unapproved members to the admin menu too (under reported posts) and add that into the count of items too, so that it raises prominence on it and admins can deal with it better. (Subs.php, index language file)
----
Modified : /trunk/Sources/Subs.php
Modified : /trunk/Themes/default/languages/index.english.php
Revision: 1330
Author: arantor
Date: 13 February 2012 01:16:46
Message:
! Add the number of unapproved members to the admin menu too (under reported posts) and add that into the count of items too, so that it raises prominence on it and admins can deal with it better. (Subs.php, index language file)
----
Modified : /trunk/Sources/Subs.php
Modified : /trunk/Themes/default/languages/index.english.php
4935
Plugins / Re: Readability
« on February 13th, 2012, 02:07 AM »
I was against it as a core feature but as a plugin... *shrug* I don't have to use it now, do I? :P