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
4861
Features / Re: Don't know if I shared it publicly or not
« on February 17th, 2012, 12:41 PM »
Well, I'm just taking a break to go have a shower (always good for clearing the mind), then I'll look at moving the conversion code to the attic, and dropping the existing changelogs from the current repo, which will take about an MB out of the current deployment size in total, I'd say...
4862
Features / Re: Don't know if I shared it publicly or not
« on February 17th, 2012, 12:29 PM »
So I started on this today.

I'm thinking that the AeMe changelog - like the SMF changelog - probably should be removed from the admin panel as a general rule, even as nice as AeMe's changelog page is. What occurs to me is that we should keep that stuff on wedge.org (perhaps separated by month, or by release or something, and even then it only needs to occur after we hit alpha, because then we just track changes between releases since alpha)

Thoughts?

(I'm still figuring out how I want to handle the rest of the items like FFMPEG/IMagick, but I got safe mode in there is a way I'm happy with for now)
4863
Features / Re: New revs
« on February 17th, 2012, 12:17 PM »
(6 modified, 5KB)

Revision: 1356
Author: arantor
Date: 17 February 2012 11:17:11
Message:
! Typo fix in the credits (Who.english.php)

! Bug fixes from the generic list template (invalid markup under certain circumstances, not always validating existence of list) (GenericList.template.php)

! Rejigging the list of version numbers in Detailed Version Check (to move stuff there from Media/About) (ManageMaintenance.php, Subs-Admin.php, Admin.template.php, Admin.english.php)
----
Modified : /trunk/Sources/ManageMaintenance.php
Modified : /trunk/Sources/Subs-Admin.php
Modified : /trunk/Themes/default/Admin.template.php
Modified : /trunk/Themes/default/GenericList.template.php
Modified : /trunk/Themes/default/languages/Admin.english.php
Modified : /trunk/Themes/default/languages/Who.english.php
4864
Features / Re: New revs
« on February 17th, 2012, 10:37 AM »
(4 files, 6KB)

Revision: 1355
Author: arantor
Date: 17 February 2012 09:35:56
Message:
! Moderation filters UI can now properly update (well, delete an existing one and append a new rule on the end, but has no net difference in reality) and delete entries, as well as cleaning up empty nodes before updating. Also removed the extra UI in Security and Moderation now it has no meaningful purpose. (ManageSettings.php, ManageModeration.php, ManageModeration.template.php, ManageSettings.english.php)
----
Modified : /trunk/Sources/ManageModeration.php
Modified : /trunk/Sources/ManageSettings.php
Modified : /trunk/Themes/default/ManageModeration.template.php
Modified : /trunk/Themes/default/languages/ManageSettings.english.php


NB The UI is still not finished, not all types that can be handled through the system are actually in the interface, as user id and groups is still required to be implemented, but everything else is implemented and, so far, working.
4865
Features / Re: Privacy options
« on February 17th, 2012, 10:17 AM »
I'm not quite sure what you mean by additional test... if (empty($settings['postmod_rules'])), approved shouldn't be tested at all. Otherwise, the test needs to be approved = 1 || (approved = 0 && (t.id_member_started = $user_info['id'] || allowedTo('approve_posts')))[1]
 1. And remember, post approval is a board level permission, so in topics and message indexes where you have a board or topic id, allowedTo will function normally, but in any place outside of those, like search, recent, unread, etc. the test has to be done separately.
4866
Features / Re: Privacy options
« on February 17th, 2012, 09:50 AM »
The problem with baking something like privacy into a plugin is that other plugins may or may not use it properly.
4867
Features / Re: New revs
« on February 17th, 2012, 12:03 AM »
(3 files, 10KB)

Revision: 1354
Author: arantor
Date: 16 February 2012 23:02:31
Message:
! Moderation UI now supports editing, though it's not quite finished yet. Specifically, it takes the existing rule, lets you shape it and resaves it as a new rule because I haven't quite got replace/delete working just yet, at least not without adding another dependency (the DOM library) but in the meantime the bulk of the editing UI is basically done for now. (ManageModeration.php, ManageModeration.template.php, ManageSettings.english.php)
----
Modified : /trunk/Sources/ManageModeration.php
Modified : /trunk/Themes/default/ManageModeration.template.php
Modified : /trunk/Themes/default/languages/ManageSettings.english.php


@ This is the reason things have been slow today, getting this PITA down straight between the saving and editing stuff...
4868
Features / Re: Privacy options
« on February 16th, 2012, 11:26 PM »
It's a worthy cause and it looks like it would be quite popular, so I wouldn't give up on it, but I get the impression it does need some serious planning to make work.
4869
Features / Re: Privacy options
« on February 16th, 2012, 10:56 PM »
Quote
e.g. if I'm putting the condition at the same level as the is_approved, which is probably what 'should' be, then why not simply have the approved test inside the query_see_topic...?
Because the condition for approval is evaluated at both topic and message level. If the entire topic isn't approved, then it can safely be made part of the query_see_topic - however, test first that $settings['postmod_rules'] is non empty before adding that condition in, if it's empty, don't have the approval condition at all.

That's the thing about permissions... being able to split, merge, delete, whatever, they're all dependent on being able to see the topic. If they can't see it, they can't see it and no other granting of permissions will change that small detail, not really should it.
Quote
I have no idea... I'd tend to say yes, otherwise it gets complicated.
*nods* Then we just have to deal with the fact that approval is one method of a topic being hidden rather than being separate and something else.
Quote
There are only a few queries about topics in the admin anyway.
True enough. The one I'm really thinking of that's affected here is post counts.
Quote
I'm a bit wary of removing the patch code without checking the implementation...
That's a valid statement, I'd just wonder how far other queries have come since the Noisen patch though. Stuff like the blog changes to message/display pages for example.
Quote
BTW, if no one comments on the logo topic any longer... Does that mean I get to choose our final logo?
I think you have a pretty good idea on what I like and what I don't like, though I have the tab open still to reply to (and read, really) and I'm not that fussy. The fact that while I appreciated the idea of the fulcrum, I actually actively disliked the exact style SMF used themselves never otherwise put my off contributing ;) Seriously though, I don't mind too much provided that it's legible and nice.
4870
Features / Re: Privacy options
« on February 16th, 2012, 10:42 PM »
Yes, t.approved (and m.approved, ma.approved and all the other aliases that get used on the tables in those queries) are 'protected' but they're protected in a funky way, i.e. based on owner and a permission. I'd argue that you need to leave that component alone, as well as adding the see_topic component to said queries.

Therein lies the problem: can, or should, a topic whose privacy is not explicitly 'everyone' be able to have unapproved posts?

Any queries we've added to the code should adhere to t.approved where it's currently been used, I can't think of a single query we might have added where it wasn't respected, with the exception of anything added in the admin panel where the rules are different anyway.

I'd also argue you pretty much do have to go by what's there and not necessarily by what's in the Noisen patch because there are going to be differences now that weren't in the original SMF code, which does mean looking through approved - there are, unfortunately, quite a few of those.
4871
Features / Re: New revs
« on February 16th, 2012, 04:10 PM »
(3 files, missed the KB size, sorry)

Revision: 1351
Author: arantor
Date: 16 February 2012 15:10:05
Message:
! First version of moderation filters UI able to actually save moderation rules. It cannot yet save any types other than the ones shown in the UI, but it seems to be able to save things well enough. The handlers for body/subject are going to need serious testing however, to make sure that things are properly escaped/unescaped if necessary, this hasn't even been tested yet so it's likely broken, but that's a minor enough matter right now! (ManageModeration.php, ManageModeration.template.php, ManageSettings.english.php)
----
Modified : /trunk/Sources/ManageModeration.php
Modified : /trunk/Themes/default/ManageModeration.template.php
Modified : /trunk/Themes/default/languages/ManageSettings.english.php
4872
Features / Re: Moderation filters UI
« on February 16th, 2012, 12:01 PM »
OK, I think it's time to start working on the saving logic, because the two remaining types of moderation filter (user id and permissions) require a lot more energy on my part to implement (user id will depend on auto-suggest so I don't want to get into that until I know it's not likely to change any time soon, and permissions is complicated because I don't want to have to do anything manual to keep it updated)

But at least this way you'll be able to start using the UI properly :D
4873
Features / Re: New revs
« on February 16th, 2012, 11:59 AM »
(2 files, 2KB)

Revision: 1350
Author: arantor
Date: 16 February 2012 10:59:30
Message:
! Add case-sensitive test to subject/body area in moderation filters UI. (ManageModeration.template.php, ManageSettings.english.php)
----
Modified : /trunk/Themes/default/ManageModeration.template.php
Modified : /trunk/Themes/default/languages/ManageSettings.english.php
4874
Features / Re: New revs
« on February 16th, 2012, 11:46 AM »
(2 files, 3KB)

Revision: 1349
Author: arantor
Date: 16 February 2012 10:45:56
Message:
! Moderation filters UI now also supports subject and body tag, though it doesn't know how to differentiate case sensitivity. I do believe it's properly protecting content before inserting into the DOM (and I know somewhere between Chrome and jQuery being "helpful" I got very annoyed with it, heh) (ManageModeration.template.php, ManageSettings.english.php)
----
Modified : /trunk/Themes/default/ManageModeration.template.php
Modified : /trunk/Themes/default/languages/ManageSettings.english.php
4875
Features / Re: New revs
« on February 16th, 2012, 10:33 AM »
(2 files, 2KB)

Revision: 1347
Author: arantor
Date: 16 February 2012 09:32:38
Message:
! Warning level is now also in the moderation filters UI. (ManageModeration.template.php, ManageSettings.english.php)
----
Modified : /trunk/Themes/default/ManageModeration.template.php
Modified : /trunk/Themes/default/languages/ManageSettings.english.php