Sphene Community Tools

Community

Copyright © 2007-2018 by Herbert Poul

You are not logged in.
Login
Register

Change Language:



AddThis Social Bookmark Button

A Django site.

Powered by Sphene Community Tools
Board » General » Feature Discussions » Two new features: post moving (thread split) and option to not leave info about moved thread.

Page: 1 2 Next

I'd like to have two (or three) new features in SCT. I'm able to create them, but first I'd love to hear any opinions.

1. Allow Admin to decide if he wants to leave information about moved thread in original place. I think this can be easily done by adding checkbox field to Move Thread form, and by deleting ThreadInformation in move view (instead of setting status as THREAD_MOVED)

2. Allow Admin to split thread into two threads (moving specific posts).
This would be something similiar to moving whole thread but concerning only Posts. Admin would be able to click 'Move post' link and select new category for it. Additionally Admin can decide to move all subsequent posts (created after selected one) with it.
New thread will be created starting from moved post.

3. Join threads.
Not so important for me, but... would be nice to have it.
Joining is something like moving threads/posts into another, existing threads (appending).
This is a bit harder to create, I think.

So... opinions?!
well .. i think moving without a notice would be quite useful (i wanted to have that once or twice :) ) - but i think it should be configurable in settings.py - some webmasters might not want to give admins this possibility..

as for the other two features.. i'm not sure if this is really useful in a normal discussion forum .. because if a post is really off-topic chances are that subsequent replies will be both .. on-topic and off-topic .. so i would say splitting a thread in half usually makes not much sense.

joining on the other hand could be useful for a Q&A type of forum if a question was already asked for .. although this might be better off simply beeing marked as "duplicate" (both ways)

just thinking out loud here.. i wonder what your use cases would be for those two features?
Hey, we have Signatures !!! Great, isn't it ? ;)
I've created simple patch to allow admin to decide whether to leave information about moved thread:
http://code.google.com/p/sct-project/issues/detail?id=184

You're right that splitting thread in half might not be a good idea, but what about moving only one post?
The use case for this might be when Admin sees that off-topic post is created in thread (just one off-topic post). What can admin do? Currently he can hide/delete/annotate the post. I think that moving into new thread (creating thread from moved post) is better solution (at last sometimes).
Also, I was thinking about something like Trash category, where posts are removed after specified time, and where users may see what has happened with their messages. I've seen discussions like 'Where is my post!?' on some discussion boards. Trash is solution for this.

Another thing. If joining posts is implemented then moving post into existing thread (join) may allow admin to create whole new thread from off-topic posts.
I've created a patch to allow moving individual posts. Please review:
http://code.google.com/p/sct-project/issues/detail?id=188
I've created a patch to allow moving individual posts. Please review:
http://code.google.com/p/sct-project/issues/detail?id=188
Any opinions?
looks good.. although i'm not sure how much features the forum UI can handle :) but it's only an admin option .. so i don't really mind so much ..

anyway.. i think this will be the last feature to be added for this release, i have to finally wrap up and create a 0.6 release :) i guess i get right on it.. it seems the only thing left would be: http://code.google.com/p/sct-project/issues/detail?id=181 - i'm currently committing that too..

as for django 1.0 support.. i guess i'll keep it for 0.6 .. and then forget about it and make it 1.1 compatible - that should be enough i guess.


btw - what is not PEP 8 compliant in the rest of SCT? i haven't completely read the PEP i guess, but i try to write as clean as possible :)

--- Last Edited by Herbert Poul at 2010-01-04 13:18:09 ---
Hey, we have Signatures !!! Great, isn't it ? ;)
looks good.. although i'm not sure how much features the forum UI can handle :) but it's only an admin option .. so i don't really mind so much ..

anyway.. i think this will be the last feature to be added for this release, i have to finally wrap up and create a 0.6 release :) i guess i get right on it.. it seems the only thing left would be: http://code.google.com/p/sct-project/issues/detail?id=181 - i'm currently committing that too..

as for django 1.0 support.. i guess i'll keep it for 0.6 .. and then forget about it and make it 1.1 compatible - that should be enough i guess.


btw - what is not PEP 8 compliant in the rest of SCT? i haven't completely read the PEP i guess, but i try to write as clean as possible :)
Great news! I'll try to send you updated polish translation files soon.

PEP 8. My code is also not always fully compliant with it :) but in this case I meant mainly about white spaces in the code. Something like:

thread_list = thread_list.order_by( '-sticky_value', '-thread_latest_postdate' )

or
def showCategory(request, group, category_id = None, showType = None, slug = None)


According to PEP 8:
Avoid extraneous whitespace in the following situations:

- Immediately inside parentheses, brackets or braces.
      Yes: spam(ham1, {eggs: 2})
      No:  spam( ham[ 1 ], { eggs: 2 } )

(...)
Don't use spaces around the '=' sign when used to indicate a
keyword argument or a default parameter value.


There are also very ugly intendations in community/models.py.
Great news! I'll try to send you updated polish translation files soon.
cool, that would be great.. so i'll update the german translations and we've got two fully up to date languages beside english.. i think that's great :)


PEP 8. My code is also not always fully compliant with it :) but in this case I meant mainly about white spaces in the code. Something like:


ah ok.. that makes sense.. i always wondered what is nicer... now i don't have to care any more :)

There are also very ugly intendations in community/models.py.


hmm.. really? i usually let emacs handle my indentations :)
Hey, we have Signatures !!! Great, isn't it ? ;)
There are also very ugly intendations in community/models.py.
hmm.. really? i usually let emacs handle my indentations :)

Emacs? I heard Vim is better ;) but I prefer Netbeans.
Take a look at: http://dpaste.com/140883/
Attributes of Navigation have 8 spaces while CommunityUserProfile's just 4.
oops, you are right, that's just ugly .but i fear i can't give emacs the blame here :(
4 spaces are the way to go :)

(and, for development i prefer emacs.. i only use vim for configuration files and stuff ;) i also don't really like netbeans.. for java development i always use eclipse :) )
Hey, we have Signatures !!! Great, isn't it ? ;)

Page: 1 2 Next

Please login to post a reply.



Powered by Sphene Community Tools