View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005792 | Composr | cns_warnings | public | 2024-06-28 22:53 | 2024-07-22 21:03 |
| Reporter | Patrick Schmalstig | Assigned To | |||
| Severity | Feature-request | ||||
| Status | non-assigned | Resolution | open | ||
| Product Version | 11.alpha4 | ||||
| Fixed in Version | |||||
| Summary | 0005792: Add privilege and access restrictions as punitive action | ||||
| Description | Add a cns_warnings hook allowing to define multiple privilege and/or access restrictions as part of a punitive action. This will be complicated to implement on a UI standpoint, but here's my idea (with some JavaScript involved): * The UI field itself is a textarea where you put in XML. * Above the field are JavaScript-controlled inputs. * The first line has a searchable dropdown of privileges which can be restricted, plus a date field for "until", and an "Add" button. * The second line has inputs to define access restrictions on zones, categories, and/or pages... plus an "until" date field and an "Add" button. * When an Add button is clicked, JavaScript will populate a new XML entity for the chosen options in the primary UI field and then clear out the inputs (so another one can be added). On actualisation, the XML is parsed accordingly, records added into the appropriate tables, and a punitive_action record also added referencing the relevant privilege / access record. We will also need to add "the_value" to all the member access tables so we can define a negative (denied) access record (like we do for privileges). And this takes priority if a similar record has a positive (granted) assertion. | ||||
| Additional Information | This will allow site administrators to add even more fine-grained control over how they moderate problematic users by restricting specific privileges or areas of the site which they've caused problems. It also allows us to say we now (sort-of) have a UI for these non-UI / rarely used tables. | ||||
| Tags | Roadmap: Sponsorship | ||||
| Time estimation (hours) | |||||
| Sponsorship open | |||||
|
|
Automated message: This issue was created using the Report Issue Wizard on the Composr homesite. |
|
|
This is a lot of work, for I think very advanced Composr usage. For most sites, Probation should be fine (already allows changing of privileges). Or just manually moving someone to another group. Maybe a feature whereby you could have multiple Probation groups, and you choose which, would be a reasonable middle-ground. I wouldn't advise spending so much effort on making Composr do more and more, I think our effort should really on be making it more acceptable to a wider audience. |
|
|
I'd think the ability to choose multiple probation groups would be even more complicated because of how implicit groups operate and how Composr gets / searches for the probation group. I'm going to switch this to Sponsorship. It is likely something I'll need personally for a v11 site WIP which I'll develop myself and maybe offer as a non-bundled addon. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-06-28 22:53 | Patrick Schmalstig | Tag Attached: Roadmap: Over the horizon | |
| 2024-07-22 19:58 | Chris Graham | Note Added: 0008862 | |
| 2024-07-22 21:03 | Patrick Schmalstig | Note Added: 0008871 | |
| 2024-07-22 21:03 | Patrick Schmalstig | Tag Detached: Roadmap: Over the horizon | |
| 2024-07-22 21:03 | Patrick Schmalstig | Tag Attached: Roadmap: Sponsorship |
