Avatar

Discussion about bug fixing and planned features for mlf 2.5 (Project organisation)

by Auge ⌂ @, Monday, March 19, 2018, 13:24 (65 days ago)

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 a 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.

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 Github issue #331.

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.

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).

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 insted 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 also Github issue #348.

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.

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Tags:
feature request, 2.5, bug, feature

Avatar

Features for mlf 2.5

by Mardor ⌂, Monday, March 19, 2018, 14:26 (65 days ago) @ Auge

A better way to manage uploaded files would be great. The last time I searched for orphaned files I scanned a database dump with a Python script to find the candidates for deletion.

It would be helpful if there was a possibility to upload other filetypes as well. At least ZIP files and PDF documents should be supported.

One proposed to make the forum program working as several forums.

I for one prefer MLF because it is a single-forum-system and no BBS.

idea number 3: Unsubscribing from e-mail-notifications

I second that. Plus: Maybe it did not discover the already existing check box but is there a way to implement a setting in the user profile to make subscriptions active by default?

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

Yes. Please.

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

… if there are no other references. See above.

idea number 6: Function to report a posting as abuse

Maybe a „like“ button would be nice, too?

Discussion about bug fixing and planned features for mlf 2.5

by Martin66 @, Monday, March 19, 2018, 21:03 (65 days ago) @ Auge

idea number 3 seems to be necessary because of the EU General Data Protection Regulation.

One more sugestion (see here): The Admin should be able to activate an automatic daily deletion of personal data when a thread will be locked. I'm not a lawyer, but I think this is necessary for legal reasons in the EU.

Martin

Discussion about bug fixing and planned features for mlf 2.5

by Kepha, Monday, March 19, 2018, 23:14 (65 days ago) @ Auge

I still would like to see categories name as a parent-name?

e.g.
mylittleforum.net/General
mylittleforum.net/Bugs
etc

---

Would like to see the option to add Tables, in a simplest way possible, no need to be complicated and too much customizable

---

Easy menu to apply/change forum colors by inserting the HEX (#FF5733)
"default-text"
"link"
"visited-link"
"background"
(possibly the logo-text and usernames)

Avatar

Discussion about bug fixing and planned features for mlf 2.5

by Auge ⌂ @, Tuesday, March 20, 2018, 09:28 (64 days ago) @ Kepha

Hello

I still would like to see categories name as a parent-name?

e.g.
mylittleforum.net/General
mylittleforum.net/Bugs
etc

Hmm, a really nice idea. But what should we do with (then) old styled links (i.e. https://mylittleforum.net/forum/index.php?mode=index&category=7) that was posted anywhere in- and outside a forum in the (then) past? It would mean to have and to nurse two parsers. At least for me a not really nice idea but it's worth to be discussed.

Would like to see the option to add Tables, in a simplest way possible, no need to be complicated and too much customizable

Add tables to what, the database or the posting with BB-Code?

If you talk about BB-code-based tables, we discussed that before (german language) and my personal experience (I also shared there) tells me to prevent such complicated structures. Even an implementation in the "simplest way possible", uncomplicated and not "too much customizable" is often to complicated to handle for the audience.

Much more simple and significantly less fault-prone is an ASCII-table in a [pre]-block like Milo proposed it.

[pre]
Datum    | Termin     | Bemerkung
15.01.17 | Tabellen   | Diskussion über das Für und Wider von BB-Code-generierten Tabellen
17.01.17 | Feierabend | aber erst um fünf Uhr abends
18.01.17 | Aufstehen  | schon wieder morgends *gnarf*
[/pre]

resulting in:

Datum    | Termin     | Bemerkung
15.01.17 | Tabellen   | Diskussion über das Für und Wider von BB-Code-generierten Tabellen
17.01.17 | Feierabend | aber erst um fünf Uhr abends
18.01.17 | Aufstehen  | schon wieder morgends *gnarf*

Easy menu to apply/change forum colors by inserting the HEX (#FF5733)
"default-text"
"link"
"visited-link"
"background"
(possibly the logo-text and usernames)

An absolutely no from my side. When one wants to change the layout and/or colours, one can change or add a theme. I know, that this is much more than only a bit of work, but the theme is the right place to work on it. We currently have exactly 130 setting items. I'm not willing to add further five to ten new settings now and to add further settings every time a forum operator wants to change a further thingamabob in the forum styles per setting for something, that can be done in another and proper way (in the CSS of the theme).

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

Discussion about bug fixing and planned features for mlf 2.5

by Auge ⌂ @, Tuesday, March 20, 2018, 10:26 (64 days ago) @ Auge

Hello

idea number 8: tabbed settings page

Since the selection of settings, that are accessible on the main-settings-page, is a bit arbitrary and further settings are more or less hidden on the enhanced-settings-page (even many administrators doesn't take notice of the link to the enhanced-settings) my idea is to display all settings in a tabbed page grouped by their meaning.

I implemented this anciently for MLF1 but it was never released. As example a screenshot of the MLF1-settings-page, tab "postings" (reduced colour table).

[image]

I am willing to implement it again for MLF2. It will need enhancements to the structure of the settings table and will result in massive enlargement of the language files because of the need of strings (name and description) for every possible setting.

Current structure of the settings table with only two fields:

CREATE TABLE mlf2_settings (
    name VARCHAR(255) NOT NULL,
    VALUE VARCHAR(255) NOT NULL DEFAULT '',
    PRIMARY KEY (name))
ENGINE=InnoDB CHARSET=utf8 COLLATE=utf8_general_ci;

As a comparision the settings table form the rework of MLF1 from the repository (latest touched three years ago):

CREATE TABLE mlf1_settings (
    name VARCHAR(255) NOT NULL,                   -- same as in MLF2, name of the setting
    VALUE VARCHAR(255) NOT NULL DEFAULT '',       -- same as in MLF2, value of the setting
    TYPE VARCHAR(30) NOT NULL DEFAULT '',         -- form field type name
    poss_values VARCHAR(160) NOT NULL DEFAULT '', -- NULL, or list of allowed values
    standard VARCHAR(80) NOT NULL DEFAULT '',     -- default value
    cat VARCHAR(20) NOT NULL DEFAULT '',          -- category of setting (determines tab of the setting)
    UNIQUE KEY setting (name))
ENGINE=InnoDB  DEFAULT CHARSET=utf8;

I introduced this idea once two years ago and Milo gave me then his o.k. @Alex: would it be ok to change the settings that way?

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Discussion about bug fixing and planned features for mlf 2.5

by Martin66 @, Wednesday, March 21, 2018, 08:10 (63 days ago) @ Auge

idea Nr Whatever:

A User should have the possibility to activate E-Mail notification for any Posting, even without publishing something inside this thread by himself.

As written before, each User needs the Chance to deactivate any activated notification also.

Martin

Avatar

Discussion about bug fixing and planned features for mlf 2.5

by Auge ⌂ @, Wednesday, March 21, 2018, 08:40 (63 days ago) @ Martin66

Hello

idea Nr Whatever:

Here in this thread it is the number nine (in ciphers: 9). :-)

A User should have the possibility to activate E-Mail notification for any Posting, even without publishing something inside this thread by himself.

This is a much more valid idea than your first one. It's the one I described in the last paragraph of this posting (Abonnements, subscriptions). We will see, what can be implemented in an adequate way and with an adequate effort. I actually work on idea 4b from the opening posting.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

question about idea #3, unsubscribing feature

by Auge ⌂ @, Monday, April 23, 2018, 14:32 (30 days ago) @ Auge

Hello

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 Github issue #331.

Would it be enough to provide an unsubscribing link in the e-mail-notification? An addition with a higher effort would be to provide a page with a list of subscriptions in the users profile (was requested in that posting). I know, the best would be to have both ways but I want to limit the effort to the necessary.

IMHO it's worth to implement the link in the e-mail first and to add the page afterwards. With the link and it's processing we have the infrastructure to get such a page working.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

question about idea #3, unsubscribing feature

by Magma, Wednesday, April 25, 2018, 18:24 (28 days ago) @ Auge

Personally I'm just happy with a link in the notification email that the guest or user can click on or copy and paste to unsubscribe from further notifications.

RSS Feed of thread
powered by my little forum