Issue: XF2.x: 1) Admin cp: collapsible user permission groups, 2) Better indication of a contributor's own pending (moderated) edit, 3) Create New Page tabs overhaul

Issue Tools
- View Changes

March 31, 2019 6:24 AM
ACL

Regular Member
XF2.x: 1) Admin cp: collapsible user permission groups, 2) Better indication of a contributor's own pending (moderated) edit, 3) Create New Page tabs overhaul

At this time I have threetwo suggestions for VaultWiki 4.1 on XenForo 2.x.

1) Admin cp: User group permissions (and access masks) suggestion (XF2.x)

Suggestion part 2: Make permission blocks collapsible, e.g. data-xf-click="toggle" and css classes collapseTrigger/block-body--collapsible. Example PHP and screenshot: https://www.vaultwiki.org/issues/5694/#note31947

Suggestion part 1: Change "Staff Permissions" to "Wiki Moderator Permissions" (or just "Moderator Permissions"). This would then match the word choice in "VaultWiki: Miscellaneous" options (Usergroup for Wiki Moderators).

2) Moderated status indicator for contributor's pages/edits suggestion

XenForo allows posters to view their own post/thread while it is pending moderation, albeit with various indicators of the thread/post's current moderated status. This provides reassurance to content creators that their submission hasn't been lost and that there is no need to submit it again. For VaultWiki, the following would be welcome:

Moderated new page
* In lists where a moderated wiki page would ordinarily appear if it were approved, consider allowing the contributor to see their own pages that are pending moderation (as long as they have view permission for that area). Like XenForo threads, the moderation shield fa icon could be displayed in lists with an "Awaiting approval" tooltip.

* On the page itself, display a message under the title, e.g. phrase(awaiting_approval_before_being_displayed_publicly)

Moderated page edit
* On the page itself, display a suitable message under the title to the contributor that describes the state and who can view it, such as "A newer version of this page is awaiting approval before being displayed publicly"

3) Create new page 'Edit' tab and other tabs clutter during page creation. Resolved in Beta 2, thank you
This item was reported under its own issue, #5740.

Right now, there is insufficient distinction between the appearance of the Create new page form and the Edit area form.

The biggest issue I have is that the selected tab in the tabs block is "Edit", and what is worse is that it hyperlinks to the containing Area's edit page (?do=edit). I think this should be attended to at a minimum.

I think a lot of the tabs in this block could be skipped while creating a page, since they refer back to the parent Area. I would like to see this simplified to two tab options:

Area - a link back to the parent Area where the new page is to be saved (or Page/Index if not applicable)
Create/New - a selected tab without any link

If I am in the middle of creating the page "Bananas" within a "Fruits" Area, then the most of the other tabs (which refer to containing "Fruits" Area) are irrelevant here, e.g. View source code, Report page, Manage synonyms, etc.]

Issue Details

Issue Number 5694

Issue Type Feature

Project VaultWiki 4.x Series

Category Editing Pages

Status Implemented

Priority 7 - Minor Features / Enhancements

Suggested Version 4.1.0 Alpha 3

Implemented Version 4.2.0 Alpha 1

Milestone (none)

Software DependencyXenForo 2.x

License TypePaid

Votes for this feature 0

Votes against this feature 0

Attachments 2

Assigned Users (none)

Tags (none)

May 6, 2019 6:47 AM

ACL

Regular Member

For 3), I have attached a mock up of how the ?do=create view could look with most of the area tabs removed
Attachment 1669

To clarify, in other views the tabs would remain as-is. "Create this page" selected tab is just for ?do=create, since it is this URL where the standard tabs are out of place.

Reply
May 24, 2019 4:26 PM

pegasus

VaultWiki Team

1) part 1: Staff Permissions are not the only permissions used by Wiki Moderators. Wiki Moderators is an entire usergroup and can benefit from all permissions groups. The term "Staff Permissions" was already changed FROM "Moderator Permissions" because people were actively confused by users with "Moderator Permissions" not necessarily being "Wiki Moderators", and "Wiki Moderators" having access to other permissions. The default phrase text will not be changed back, nor would it be changed for consistency with XenForo to something like "Wiki moderator permissions" which will obviously be just as bad confusion-wise.

There was similar confusion in the default phrasing on both vBulletin and XenForo in the past. It looks like XenForo updated the phrasing at some point (possibly 2.0) to try to distinguish "General moderator permissions" from actually being a moderator. I'm not sure the change does enough.

3) Completed per: https://www.vaultwiki.org/issues/5740/

Reply
May 24, 2019 5:44 PM

ACL

Regular Member

Thanks for the update. Regarding 1) part 1, that is fair enough. If VaultWiki could investigate 1) part 2 with having the "staff permissions" block collapse by default in the XF2.x version, then this would still address the main desire behind suggestion 1) as a whole. This is to not have the "staff permissions" be as 'in the way' when editing non-moderating (non-staff) usergroups. To be honest, if the staff permission section was default collapsed for non-staff/moderating, then perhaps there is no need to consider reordering it to appear beneath the other permission blocks.

Reply

August 22, 2019 8:18 AM

ACL

Regular Member

1) part 2 (collapsible permission groups) seems to be possible with a little tweaking to the PHP functions print_group() and print_permission_group() in the file _core\view\cp\xf2.php (class vw_CP_View_XF2). I've added one additional argument to print_groups() (true/false) for whether a particular block should be collapsible, which defaults to false. These changes do not implement the auto-collapsed staff permissions suggestion.

Code:

	public function print_group($heading, $html, $collapse = false)
	{
		$group = '';

		if ($heading)
		{
			$group .= '<h3 class="block-formSectionHeader">';
			if ($collapse) {
				$group .= '<span class="collapseTrigger collapseTrigger--block is-active" data-xf-click="toggle" data-target="< :up:next">';
				$group .= '<span class="block-formSectionHeader-aligner">';
			}
			$group .= $heading;
			if ($collapse) { 
				$group .= '</span>';
				$group .= '</span>';
			}
			$group .= '</h3>';
		}

		$group .= '<div class="block-body'.(($collapse)?' block-body--collapsible is-active':'').'">';
		$group .= $html;
		$group .= '</div>';

		return $group;
	}

	public function print_permission_group($group_title, $controls, $columns)
	{
		$group = $this->print_group($group_title, $controls, true);
		$groupbits = explode('</h3>', $group, 2);
		$divbits = explode('">', $groupbits[1], 2);

		return $groupbits[0] . '</h3>' . $divbits[0] . ' block-body--collapsible is-active cp-perm-controls cp-group">' . $divbits[1];
	}

The original code for print_group() and print_permission_group() was:

Code:

	public function print_group($heading, $html)
	{
		$group = '';

		if ($heading)
		{
			$group .= '<h3 class="block-formSectionHeader">';
			$group .= '<span class="is_active">';
			$group .= $heading;
			$group .= '</span>';
			$group .= '</h3>';
		}

		$group .= '<div class="block-body is-active">';
		$group .= $html;
		$group .= '</div>';

		return $group;
	}

	public function print_permission_group($group_title, $controls, $columns)
	{
		$group = $this->print_group($group_title, $controls);
		$groupbits = explode('</h3>', $group, 2);
		$divbits = explode('">', $groupbits[1], 2);

		return $groupbits[0] . '</h3>' . $divbits[0] . ' cp-perm-controls cp-group">' . $divbits[1];
	}

Attachment 1681

With the extra print_groups() argument, build_edit_form() in vw_CP_Area_View_XF2 (extending vw_CP_Area_View) could possibly be adjusted so that each of the Area manager form groups (Structural Options, Content-Related Options, etc...) would be collapsible.

Example:
$html .= vw_Hard_Core::view('CP')->print_group(vw_Hard_Core::view('Phrase')->get('vw_area_structural'), $this->structural_options(),true);

February 20, 2020 11:30 PM

pegasus

VaultWiki Team

Made all permission groups collapsible in the next release, on XenForo 2 platforms.

Reply
October 29, 2020 6:08 PM

pegasus

VaultWiki Team

#2 is Implemented in 4.2.x. We attempt to improve consistency with other moderated content in XenForo 2, where the user who posted the content is able to see it for a short period of time (seems to be roughly 1 hour) in content lists. Even after that time is up, the user should now also be able to access the content directly if the URL is known. This does not apply to guest users.

Reply

+ Reply

All times are GMT -4. The time now is 3:41 PM.

This site uses cookies to help personalize content, to tailor your experience, and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.

Learn more… Accept Remind me later

Welcome to VaultWiki.org, home of the wiki add-on for vBulletin and XenForo!

Issue: XF2.x: 1) Admin cp: collapsible user permission groups, 2) Better indication of a contributor's own pending (moderated) edit, 3) Create New Page tabs overhaul

Issue Tools