Invision Community 4: SEO, prepare for v5 and dormant account notifications By Matt Monday at 02:04 PM
Mark Posted June 20, 2016 Posted June 20, 2016 We have made some changes in IPS Community Suite 4.1.13 to how FrontNavigation extensions handle permissions. Previously the permission settings ("Show this item to users who can access its content" / "I want to choose which groups can see this item") were ambiguous as to whether the latter setting includes groups who cannot access the content the item links to. This change resolves that ambiguity. The changes are backwards compatible, so you don't need to make any changes for your application to keep working, but you should make these changes as soon as possible to ensure consistency. Previously, permission checks were implemented in a single method and you would call the parent method within it. For example, here is what was defined for the Cards extension in the Commerce app (which shows a link to where users can view and add stored credit cards): /** * Can access? * * @return bool */ public function canView() { return \IPS\Settings::i()->card_storage_gateways and parent::canView() and \IPS\Member::loggedIn()->canAccessModule( \IPS\Application\Module::get( 'nexus', 'clients' ) ); } This has 3 checks: It checks if the site has any gateways set up which allow cards to be stored. If this functionality doesn't exist, the link shouldn't show to any users. It calls parent::canView() which is intended to check the permissions the admin has set up for the menu item. It checks the currently logged in user has permission to access the page. In 4.1.13, rather than override canView() like this, there are 2 different methods you can override: isEnabled() is used for you to specify if the functionality the menu item linked to exists. If this returns false, the menu item will never show to any users, regardless of whatever permissions to admin has set up. In the Commerce example above, we will use this method to check if it is possible for anyone to use stored cards. This is a static method. canAccessContent() is used for you to specify if the currently logged in member can view the page that the menu item links to. The admin may choose to override this, or they may choose to show the menu item to those users who this returns true for. In the Commerce example above, we will use this method to check if the user has permission to access the client area. So here is the new code for the Cards extension in the Commerce app: /** * Can this item be used at all? * For example, if this will link to a particular feature which has been diabled, it should * not be available, even if the user has permission * * @return bool */ public static function isEnabled() { return \IPS\Settings::i()->card_storage_gateways; } /** * Can the currently logged in user access the content this item links to? * * @return bool */ public function canAccessContent() { return \IPS\Member::loggedIn()->canAccessModule( \IPS\Application\Module::get( 'nexus', 'clients' ) ); }
HeadStand Posted June 20, 2016 Posted June 20, 2016 +1 for this change. I never did like having to remember to call the parent in canView.... my memory is full of holes these days.
Dylan Riggs Posted June 20, 2016 Posted June 20, 2016 Off topic... So why is this posted here exactly, and not the whole community? Are contributors the only ones to know about backend changes before releases and not the entirety of the IPS community? Sorry, these have been ratteling my attention a bit :P
HeadStand Posted June 20, 2016 Posted June 20, 2016 21 minutes ago, Dylan Riggs said: Off topic... So why is this posted here exactly, and not the whole community? Are contributors the only ones to know about backend changes before releases and not the entirety of the IPS community? Sorry, these have been ratteling my attention a bit How would this benefit non-contributors?
Adriano Faria Posted June 20, 2016 Posted June 20, 2016 27 minutes ago, HeadStand said: How would this benefit non-contributors? Because of this:
Dylan Riggs Posted June 20, 2016 Posted June 20, 2016 35 minutes ago, HeadStand said: How would this benefit non-contributors? Just because someone hasn't uploaded a file to the marketplace, doesn't mean that they don't do any development work at all with the IPS framework. It's silly to hold back breaking changes from everyone but private contributors. Edit... ninjaed
Mark Posted June 20, 2016 Author Posted June 20, 2016 5 hours ago, Dylan Riggs said: Off topic... So why is this posted here exactly, and not the whole community? Are contributors the only ones to know about backend changes before releases and not the entirety of the IPS community? Sorry, these have been ratteling my attention a bit I didn't give where I posted it a huge amount of thought... but the idea is that contributors can make sure nothing we're doing will break their mods and if so, let us know before the release so we can fix it since if we do something which breaks a really popular mod that sucks for everyone: us, the author and the users. In fact, for the gateway changes, we already did change the signature slightly from what I originally had it as because someone messaged me to tell me it was causing their gateway to get an error.
Ali Majrashi Posted June 20, 2016 Posted June 20, 2016 12 minutes ago, Mark said: I didn't give where I posted it a huge amount of thought... but the idea is that contributors can make sure nothing we're doing will break their mods and if so, let us know before the release so we can fix it since if we do something which breaks a really popular mod that sucks for everyone: us, the author and the users. In fact, for the gateway changes, we already did change the signature slightly from what I originally had it as because someone messaged me to tell me it was causing their gateway to get an error. if only we have good dev-portal including all official recourses with upgrading notes between versions
Dylan Riggs Posted June 21, 2016 Posted June 21, 2016 2 hours ago, Mark said: I didn't give where I posted it a huge amount of thought... but the idea is that contributors can make sure nothing we're doing will break their mods and if so, let us know before the release so we can fix it since if we do something which breaks a really popular mod that sucks for everyone: us, the author and the users. In fact, for the gateway changes, we already did change the signature slightly from what I originally had it as because someone messaged me to tell me it was causing their gateway to get an error. I understand that, but my point still remains. Posting it private isn't benefiting anyone not labeled as a contributor - Posting it public will. If it's public, authors as well as everyone else will know what needs to be altered to fit the changes that the updates are being pushed..... that's all. Looking forward to this new dev center
Recommended Posts
Archived
This topic is now archived and is closed to further replies.