user.fld_usr_name is a string with the value random name
user is an object that is given as a parameter
ByVal user As GUser
this is the linq query that doesn't work
Dim result = (From usr In users Where usr.Name.Contains(user.fld_usr_name) Select usr).ToList()
this is the one that works
Dim result = (From usr In users Where usr.Name.Contains("random name") Select usr).ToList()
this is the error
Object reference not set to an instance of an object.
I am using this in Linq to Active Directory library
which probably means it's linq to entities
I've tried everything
I went up into the source code of that plugin.
LINQ just didn't work like it should with vb.net as with c#.
The plugin was C# code, but that shouldn't matter. Very strange.
I forgot the specifics since it has been a while, but it had to do something with the fact that it passes the property as a reference and not the value. Or the fact that it has to be a static... If I knew I'd fix it
I used a shared property to load all my users and worked with that.
If someone knows how to fix this bug, please let me know
another thought on this is that active directory has a really loose definition of what a "user" or "group" is. For instance, with groups; you have security groups and distribution groups. But AD maybe implemented as having something like security groups, authorization groups, distribution groups, location groups, etc. Then on top of that, your IT dept might have it set up so that OUs represent matrix groups and so on. But when you tell AD to bring you back a list of security groups, it'll bring you back EVERYTHING that used a security group type to create it.
Now, if you back up and look at it from the other direction, you'll find that not all "User" are actually users. Some are used differently and thus did not use "Name" property. I've run across this a few times where i had the connected drilled down into an OU that I thought was appropriate and then tried to bring back all the names in that OU. If the field isn't actually used, it'll come back as null and blow your application up. Is it poor AD design? Usually. A lot of organizations get into a habit of creating users or groups to accomplish tasks rather than doing it in a way that physically represents the organization. For instance, creating a user account that is used by a web application only, or creating new groups just to encompass a few permissions for a few special people like I described earlier. And the problem with this of course, is that you try to look at it from a database perspective when coding your application. But it's not a database; it's simply a collection of collections. An unstandardized, dynamic, flat file. :(
So as it possibly applies to you, your linq query maybe returning zilch because the Name field is in fact null for that collection. It is for this reason, that I now only use GUIDs or Native GUIDs. In cases where you only have a name, then use the searcher and grab guids, then use those guids to create a directory entry that WILL have the info you're looking for.
Related
I am not able to figure out that how should I store system related information in Moqui.
For example, if I am using the HiveMind application for a particular organization (ABC Corp), I have to hard code the value while making records for the particular organization. I could not find any suitable entity that will allow me to handle this particular case.
So is there any method by which I can handle this particular case?
For example, when I am creating users and clients in the HiveMind application, there is no record in the database that will specify that the Users are employees of a particular organization.
For clients they are just stored in the Organization entity and no relationship exists that will specify that. I can handle that case by creating a party relationship whenever a new user or client is created.
But I will have to hard code the value of the Party with which I want to create the relationship. Suppose ABC corp is using the HiveMind application, I would have to hard code ABC corp's party Id whenever I create a new user or client. Rather that hard coding this value, it would be more efficient for me to fetch this particular value from the database. Whenever a new Organization wants to use the application, I will just change it in the database and the service code will remain as it is.
This is really an application design question and not an aspect of the framework, but I'll share some thoughts on it.
Business level configuration should generally be done in the database in structures (entities) that are designed for the purpose. Sometimes it general values are needed, but this should be the exception and only rare cases. In Moqui the way to handle user or user group preferences is to use the UserPreference and UserGroupPreference, and for all users use the ALL_USERS group that is standard in Moqui (all users are automatically part of this group). This can be done directly on the entities or using the relevant methods on the UserFacade (ec.user).
That said, from a business and application design perspective for apps based on Mantle (for others reading in, this is the business artifacts project based on Moqui) I wouldn't recommend doing it this way. If you want to support multiple organizations when creating an employee you should have a field on the form to select which organization the employee is part of (and then create the PartyRelationship record as you implied).
In HiveMind there can be multiple vendor organizations with people in different roles associated with them. When creating a project you select the vendor and client organizations for the particular project so we know who to bill from and to, which users are involved with different aspects of the project, etc.
If you do want to support just one vendor organization you may as well hard-code it and not make it visible or selectable anywhere in the application, and make it part of the "seed" data of the app in the more strict sense of the term seed data as data that code depends on directly (i.e. uses "hard-coded", though that term has negative implications that are often unjustified, directly use string values are often quite useful and improve clarity and maintainability).
I'm trying to determine the best way to utilize SharePoint 2013 to manage a very large project with a number of hierarchical elements. I've thought about using cascading/embedded group permissions (doesn't appear to be possible), audience targeting (I'm concerned about user's ability to understand and correctly enter the appropriate target audience), using some kind of session variable fed from a SharePoint list to determine how to characterize entries but then I need a way to auto filter them in lists (seems awfully complex and not sure this will even work). So I'm wondering if I'm missing a better way to do this. This being the following:
I have various staff levels: people at the bottom who are located at a site, a person at the site that is the manager, a hub that links various sites, areas that oversee hubs and include an area manager. I'd like these various people to be able to see only whats relevant to them so for a simple example: a list with a calendar view. An area lead should be able to see all entries made by his site leads, while a site/hub manager should only be able to see entries made by people under their respective site/hub. This would work perfect if I could assign groups to groups and then filter the list instead of by [me] by [(some permission filter option)]
There has got to be a simple way to do this, anyone have any ideas? I think I'm missing some capability of SharePoint 2013 to do something like this and thus am making it harder than it should be.
I am trying to design an efficient database schema for user settings in SQL Server 2008 R2. The wrinkle here is that we need multiple levels of granularity, and I'm not sure how to efficiently represent that.
We have a handful of settings that can be applied to a full Account, a single Module, or a specific Feature. Currently the way the table has been set up is something to the effect of:
AccountId int
ModuleId int
FeatureId int
SettingData string
(please don't get hung up on what SettingData is or isn't, I just made it a string here in the example to distinguish it from the other Ids).
Problem: Many customers have access to many modules, and these modules have access to many features. A single Account making a change to SettingData can modify 4000 records. This is absolutely not tenable for obvious reasons, and I'm determined to fix it.
The solution is obviously to have a few different tables that, by their usage, override eachother and allow some account wide settings and granular preferences. However, I've never done this before and my attempts at designing it end up looking disturbingly similar to the inefficient table structure we currently have.
Thanks in advance, any help is appreciated.
It sounds as though settings can currently be specified at the following levels:
Account
Module
Feature
Given that there are probably already tables set up for each of Account, Module and Feature, it would appear to make sense to:
Remove the existing table.
Set up a new field for setting data on each of the existing Account, Module and Feature tables.
Since the general principle is that the specific should override the general, a Module-level setting should override an Account-level setting, and a Feature-level setting should override a Module-level setting.
The advantage of this approach is that any time a specific setting was updated, only a single record would need to be updated.
The disadvantage is that to determine which setting should apply to a specific feature (for a specific account) in a specific module, 3 tables would have to be queried instead of one.
I have just started using RavenDB on a personal project and so far inserting, updating and querying have all been very easy to implement. However, I have come across a situation where I need a GetOrCreate method and I'm wondering what the best way to achieve this is.
Specifically I am integrating with OpenID and once authentication has taken place the user is redirected to my site. At this point I'd either like to retrieve their user record from Raven (by querying on the ClaimsIdentifier property) or create a new record. The user's ID is currently being set by Raven.
Obviously I can write this in two statements but without some sort of transaction around the select and the create I could potentially end up with two user records in the database with the same claims identifier.
Is there anyway to achieve this kind of functionality? Possibly even more importantly is do you think I'm going down the wrong path. I'm assuming even if I could create a transaction it would make scaling out to multiple servers difficult and in anycase could add a performance bottle-neck.
Would a better approach be to have the Query and Create operations as separate statements and check for duplicates when the user is retrieved and merge at that point. Or do something similar but on a scheduled task?
I can't help but feel I'm missing something obvious here so any advice on this problem would be greatly appreciated.
Note: while scaling out to multiple servers may seem unnessecary for a personal project, I'm using it as an evaluation of Raven before using it in work.
Dan, although RavenDB has support for transactions, I wouldn't go that way in your case. Instead, you could just use the users ClaimsIdentifier as the user documents id, because they are granted to be unique.
Alternatively, you can also stay with user ids being generated by Raven (HiLo btw) and use the new UniqueConstraintsBundle, which lets you attribute certain properties to be unique. Internally it will create an additional document that has the value of your unique property as its id.
Does anyone know of some good resources related to setting up heirarchical user account systems? I'm currently setting one up and am struggling with some of the more complex logic (especially with determining permissions). I was hoping I might be able to find some resources to help me along.
Some Background:
I'm building a user account system for a web CMS that allows for a nested group hierarchy. Each group can be allowed/denied access to read, write, add, and delete (either explicitly for that group, or implicitly by one of its parents). As if that weren't complicated enough, the system also allows for users to be members of multiple groups. -- This is where I'm stuck. I've got everything set up, but I'm struggling with the actual logic for determining pemissions for a given user.
The manual for CakePHP has an excellent description of how Access Control Lists work.
http://book.cakephp.org/2.0/en/core-libraries/components/access-control-lists.html
Represent the permissions set for a given group as a bit mask. OR-ing the bit masks together will give you the resultant permission set.
Update for #Alex:
I wrote this answer 3 years ago, but I believe I was alluding to the following...
From the question
a nested group hierarchy. Each group can be allowed/denied access to
read, write, add, and delete (either explicitly for that group, or
implicitly by one of its parents). As if that weren't complicated
enough, the system also allows for users to be members of multiple
groups. -- This is where I'm stuck. I've got everything set up, but
I'm struggling with the actual logic for determining pemissions for a
given user.
Assign a bitmask matching the total permission set of a group (or role) in the system:
e.g. 00 (using two bits keeps it simple here!)
The first bit confers Permission A and the second Permission B.
Now say Group A confers the following permission set: 01.
... and say Group B confers the following permission set: 10.
To get the resultant permission set for a user in an arbitrary set of groups you could perform a logical OR on the permission set bit masks:
Permission set for Group A 01
Permission set for Group B 10 OR
----
Resultant permission set 11 (i.e. both permission A and B are conferred)
I do not know the details of the questioner's system, but the system outlined here could be augmented to achieve different group-composition behaviors using different logical operators.
Look at the permissions in the Andrew File System. It allows users to create and administer groups of their own, while selectively assigning admin rights and ACLs. You might find that many of the pesky details are already worked out for you in their model.
Edit: here's a better link to AFS documentation:
http://www.cs.cmu.edu/~help/afs/index.html
Here's the section on groups:
http://www.cs.cmu.edu/~help/afs/afs_groups.html
I've done exactly this before and its no trivial implementation. You're going to want to look at the SecurityPermission class.
[http://msdn.microsoft.com/en-us/library/system.security.permissions.securitypermission.aspx][1]
I have done this before by utilizing XML (which I'm not sure I'd do again) and storing that XML as permission list inside of SQL server in an XML column through a CLR stored proc. The XML would have an element called a "permission" and then the permission would actually be a ENUM inside of the code. Each permission was a new implementation of the SecurityPermission class (linked above) Users were tied to groups which were defined in SQL server and then as the user was added/removed to groups, the XML doc would get updated to reflect which groups they were apart of.
As soon as the user logged in, the users credentials would be loaded into the application store (session) and then would be accessed accordingly. When authorization needed to take place the XMl in the application store would be pulled down loaded into the SecurityPermission via the "FromXML" method. At that point I would use the following methods to determine if the user had permission:
Demand
Intersect
Union
IsUnrestricted
IsSubSetOf
etc., etc, etc.
At that point after performing the Demand I was able to determine if the caller had access according to how I implemented my security routines in the SecurityPermissions.
Again, this is leaving out a TON of detail, but this should get you going down the right path.
Take a look at this name space as well: [2]: http://msdn.microsoft.com/en-us/library/system.security.permissions.aspx "System.Security.Permissions"