Category: "Popular demand"
Here's how I think this should be implemented:
Right now we only have an EDITOR role who can create anything, edit anything and delete anything.
The extra granularity we need is this:
- being able to only create/edit one's own stuff without being able to touch what belongs to others.
- being able to only edit stuff that belongs to someone with a user LEVEL lower than yours.
- being able to only edit stuff that belongs to someone with the same user LEVEL as yours.
(I am talking abou the user LEVELs you see on the user list screen. Those are basically useless currently and waiting for the above implementation.).
(For the sake of simplicity I am deliberately leaving out the "delete" problem. Let's talk about it later, once the "edit" problem is clear :)
The 2 additional LEVEL based cases allow for collaborative editing having a hierarchy of competence.
Furthermore on the lower levels, you might want to allow people to only post drafts and then have someone with a higher level validate those drafts.
In the User Interface, this would translate to the following:
We keep the same "wide" checkbox table we already have, but we replace the 5 checkboxes in the columns for Published, Protected, Private, Draft & Deprecated.
We replace those checkboxes with select lists. In a full implementation those select lists would have all of the following choices:
- < Own Level
- ≤ Own Level
Of course the current implementation is equivalent to only having the following choices:
- All (except for PRIVATE, see below)
NOTE: for the PRIVATE status, even in the full implemtation, we would only have:
Because only yourself can see the private posts, so there it doesn't make sense to have editing rights on stuff you can't even see. (We might actually want to allow some super admin to see other people's private stuff but that's different from what we have now and would probably bug quite a few users. "If you don't want people to post private stuff on your blog don't allow them from the beginning").
In the Simple display UI, this would add the following new radio options:
o Not Member
o NEW: Writer (can post own stuff)
o NEW: Editor (can edit < own level)
o RENAMED: Moderator (can edit anything; this is the existing "editor" level)
check/uncheck all won't make sense any longer and can probably be removed, since you can select the admin radio in the "Debug" mode. Maybe we should make the debug mode a feature and call it "combined" or sth like that.
Okay this is a bit long but nothing too weird I think. Does it make sense?
PS: I've said it before, but someone should remove the 'non members' part from those screens and replace it with a text entry named "add member:"
Add these ping destinations:
Here's how MT handles the thing.
We need compatibility with that as a minimum.
# Entry Body
# Extended Entry
Collectively these two fields make up the body of your entry. You can use the two fields however you like: you could split up your entry over the two fields, or you could completely ignore the Extended Entry text and enter only the Entry Body text. Movable Type allows you to split up your entry for more flexibility in the display of that entry; for example, if you write very long entries, you may not want your entire entry on your index pages. You can use the two fields to control what gets displayed, and where.
You can enter an excerpt from your entry, or use this field to provide a summary of the content therein. If you do not provide an excerpt, it will be automatically generated (when specified in a template using the MTEntryExcerpt tag) by selecting the first twenty (20) words from your entry, followed by an ellipsis.
Expiration of comments (general and blog setting, perhaps overridable per post!?!) would help to prevent spam on old entries.
You probably see hundreds of post about MT 3.0 and it's new pricing policy. After typekey case (community doesn't seems enthousiastic about this new product) things are going bad : what is the place of b2evo here ?
MT Community is posting about migrating to Wordpress or Textpattern but almost nothing about b2evo :( ... while b2evo could be a better solution for this user requirements : multi blog/authors with good features such as antispam that lacks in MT ... We also see a few MT users posting in forums about migration tools from MT to b2evo.
Import from pmachine, MT, blogger, greymatter, livejournal ... is really a must have feature today is we want to take advantage from MT community moving to other blog software. In forum Francois said he'll look at this as soon as 0.9 will be released :)
You people are great developpers, you've implemented lots of features that most of powerusers want. The 0.9 release also focus on newbies with auto install, posts in B blog that explain lots of things and all much more. Manual and communication with community is also better with this FR blog and with wiki. We have almost all ... perhaps we miss a designer and a PR.
Simple, powerfull, alive, great community ... b2evo has everything to become a leading bloog tool if people knew it better
links about MT 3.0 and people talking about mirgation to other tools :
- blog of Michel V. original developper of b2
- Dive into Mark
- MT or WP
- For those about to move
- Embruns (French)
=> Edit : MT community looking for new blo tool is moving from MT forum to Forum4bloggers. Specific categorie for people looking for a new blog tool is here . Should we look at this and help advice (not spam) them if they are potential b2evo users ?
Add a plugin with buttons for fonts, colors... (a lousy plugin for lousy users)
The ability to order items (posts and categories). Display could then be sorted by date, ordering, alphabetically, or some other unique way. This would be useful for blogrolls and the display of categories.
Needed to implement: field added to appropriate database tables ('ordering' seems to be the defacto standard), interface to handle ordering via admin interface. Up/down arrows displayed on a list would be an easy UI way to handle this.
Possible problems: moving items around can get sticky. Mambo does a good functional job of this (see /includes/database.php, function updateOrder() for an example).