Hello

This is a thread to collect ideas and plans for features and bugs that should gets implemented/solved with version 2.5. At the moment this is a list of proposals. I collected everthing I found whithin the foirst four pages. You can read about a few more proposals in the issues list on Github.

Idea number 1: User groups

Because of a repeatedly pleaded proposal [1] I want to bring it into the discussion. One proposed to make the forum program working as several forums. He wished to have this function from inside one installation instead by installing more then one forum (and possibly sharing some of the database tables) and to regulate the access of the users to the forums.

IMHO this would cause a massive change in the code base. This would not be preferable. On the other hand it should be possible to handle this with user groups and their access to the categories.

Then I found a posting in the collect feature requests and bugs for version 2.4 thread where Milo proposed the feature of user groups. Seems to be a plausible idea not only for me.

Quote:

P.S. Further feature: Define groups for users (and special categories).

What do we need?

- add a database table for the groups
- add a database table for the group-user-relation (a user can be member of several groups)
- add a database table for the group-category-relation (a group can have access to several categories, a category can be accessible for several groups)
- remove column accession from categories table (would be obsolete with the new structure)
- PHP-code to handle the access to the categories by the user as a member of groups instead by her/his rank (actual stucture: unregistered visitor = NULL, registered user = 0, moderator = 1, administrator = 2)

idea number 2: Make pinned threads independent from the category selection

If the groups-feature would be implemented, Magmas feature request (number 2 in this posting) for showing (special) pinned threads in every selection of one or more categories a user can switch to gets more relevance.

See therefore also Github pull requests #471 and #472. (implemented)

idea number 3: Unsubscribing from e-mail-notifications

A the moment an author of a posting can not unsubscribe from a notification when she/he has no access to editing the posting. The user should be able to disable the subscription. This is a request made by Magma.

See therefore also the Github issues #331, #398 and the pull request #399.

The feature got introduced with version 2.4.14. So far it is implemented.

idea number 4a: Store the information about the uploader of an image

Tie the upload to the uploading user account or the information that this was an upload of an unregistered visitor. This would make a new table necessary.

See therefore also Github pull request #451 (implemented for new uploads).

idea number 4b: Enhanced administration of uploaded images

The administration of uploads in a forum is at the moment everything else than convenient (IMHO it's a disgrace). One as an admin sees only five small images at one time in the small popup (like every user) and has to delete every single image one by one. I plan to introduce a new full-size page in the admin area for the uploads-handling. Page should provide data of the image itself, it's insertion in postings and the uploader of the image (if 4a gets consent).

See the associated thread (basically implemented).

idea number 4c: Delete images when deleting a posting where these images are included

If a posting or a thread gets deleted from the database, images that would be orphaned otherwise should get deleted too. This is a request made by Magma.

idea number 4d: Delete all unused images, uploaded by one user when closing the account

The images, a user has uploaded, should also get removed from the forum when the user removes her/his user account when the images are nowhere in use (in a posting of any user or visitor). [edit]When the posting remains, also the images, that are included in these postings, should remain.[/edit]

idea number 5: Make it possible to send e-mails over a SMTP-interface instead over the PHP-function mail()

As requested several times and stated in an answer to one of the requests we plan to test a PHP-SMTP-library as the alternative way to send e-mails.

See therefore Github issue #348 and the pull request #498 (implemented).

idea number 6: Function to report a posting as abuse

As requested (sorry, I didn't find the posting with the request) registered users might be able to report entries i.e. as spam, for abuse of the forum rules or for unpoliteness. See therefore also Github issue #156.

idea number 7: Limited moderation of entries (only when posted by specified users)

Danielb987 proposed a limited moderation feature, where only entries from specified users should get moderated.

Tschö, Auge

[1] I forwarded one of the e-mails in question to the projects allocation address.