Some feature requests


#1
  • Database based roles should have limit on what “columns” should be returned. This would make life really easy in terms of not having to write post / pre script validations on which roles could access what data.

  • Database roles need to have more conditional script as more advance filters than just column level. Many a times a related filter needs to match. Its very inconvenient to write post scripts for each roles and make more queries. I feel if a validation script could be included as part of role it would be really great. This way, not just DB permission, but a custom access could be given at the ROLE level based on business requirement.

  • A more precise Google / FB auth using Native SDK tokens ( not kind of shadow user ).

  • User management is at single level only. It cannot be matched with Org/Department level or APP level. A lot of code needs to be written if we were to have multiple orgs under same instance. Most large API platforms have this. ( Usergrid, Apigee etc ).

  • HTTPS certificate management via the admin panel itself is very important for out of the box solution.

  • API documentation UI needs a lot of improvement. It just doesn’t fit in most of the laptop screens. Good we have large screens but definitely can be improved.

  • Cache ON/OFF switch on Admin panel.

  • Service Package groups - Would be great to have groups of packages. This way all the services could be grouped together.

  • Advance code editor. Current one is really not helpful if we want to do the changes right there. Although its improved from previous editor, I think there is more room for improvement.

  • Global files like Global lookup keys. Would be nice to have some small static files which could be referred as config files for the business logic.

  • Template Roles. Currently there is no way to restrict who can access which template ID. For example, any user having access to email can use any template to make a call. I might be wrong, but I never found any template based assignment for roles.

Thoughts ?


#2

Very well, they would be fantastic improvements :clap:
In my opinion, those are the most valuable:

1 - Database based roles should have limit on what “columns”
2 - Database roles need to have more conditional script as more advance filters than just column level
11 - Template Roles

I still add one more functionality, the ability to specify the fields that should be returned from a related record. Today to have only a little additional information you need the whole record (related), consuming band and precious milliseconds*

ps* Obviously it is possible to create post processing scripts to handle this, but it would be extremely simpler if we could specify the fields in the query.


#3

Hey guys. Just wanted to address as many of these as I can.

@Hussain_Fakhruddin:
1&2 have both recently been filed as feature requests.
3. We create shadow users due to the way that the user service works. I’m not sure that it would make sense with the internal logic of the application for this to chane
4. There has been some discussion of user groups and roles. This behavior is available if you use ldap/active directory for authentication, as we can map directory groups to roles. For the regular user services, could you explain in more detail what you think this would look like? I can file a request.
5. DreamFactory doesn’t need to manage certificates because they are irrelevant to the application. The web server manages the certificates. DreamFactory will process any request that the web server delivers to it.
6. I agree, this UI needs improvement. It is not our UI =) This app is developed by Swagger/Open API. We just integrated it into the product as it is a popular tool for testing API calls. https://github.com/swagger-api/swagger-ui
7. Explain to me the utility of Cache ON/OFF switch?
8. I could also use some more detail on this one as well.
9. The code editor will not likely be changed any time soon. Since adding git integration you can work on your code in whatever editor you prefer and then push to your git source.
10. How would you use these files?
11. This is something I hadn’t thought about before. I’ll definitely file a request.

@juniorconte you can already specify desired fields in related data. You use the parameter name some_relationship_name.fields= and it works just like the regular fields parameter.

For example if I’m calling db/_table/todo?related=todo_details_by_todo_id
I can add db/_table/todo?related=todo_details_by_todo_id&todo_details_by_todo_id.fields=id,some_field,some_other_field


#4

Wow, very nice!

I didn’t get hit on it, will be very useful, I’m starting the adjustments. Thank you.


#5

Thanks for the comments.

Very eagerly waiting for 1 & 2 ; They are most important than any other. I think with these DF would be really easy and secure for anyone to use it.

I’ll explain more on others.

  1. Shadow users:
    The real life scenario is that if a user with email x@abc.com has registered via email. and then later he uses FB with same email x@abc.com and tries to authenticate, these are both same users and shadow user will not work in this case. Both accounts with same email needs to map to same DF user account which isn’t the case with shadow user.

Further, many FB accounts do not return a valid email ID as many have registered via Phone numbers, so DF user restricts and makes email id mandatory. I think username could/should be made mandatory instead of emails.

  1. There has been some discussion of user groups and roles. This behavior is available if you use ldap/active directory for authentication, as we can map directory groups to roles. For the regular user services, could you explain in more detail what you think this would look like? I can file a request.

Use case: I run an org which contains many departments or sub org level. I would like to have two applications totally separated by departments/orgs and their services not mingling with each other. Currently we’d have to setup multiple DF instances to achieve this which is kind of a problem. Most enterprise grade API management solutions like APIgee or UserGrid have this built in.
Look at this dashboard from usergrid : https://raw.githubusercontent.com/apigee-127/a127-documentation/master/a127/images/usergrid_portal.png ( It has ORG and then Apps - 2 levels ).

  1. DreamFactory doesn’t need to manage certificates because they are irrelevant to the application. The web server manages the certificates. DreamFactory will process any request that the web server delivers to it.

You’re right but think of it as an out of the box solution. All APIs being secured out of the box and certificates can be imported. I could think of it like how cPanel sub accounts allowing importing of certificates, it could be really simple and good feature.

  1. I agree, I feel the recently changed Open API UI is even more difficult than what we had before. Too much scrolling needed and presentation is not at all developer friendly.

  2. Explain to me the utility of Cache ON/OFF switch?>> Many a times during development stage, the cache plays up a lot. We have to manually flush cache every time. A quick switch to turn on/off would be really helpful.

  3. For example we have 20 services, if somehow those services could be grouped, relate to an APP / API Key it would be wonderful. This way the API key would have access to those packages. An additional level of security within the org. Also if they could be exported as a package, rather than single service. We had some troubles upgrading to new versions.

  4. Just like variables. Many a times the files could be used as external templates. For example, a keychain / keystore file; or manifest file for any apps or business logic. It could be even long XML template files for legacy systems. Could be anything.

Some more important stuff :

  • Filter on Related tables. It would filter based on conditional match on related table. We did something on it for our project but then DF changed a lot. We have the code, just too much time needed to pull /push. Can I just share via email or something ?

  • Auto Upgrade DF from within itself would be a fantastic feature. One click backup and upgrade. Just like how wordpress does it.

  • Finally would love to have a way where all the user ids or any other ids everywhere are non integer by force. Could it be alpha numeric and generated in a way

  • Kill sessions for other users, make other users inactive or change password for a user. Not sure if this exists as I couldn’t find it - I couldn’t kill or deactivate any user via an API call. We have our own admin panel and would like the admin user be able to control other users. A normal case would be if someone forgot the password and isn’t registered via email ( for example login via FB phone number ). In this case I cannot reset their password unless I login as an admin inside DF.


#6

@drewpearce Regarding the cache on-off switch: to have that at the service level would be great so that as we’re adjusting DB schema we can not be concerned with the cache. In our org, the folks developing data schema aren’t necessarily dreamfactory admins.