Restricted Display of Apps on Developer Portal using Custom Attributes

[viyer1]

Is there any way I can restrict the Apps being displayed on the Apps page of Developer Portal based on the Custom Attributes defined in the Edge Management UI. For Instance

I have a custom attribute appRevoke

Now in Developer Portal, the app with Custom Attribute appRevoke with value Yes should be hidden from the end user.

[dchiesa1]

I think you could write custom JavaScript that runs and examines these attributes...and modifies the display. There's nothing like a Drupal hook, though.

[viyer1]

Thanks Dino for the answer. Do you have any other efficient alternatives in mind wherein we have the app active on edge but we temporarily restrict its display on Developer Portal for the app subscriber ? Thanks for your time

[viyer1]

Also @Dino-at-Google JavaScript is not going to prevent the Restricted app details coming to the client side and hence I was a bit skeptical

[dchiesa1]

Yes, you are correct. JS would not restrict that data from being transmitted to the browser. It would only restrict the data being displayed.

Let me ask a clarifying question -

is it that you don't want to display revoked apps?

or that you want to display them, and list them as revoked?

[viyer1]

I don't want to display the revoked apps to the App clients.

[viyer1]

Ideal Use Case Scenario we are trying to achieve Dino - A client has subscription for 10 Apps,however, we are trying to hide 2 apps out of the 10 on Developer Portal for the App Subscriber ( though ideally all the 10 apps practically remains active on Edge portal). We were planning to use Custom Attribute and regulate the display of apps using a Drupal Hook. However, with no hooks and with the loopholes in JavaScript, we are looking for effective alternatives.

[dchiesa1]

Let me see if we can get someone who is more of a subject matter expert here to engage on this question.

[Marsh]

No, there isn't a clean way to accomplish what you're asking today, but it sounds like a reasonable feature request.

Could you help me understand why you want to accomplish this? Why would you not want the user to see that their app status was "revoked"? And why use a custom attribute rather than using the "app status" property?

[viyer1]

Thanks Marsh ! So the background is :

We have two Developer Portal Environments

1. Environment 1 - For Users accessing Internally

2. Environment 2 - For members using the Portal Externally.

However the catch here is both of the Developer Portals are pointing to the same organization on Edge.

Though rare, but if certain individuals have roles and access for both the Internal and External portals, the below use case comes into picture.

Say if an internal portal user A, accesses the external portal, A has the internal apps that A had subscribed to, available on External portal as well [ due to common organization and email-id on Edge ] .

Hence, we were looking for granular level access to each app, so that we can regulate the display of apps for those certain individuals on the respective portals.

P.S. - Though App Status would be perfect but it would revoke the API Keys as well, a functionality not favorable to our use case.

[Marsh]

Thanks for the additional background. One story we're considering is whether to limit the list of applications to the context of the portal they were created in. When you visited the internal or external portal, you'd only see the apps you created there. I believe that if we added that configuration option, that it would address your root issue, no? Note that we don't have this story committed to our roadmap, it's simply a consideration for the future.

[viyer1]

Yes, that would be the ideal functionality indeed. That would give the developers freedom to perform micro level configuration for apps on the Developer Portal.

Currently, as a last resort, we are planning to make some custom code configurations in the AppListBuilder PHP file within Edge Module by restricting the display of apps with certain custom attribute based on internal or external environment using the old school if else statements. But that would have its own repercussions and risks, as that would involve tweaking core bare-metal modules that should be best left untouched.

However, it'd be really awesome to see that story soon on your roadmap 🙂

[Marsh]

Ah, I missed that you were using the Drupal-based portal. In this case, you could use custom attributes to implement your own solution in the short term. If you want to file an issue on the project, you can do so here, but note that popularity of customer requests informs our prioritization, and this isn't a widely asked for feature today (and has a reasonable workaround)

[viyer1]

Noted. Thank you so much for your time and the information.

[dchiesa1]

Varun, sorry about the confusion. I didn't realize you were using the Drupal-based developer portal. Of course there IS a hook in the drupal portal, and you can filter the list of apps that comes back based on any attribute on the app.

[viyer1]

Thanks Dino for the info. I'm a bit new to Drupal. It'd be really helpful if you happen to have any documentation link or info about the same. Appreciate your time

[viyer1]

Hey Dino ! Sorry for the repetitiveness but any luck with the hook for Drupal 8 portal ?