Any way to accomplish an array of form names that a given security group has access to?
e.g. getSecurityGroupForms(‘Administrators’)
returns array
[viewable_and_accessible]
[form_a]
[form_b]
[viewable_only]
[form_c]
Thanks
At least not in 2.2.7 (which I have in front of me coincidentally)…
You can hit the repository directly with a SQL query. The following works in 3.5.1.
SELECT property_value FROM demo3_repository.servoy_element_properties where element_id in (SELECT element_id FROM demo3_repository.servoy_group_elements where element_access = 2 and group_id = (SELECT group_id FROM demo3_repository.servoy_groups where group_name = "Administrators")) and content_id = 37
“element_access = 1” = viewable but not accessible
“element_access = 2” = not viewable
Note that you are approaching this “backwards” – finding the forms that have restrictions placed on them as Servoy only adds records in the repository for forms that you place restrictions on. So compare returned form names with an array of all form names returned by:
var allForms = forms.allnames
If you need the SQL query for an earlier version of Servoy let me know.
Note: although this is a good tip I did not want to post it.
Imho it is dangerous to use it because it is not future proof.
Chances are pretty big that things will be different for Servoy 4.
In my opinion the repository is a gold mine of information that is useful in all kinds of situations like this example. Since you are not modifying the repository I don’t view gathering meta information from the repository as “dangerous”.
If the repository does happen to change a bit moving to 4.0 at least the concept is the same and only the query will need to be modified. It doesn’t take much snooping around to see what any new changes are.
I wish I had done more stuff like this early on. We certainly are making up for it now though and are using repository queries whenever they give us information we need that we can’t otherwise get easily (or at all). Sometimes we do it this way just because it is easier!
Returning information about your solution from a database to use directly in your solution is a powerful tool and not a “feature” any other development platform (that I know of) allows the developer to do. It’s outside the box thinking and I highly recommend giving it some thought
Since you are not modifying the repository I don’t view gathering meta information from the repository as “dangerous”.
Maybe I did not use the word ‘dangerous’ in the correct context.
I do agree with what you say but bypassing the API is not supported by Servoy and is likely to give more issues upgrading to a future version of Servoy than it does now.
I know for a fact that the future structure of the repository will be quite different. And I am pretty sure this will break the way queries work (if they work at all).
So, it is not that I say don’t use it but I want to warn for possible future effects…
Agree on the warning - well said. It certainly is up to the developer to weigh advantages and disadvantages of this particular approach. It probably isn’t a technique to use unless you’re comfortable with your Servoy abilities.
In Jeff’s case, I know for a fact that he eats SQL queries for lunch and has no fear of kicking the repository tires so my response was tailored in his direction.
As a side note: I am not so sure that I agree with sticking with the “supported” Servoy API is much of an argument. In my experience it is no guarantee you won’t have a lot of work involved in upgrading your solution at a certain point. I have had plenty of work going from 2.2.7 to 3.0 to 3.1 to 3.5 with solutions with hundreds of forms and 10’s of thousands of lines of code just dealing with supported changes. A few more things to check (and possibly rewrite) in a major upgrade won’t make much difference to me.
Plus who’s to say it isn’t supported? Servoy is by nature designed to be extremely extensible. Plugin API and inline Java code are two things that can change at anytime potentially breaking solutions that use those techniques. But we still use them
Solution meta data at your fingertips is just too juicy to pass up. Once you start down this path, it gets addictive.
Solution meta data at your fingertips is just too juicy to pass up. Once you start down this path, it gets addictive.
Hey why do you think I like working on the Analyzer
david:
If you need the SQL query for an earlier version of Servoy let me know.
Hi David.
Old topic, I know, but I am trying to do some updates to the security model on a 2.2.7 solution, so could you please let me know the code for 2.2.7? (And what other ‘content_id’ numbers might be useful )
Basically I had created a bunch of groups that I spent a long time working on the Security for (locking down forms & elements) then went and added a bunch of new (more meaningful) groups that I assigned users to and suddenly they could do/see things they shouldn’t have been able to
So I need to see what the privs. where for the old ones quickly and then apply them to new groups
[Marcel, maybe you could add the ability to ‘duplicate’ a security group in Analyzer and apply all it’s settings to the newly named duplicate? ]
Thanks
Rafi
[Marcel, maybe you could add the ability to ‘duplicate’ a security group in Analyzer and apply all it’s settings to the newly named duplicate? ]
Rafi, please add it to our Support system.
Rafi, please add it to our Support system.
OK
rafig:
Hi David.
Old topic, I know, but I am trying to do some updates to the security model on a 2.2.7 solution, so could you please let me know the code for 2.2.7? (And what other ‘content_id’ numbers might be useful)
Just checked and the same query works in 2.2.7. Here’s a query for the content ids for all the properties of all the objects:
SELECT content_id, (SELECT name FROM servoy_object_types a where a.object_type_id = b.object_type_id) as "Object name", property_name as "Property Name" FROM servoy_content_spec b
