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.
6391
Features / Re: New revs
« on February 19th, 2012, 01:29 PM »
rev 1364
(7 files +1, 2kb)
* More fixes and tweaks to Weaving and Wine. Getting tricky eh? (skins/*, skin/Wine/*)
(7 files +1, 2kb)
* More fixes and tweaks to Weaving and Wine. Getting tricky eh? (skins/*, skin/Wine/*)
6392
Features / Re: New revs
« on February 18th, 2012, 11:46 PM »
rev 1363
(6 files, 8kb)
! Fixed Wine & co to behave just like Weaving (new auto-suggest styling, new New notifications, etc), added a couple of files I forgot, and fixed a few errors in Weaving as well. (index.css, sections.css, Wine/.htaccess, Wine/index.css, Wine/index.php, Wine/sections.css)
(6 files, 8kb)
! Fixed Wine & co to behave just like Weaving (new auto-suggest styling, new New notifications, etc), added a couple of files I forgot, and fixed a few errors in Weaving as well. (index.css, sections.css, Wine/.htaccess, Wine/index.css, Wine/index.php, Wine/sections.css)
6393
Features / Re: New revs
« on February 18th, 2012, 10:23 PM »
rev 1362
(all Skins files, 64kb)
* Moved Wine skin down a level (and Warm and Wuthering with it), and moved Worg up a level to replace it as the default skin. Hopefully I didn't screw it up too much[1]... Worg now has the codename 'Weaving'. Started work on adapting Wine to use Weaving's additions. (skins/*)
(all Skins files, 64kb)
* Moved Wine skin down a level (and Warm and Wuthering with it), and moved Worg up a level to replace it as the default skin. Hopefully I didn't screw it up too much[1]... Worg now has the codename 'Weaving'. Started work on adapting Wine to use Weaving's additions. (skins/*)
| 1. | Actually I moved Wine to its own folder, and then manually moved some of its files back to the root, while I should have SVN Moved them. Should be okay though. |
6394
Features / Re: Privacy options
« on February 18th, 2012, 08:21 PM »
The only subquery is when contacts are being looked through. Otherwise it's as easy as usual.
Crap... So, I've got this query in SSI.php (always...)
Code: [Select]
After some consideration, it doesn't really make sense to call query_see_topic at the beginning. Because if I'm not the author, then it'll return false, even before evaluating the allowedTo('approved_posts') that would automatically give me a positive and thus skip the approved test...
So I would logically put that instead of the t.approved test, but not in a 'higher' level place.
That makes sense, right?
Now... What about approved_posts? Is this a forum-wide permission only? If yes, then it WOULD make sense to have it in our query_see_topic test, wouldn't it...? Plus, I've seen plenty of places where SMF just tests for postmod_active, and not for that permission... That would allow us to 'clean up' that code.
Any opinions?
Seriously everyone... Just have a look at ssi_recentPosts().
It doesn't test for allowedTo('approve_posts') before it runs m.approved = 1... Does that make sense? AFAIK, SSI calls can and should support permissions...
Bump.
Posted: February 18th, 2012, 09:57 AM
Crap... So, I've got this query in SSI.php (always...)
WHERE {query_see_topic}
AND att.attachment_type = 0' . ($attachments_boards === array(0) ? '' : '
AND m.id_board IN ({array_int:boards_can_see})') . (!empty($attachment_ext) ? '
AND att.fileext IN ({array_string:attachment_ext})' : '') .
(!$settings['postmod_active'] || allowedTo('approve_posts') ? '' : '
AND t.approved = 1
AND m.approved = 1') . 'After some consideration, it doesn't really make sense to call query_see_topic at the beginning. Because if I'm not the author, then it'll return false, even before evaluating the allowedTo('approved_posts') that would automatically give me a positive and thus skip the approved test...
So I would logically put that instead of the t.approved test, but not in a 'higher' level place.
That makes sense, right?
Now... What about approved_posts? Is this a forum-wide permission only? If yes, then it WOULD make sense to have it in our query_see_topic test, wouldn't it...? Plus, I've seen plenty of places where SMF just tests for postmod_active, and not for that permission... That would allow us to 'clean up' that code.
Any opinions?
Posted: February 18th, 2012, 12:49 PM
Seriously everyone... Just have a look at ssi_recentPosts().
It doesn't test for allowedTo('approve_posts') before it runs m.approved = 1... Does that make sense? AFAIK, SSI calls can and should support permissions...
Posted: February 18th, 2012, 03:06 PM
Bump.
6395
Features / Re: New revs
« on February 18th, 2012, 05:50 PM »
rev 1361
(4 files, 4kb)
+ In topic pages, profile icons will now have a low opacity setting, with an animation to reset it on hover. It should make the icons less intrusive, whatever we decide to do with them. (Worg/sections.css)
* Rewrote a bit of the Change Skin page to show a fieldset-based layout[1], instead of regular headers. This should give a bit more space for long lists of skins. (Themes.template.php, Worg/index.css, Worg/sections.css)
* A few extra styling tweaks. (Worg/index.css)
! Debug info sometimes generates a minor error if called for guests. Yeah, I know, no one would normally enable debug info for guests. (ViewQuery.php)
(4 files, 4kb)
+ In topic pages, profile icons will now have a low opacity setting, with an animation to reset it on hover. It should make the icons less intrusive, whatever we decide to do with them. (Worg/sections.css)
* Rewrote a bit of the Change Skin page to show a fieldset-based layout[1], instead of regular headers. This should give a bit more space for long lists of skins. (Themes.template.php, Worg/index.css, Worg/sections.css)
* A few extra styling tweaks. (Worg/index.css)
! Debug info sometimes generates a minor error if called for guests. Yeah, I know, no one would normally enable debug info for guests. (ViewQuery.php)
| 1. | Yes, I know, it's NOT our default fieldset styling... That's because our fieldsets are not made for inclusion within a windowbg or windowbg2 item -- bummer. |
6396
Features / Re: Privacy options
« on February 18th, 2012, 02:00 AM »
I was working on this in the short time I was away... Managed to make it work as a WHERE argument.
Heck, it's really very easy at this point...
admin? WHERE 1=1
guest? WHERE t.approved=1 AND t.privacy="default"
member? WHERE (t.id_member_started=myself OR (t.approved=1 AND (t.privacy="default" OR other privacy settings...))
My main breakthrough is the t.id_member_started test... It's totally upsetting that I never optimized the query into testing for that FIRST... :lol: I used to do it differently, nice waste of time. Then again, at the time I was on a SQL server that didn't support subselects... Which I need for my 'contacts' privacy test.
As for the t alias... I'm afraid there's nothing that can be done. I can't just test for "privacy" because the query might be mixed in with a table that has a privacy field in it... Unless I rename the field, but, well... I'd also have to do that for the 'approved' field in topics because I'm definitely inserting it into query_see_topic. Really, not sure about the whole renaming thing.
A bit of an issue maybe...
Didn't really think about this -- what if the user has moderation perms on the board that a private topic is on...? It should be visible to them, shouldn't it...?
Maybe this could be tested though $user_info['mod_cache']['mq']... But the problem I mentioned, is that it expects the query to have a "boards AS b" in it... :-/
I don't know how to deal with this particular case.
Heck, it's really very easy at this point...
admin? WHERE 1=1
guest? WHERE t.approved=1 AND t.privacy="default"
member? WHERE (t.id_member_started=myself OR (t.approved=1 AND (t.privacy="default" OR other privacy settings...))
My main breakthrough is the t.id_member_started test... It's totally upsetting that I never optimized the query into testing for that FIRST... :lol: I used to do it differently, nice waste of time. Then again, at the time I was on a SQL server that didn't support subselects... Which I need for my 'contacts' privacy test.
As for the t alias... I'm afraid there's nothing that can be done. I can't just test for "privacy" because the query might be mixed in with a table that has a privacy field in it... Unless I rename the field, but, well... I'd also have to do that for the 'approved' field in topics because I'm definitely inserting it into query_see_topic. Really, not sure about the whole renaming thing.
Posted: February 18th, 2012, 01:28 AM
A bit of an issue maybe...
Didn't really think about this -- what if the user has moderation perms on the board that a private topic is on...? It should be visible to them, shouldn't it...?
Maybe this could be tested though $user_info['mod_cache']['mq']... But the problem I mentioned, is that it expects the query to have a "boards AS b" in it... :-/
I don't know how to deal with this particular case.
6397
Features / Re: Privacy options
« on February 18th, 2012, 12:16 AM »
Instead of (I tried to find the query you mentioned...)
Code: [Select]
We could have that:
Code: [Select]
See..? Does it make sense? It doesn't save any time in the query if it has to execute the approved test, but at least it'd work...
BTW, what did we decide already, regarding the position for {query_see_topic}...? As an INNER insertion, or a subselect in the WHERE?
Bump..?
WHERE t.id_board = {int:current_board}' . (!$settings['postmod_active'] || allowedTo('approve_posts') ? '' : '
AND (t.approved = 1 OR (t.id_member_started != 0 AND t.id_member_started = {int:current_member}))') . '
AND ' . $sort . ' ' . $sort_methods[$sort_by]['cmp'] . 'We could have that:
WHERE {query_see_topic} AND t.id_board = {int:current_board}' . (!$settings['postmod_active'] || allowedTo('approve_posts') ? '' : '
AND (t.approved = 1 OR (t.id_member_started != 0 AND t.id_member_started = {int:current_member}))') . '
AND ' . $sort . ' ' . $sort_methods[$sort_by]['cmp'] . 'See..? Does it make sense? It doesn't save any time in the query if it has to execute the approved test, but at least it'd work...
Posted: February 17th, 2012, 07:17 PM
BTW, what did we decide already, regarding the position for {query_see_topic}...? As an INNER insertion, or a subselect in the WHERE?
Posted: February 17th, 2012, 07:18 PM
Bump..?
6398
Off-topic / Re: How karma favours the wise - or not, as the case may be
« on February 17th, 2012, 07:10 PM »
$3000 is cheap, I'd say! Before taxes?!
6399
Features / Re: Selectbox
« on February 17th, 2012, 05:53 PM »
I don't know... I'm afraid it'd break something somewhere.
Any opinions?
(Also, the select box is styled entirely manually, except for the arrow. I like manual styling better :P)
Any opinions?
(Also, the select box is styled entirely manually, except for the arrow. I like manual styling better :P)
6400
Features / Re: Don't know if I shared it publicly or not
« on February 17th, 2012, 05:52 PM »Well, it would normally only be shown to people who have access to the AeMe admin or moderate panels, i.e. people who can already see it anyway, so it doesn't need to be there. But somewhere where it lists who can approve would be useful - I'm just not keen on it being publicly visible (which it would be in the credits page)... perhaps in the Media permissions page?
Why don't you want it to be visible to all?
Gallery moderators should be known. First of all, it gives a sense of responsibility to them. Also, sometimes a visible credit is pretty much the only way you're gonna get "paid" for your volunteer work, so you might as well credit everyone on a specific site...
Are you trying to say that you don't want the credits page to list the forum moderators, either...?
I know, but when I first removed it, it somehow felt like it had devalued the work that had been put in, you know? I'm just a bit fussy about making sure people get due recognition.
Well, it would be trivial enough to capture the date on install and push it into settings rather than amSettings and then display it there.
OTOH -- could be made even simpler... Since Wedge gets a list of monthly stats, why not simply give the first month of activity in the first stats area...? It's something that's already calculated, innit? Or maybe it's just the year... Not sure.
6401
The Pub / Re: Logo Madness
« on February 17th, 2012, 05:43 PM »
Hmm... Let's do it this way:
Try to determine (give me a filename for it) your:
- favorite background (I assume it's the blue one, but most are a bit different from each other, mostly in contrast)
- favorite font
- favorite font color (I assume reddish)
- favorite font position (center, right?)
- favorite logo images (I'm saying images because there are too many to find a good compromise I think :P mi9, mice and mide are the main ones.)
- favorite logo position (well inside the element, or overflowing like in the first couple?)
Try to determine (give me a filename for it) your:
- favorite background (I assume it's the blue one, but most are a bit different from each other, mostly in contrast)
- favorite font
- favorite font color (I assume reddish)
- favorite font position (center, right?)
- favorite logo images (I'm saying images because there are too many to find a good compromise I think :P mi9, mice and mide are the main ones.)
- favorite logo position (well inside the element, or overflowing like in the first couple?)
6402
Features / Re: New revs
« on February 17th, 2012, 05:32 PM »
rev 1360
(7 files +1-9, 7kb)
* Created an 'unused' folder in the other/images folder, and moved some pics there, including the changelog bullets from AeMe. (other/images/*, images/aeva/bullet_*.png)
+ Added a link to php.net's Safe Mode page, just in case admins aren't aware of what it is. (Admin.language.php)
* Translation. I hope I didn't forget anything... (Admin.french.php, ManageSettings.french.php, Who.french.php)
! #admin #main trumps all other CSS styles, so I had to override the hr margin for inner menus. (admin.css)
- Removed changelog bullets. (media.css)
(7 files +1-9, 7kb)
* Created an 'unused' folder in the other/images folder, and moved some pics there, including the changelog bullets from AeMe. (other/images/*, images/aeva/bullet_*.png)
+ Added a link to php.net's Safe Mode page, just in case admins aren't aware of what it is. (Admin.language.php)
* Translation. I hope I didn't forget anything... (Admin.french.php, ManageSettings.french.php, Who.french.php)
! #admin #main trumps all other CSS styles, so I had to override the hr margin for inner menus. (admin.css)
- Removed changelog bullets. (media.css)
6403
Features / Re: Don't know if I shared it publicly or not
« on February 17th, 2012, 05:27 PM »
- I don't believe it's important to list these persons there... Maybe, maybe, we could put them in the credits page? You know, in the first part of the page... But only if one of them wasn't listed before (i.e. not a mod/admin.) Then we list everyone.
- Speaking of credits... I did say I didn't want to keep the AeMe copyright stuff. Karl Benson and Dragooon are already credited as consultants in the credits page (and they're here to stay), and they're credited in the individual files where needed. I think my name is already too much on that credits page, especially in the French version where it's added one more time... :P
- 'Installed on' is really a freebie from Dragooon, I believe. It can go. It's here to find out when a forum was installed: take the date of the very first post (regardless of permissions)... If it's the automatic post by Wedge, then it's the real install date. Otherwise, it's the real 'first use' date, which to me is more interesting. This could go into the Stats page...
- Speaking of credits... I did say I didn't want to keep the AeMe copyright stuff. Karl Benson and Dragooon are already credited as consultants in the credits page (and they're here to stay), and they're credited in the individual files where needed. I think my name is already too much on that credits page, especially in the French version where it's added one more time... :P
- 'Installed on' is really a freebie from Dragooon, I believe. It can go. It's here to find out when a forum was installed: take the date of the very first post (regardless of permissions)... If it's the automatic post by Wedge, then it's the real install date. Otherwise, it's the real 'first use' date, which to me is more interesting. This could go into the Stats page...
6404
Features / Re: Selectbox
« on February 17th, 2012, 05:02 PM »
..Because they're already styled..? Or so?
My main issue with non-select box styling is that select boxes have this nice rounded corner effect, but I want the default skin to have straight corners, and I have trouble determining whether I should give select boxes rounded corners or not. Hence, same issue for the rest...
My main issue with non-select box styling is that select boxes have this nice rounded corner effect, but I want the default skin to have straight corners, and I have trouble determining whether I should give select boxes rounded corners or not. Hence, same issue for the rest...
6405
Features / Re: Don't know if I shared it publicly or not
« on February 17th, 2012, 01:28 PM »
Move the changelog, too. The format is special and needed ;)