I have this legacy cube, in roles I see the ReadAll_Admin role, where we have full access to the data:
Screenshot:
I have a few questions:
It says “Only rows that match the specified filters are visible to users in this role”, what if it remains blank like above?! What’s the default “visible” or “not visible”?!
I tested the role above and I can read all data, how is it possible?
What could be a reasonable case as the above: that is, where you leave all tables blank, and =FALSE() in one?
Only rows that match the specified filters are visible to users in
this role”, what if it remains blank like above?! What’s the default
“visible” or “not visible”?
Default is 'Visible'
I tested the role above and I can read all data, how is it possible?
You should be able to read all data except dimension with FALSE() filter
What could be a reasonable case as the
above: that is, where you leave all tables blank, and =FALSE() in
one?
This table might contain USERNAME or other information which should not be visible to users
Related
In CRM Online on a customer form is there anyway that you can check if the Associated View for Assets is blank? And if its blank change a field value based on it.
Using JavaScript, 2 ways:
The associated grid is showing records related to your primary record. You can perform the same query the grid is doing using REST which will tell you if there are any records. You can then count the records, and change the field value as required. This approach is better if there are records in the database but which aren't shown in the view for some reason, e.g. view filters.
Access the Grid objects data using getRows(). As above you can then count the records, and change the field value as required. The downside of this is I believe those methods only give you access to the records shown on the form (and not any hidden by filters but still in the database) - but I don't think that that will be a problem here.
Worth bearing in mind that this approach only works client side, e.g. someone has to be actually looking at the form.
If you need to cover the a non-client side approach, e.g. workflows creating records, then you should probably look at plugin development so the changes can be performed server side.
As a side if you just want a simple count shown on form you then you should probably look at Calculated Fields and in particular Rollup fields. You might also be able to run further client side JavaScript from the count.
I have an array of PFGeopoints which I query from parses back end database, and I then annotate them points onto a MapView. I now a feature in my app where you can turn yourself off so nobody can see where you are, but the current user can still see other people.
I have thought about setting the current location to O,O but this will not allow the current user to view anybody else then.
Any suggestions?
Easiest way to do this is to have a column in the database named visible. You should only query for users that have it set as true. When you don't want a user to be seen, set his visible column to false.
i have a view in an xpage with some entries (lets say clients). I have an acl group of persons (clients) that contains some of the clients of the view. Now i want to use the search attribute of the view to show only entries that belong to the group.
I already use search attribute to select users by name e.g:
FIELD Name Contains "Chuck Norris"
Is there any similar query? (maybe using #isMember on the field....?)
UPDATE: i will have the group entries (client names) into a text list in a document too. so can i filter the "name" field of the view based on the values of a text list?
Perhaps using a reader field is a good idea. You're talking about restricting document access to a group of Domino users - that's exactly what reader fields are for.
For example, make your text list field containing client names into a reader field like this:
var item = document1.getFirstItem("myfield");
item.setReaders(true);
document1.save();
myfield needs to contain canonical names (CN=firstname lastname/O=organisation).
Using reader fields, you don't need to do any view filtering at all, it happens automatically. If you have really many documents (say, half a million or so), it could slow down things, otherwise, it's a nice approach.
When you want to restrict displaying documents only in one certain view reader fields are no solution, though. In that case, you need to do the view filtering yourself as you tried.
If you want to filter only for ONE certain client, then using a categorized view is the way to go. You can give the view panel the name of one client as category filter then.
If you want to filter for multiple clients, you need to do it based on fulltext search, just as you already tried. In that case, make sure you're working with Domino 9. Previous Domino versions don't apply the view sorting order to a fulltext search result, which means you have to search it manually using custom javascript or so, which is complicated.
Or, as Frantisek suggested, write a scheduled agent which puts documents in folders depending on their clients - but depending on the number of clients you want to filter the view for this may lead to many folders, which may lead to other problems. Furthermore, you need to make sure to remove folders when they are not needed anymore, and you have a lag until new documents appear in a folder.
So in a nutshell, if you want to do an application wide restriction based on client names, use reader fields.
If you want to restrict for one client name at a time, use categories.
Otherwise, use fulltext search with Domino 9.
The scenario : an Oracle 11g database containing some sensitive user data that could result legal liabilities if disclosed to the wrong party.
The desired effect : only a certain user, connecting from a certain IP, can see the column that contains this sensitive user data
I am not sure that hidden columns or virtual columns are the right ways to do this. It seems that Fine-Grained Access Control could help. I am not sure of what is the best solution. The restriction by IP is probably done at the listener level?
The question :
How can we restrict the visibility of a column so it is only available only to a specific user? All the other users would never see the column, not even when doing a "DESC TABLE_WITH_SENSITIVE_DATA"
Thanks for any tips.
Simplest way to do this is to create a view on the table that does not contain all of the columns. Don't grant select on the table, but only on the view.
The "proper" way to do this is with Fine-Grained Access Control (Virtual Private Database), which can replace the contents of columns with a NULL if certain conditions are not met.
See the example here: http://docs.oracle.com/cd/B28359_01/network.111/b28531/vpd.htm#autoId17
You can probably build this sort of functionality yourself if you're feeling both impoverished and skilled.
Do you the ability to modify roles and create views? Perhaps you could create two separate views and grant access to two different roles for that table. All users that are restricted from seeing the sensitive data would belong to a "restricted" role and the others would have access to the "unrestricted" role. You would need to grant privileges on each view to the appropriate role.
It is important to note that there are restrictions on updating the underlying data associated with a view. As explained here, views that contain set operators, aggregates and GROUP BY DISTINCT and joins and not modifiable.
greetings,I'm facing a problem in Oracle Forms 10g. I created a simple master-detail form where i want to save data only from the detail data block (the master will function more as a browser).
The only solution found till now is to edit the properties of text items in the master block and prevent them from inserting/updating. This comes in conflict with the list of values (LOV) appearing when the user tries to input the app_id, or from a search button (i know that the way is not significant). Is there a way that i can pass values to the primary block and function only as a query?
Any help could save me from lots of trouble!
We can set various properties at the block level using the Block Properties palette. In your case you need to toggle off Delete Allowed, Insert Allowed and Update Allowed. Obviously you will want Query Allowed toggled on.