I am looking into OFBiz HR module, there leave functionality is implemented perfectly. But i am not understand few points. Even if i login as demoemployee i can apply leave for Admin.
This sould not be the case.
Please verify the following steps:
Logged in as demoemployee: (uid: demoemployee, pwd:ofbiz)
Navigate to HR --> Human Resources --> Leave
Click on "New Leave" button
Select partyid as "admin" The Administrator, and other fields... and click on "Create".
The leave has been created for admin.
I want to know how to restrict employee to apply his/her own leaves.
Is ofbiz can be used for Employee-Self-Service functionalities like updating his own details/viewing his own salary details, updating his own leavs....
Thanks,
Chandrasekhar K.
Usually OFBiz OTTB components are pretty generic and will not apply to everyones use case and some customization is required, this is also the case with HR module.
I am looking into OFBiz HR module, there leave functionality is implemented perfectly. But i am not understand few points. Even if i login as demoemployee i can apply leave for Admin. This sould not be the case.
demoemployee is part of HUMANRES_EMPLOYEE group which has VIEW and CREATE permissions, that's why with this user you can view and create leaves. But notice that you don't have UPDATE permission for example, so you cannot update and approve the leave. Usually in this case the leave is still not valid, only entered in the system…
I want to know how to restrict employee to apply his/her own leaves.
To restrict the users from creating leaves for other users, you have to override the humanResManagerPermission service and apply your custom logic (logged in user partyId should be the same as leaving party Id)
Is ofbiz can be used for Employee-Self-Service functionalities like updating his own details/viewing his own salary details, updating his own leavs....
Yes definitely, two approaches:
if there are some screens in HR or Party component close to your requirements customize them
Create a new component, with the spcific screens you want.
In both cases you can/should reuse the existing datamode and services. Most/all of the work will be about creating appropirate UI
Related
I was asked to separate access to a particular Jira project by component. e.g. user "a" can see issues created for component "a", but not component "b". conversely, user "b" can see issues created for component "b", but not component "a".
I know that I can limit access to a particular project to one or more users, but I was unaware of a way to filter access to one or more users by component within a Jira project.
Is there any way to limit access to one or more people to a subset (less than all components) of a project?
I did a search for a Jira plugin that might offer this functionality, but did not find what I was looking for.
N/A
N/A
I don't know if that's possible by using a component (I don't think so), but there is an alternative approach which might be sufficient as well:
You can adjust the Browse Projects permission like this:
You can grant permission to a group custom field value. Then you could choose a custom group field (create one if not available) which will be evaluated on each issue. Then, if you create an issue and add a group to this custom field in that issue, only users from that group have access to view the issue. Take care that you remove the any logged in user setting for "Browse Projects", otherwise the group custom field does not have any effect. There is also a KB article here in Jira's documentation.
The first question is what are you trying to do? Why do you want to restrict who can view issues?
Jira has Issue Security Schemes that can do this based on setting the security level according to the component, or other fields. I'd use a custom create post function
But what happens when the component is changed? Now you have to restrict editing too.
New at ASP.NET MVC. I am looking for some UI design ideas not entirely specific to MVC. There is probably not an exact answer but here is what I have started.
There would need to be a page with 3 tabs on it.
Permissions | Groups | Users
1) Permissions View would allow you to do CRUD operations on Permissions in a Grid
Delete on a specific permission is only allowed when the permission is not being used in any Group.
2) On Groups View, CRUD operations on Groups are allowed in grid.
Also, a Permissions link is provided that will allow to do mapping (Add/Remove) Permissions for a Group
Again, a DELETE operation on a Group is only allowed when the Group is not being used by any User.
3) On Users View, all the existing Users in the system will be presented. The grid show allow for searching a user by username, first name or last name.
Groups link should be provided for each user that when clicked allows to do mapping (Add/Remove) Groups for a User.
Below this mapping in the same view, a separate section of Permission Overrides should be provided so that a specific permission can be added with IsGranted (true/false).
Description of the database design:
1) Groups will be assigned Permissions. Based on the group that the user belongs to, User will get the Permissions.
2) UserPermissionOverrides will handle the scenario where
- a User needs to be granted certain permissions (regardless of the role they are in) or
- if certain permissions need to be revoked from a user, even if they belong to a certain group.
This will allow us good flexibility to handle the special scenarios of adding or removing specific permissions.
So, when the user logs in - 1) above will be used to retrieve the group permissions for a user and then 2) will be executed to retrieve the overrides (granted/revoked). Combining 1) and 2) will give us the final permissions for the user which will then get stored in the forms authentication cookie to prevent further database hits
Your model and functionality all make sense to me. However, I think you need to revisit the UX principles you are employing for the interface.
Write a few user stories i.e. what a user of the security system intends to do and what goal they need to fulfill for that visit.
You need not always tightly couple your UI to your model i.e. just because you have structured your model in a certain way, those entities needn't be presented as principle objects for CRUD operations to a user. It's probably very unlikely that a user of the system will come in, add a permission and leave.
Pertaining to the above, personally I would approach your user permission UI as a wizard rather than a set of tabs:
Step 1: Pick a user or add a user.
Step 2: Which roles do they need (offer the opportunity to add a role).
Step 3: In which groups do they belong (offer them to add groups here if necessary).
... or similar.
Basically, your aim should be to get your user in and out of the system as quickly as possible. I think the act of creating user stories and wizards you glean from them would be the method I would employ in the UX design of your system.
Good luck!
I'm using SpecFlow whilst writing an asp.net mvc 3 website. The registration system in the site consists of two views.
the first view asks for basic information e.g eMail, password and location, whilst the second view asks the user for the type of account (developer or standard user) and then name, address etc.
In SpecFlow terms then I have one feature Registration and two succeeding senarios, registering as a developer and as a standard user.
if this was one view I could test this using something like:
given I am on the registration page
when I enter Data1
and I enter data2
and I click the next button
then the registration should be successfull
as I have two views is it best practice to chain several given, when, and, then statements or is there a better way of doing something like this?
Any help apreciated.
Sean
I would avoid mentioning the different pages within the feature file, and handle that at the step definition level instead, e.g.
Given I am registering
When I fill in my basic information
And I choose to register as a developer
Then I should be registered as a developer
Given I am registering
When I fill in my basic information
And I choose to register as a standard user
Then I should be registered as a standard user
I have been thinking for a good while about how to tackle the problem of implementing an ID based user system while using ASP.NET MVC. My goals, much like StackOverflow's system are as follows:
Allow the users to change their nicknames without the "avoid duplicate" restriction.
Allow the users to authenticate via OpenID (not with password for the time being).
I wanted to avoid as much rework as possible, so I at first thought of using the membership, role and (perhaps) profile providers, but I found they were username based.
I thought of adapting the hell out of the SqlMembershipProvider, by using the username field to store the IDs and throwing UnsupportedException on password based methods and the like, just so as to be able to use the other systems. But it feels unwieldy and kludgy (if possible to do at all).
On the other hand, maybe I should roll up my own user system, but I'm not sure if even if I can't use the providers, I can still use some of MVC's features (plug my code in with MVC somewhere, I can think of AuthorizeAttribute off the top my head).
So I was wondering if anyone had run into the same design problem, and what solutions they had come up with.
The more detail the better!
I had to set up a quick membership system for a client, they had some requirements that didn't allow me to use the built-in right off the bat nor the time to build what they wanted. I have plans to eventually roll-out a complete membership management system, but like you, I needed something now. I went with the following plan, which will, eventually, allow me to swap out the built-in providers for my own - time constraints and deadlines suck:
I have my own Personal User Table (PT) - MembershipId, UserName, Email, superflous profile info. This is what the app uses for any user information. It's a class, it can be cached, saved in the http context, cookie - however you want to handle your user info.
I then set up the SqlProfileProvider for authentication, authorization, and roles. I don't use the profile provider (even for trivial settings) because it's a pain in MVC. I made no changes to the built-in providers. This is what I'm using for authentication and authorization.
When creating a user, my code does the following:
Check PT for user name and email, per my rules
Create Guid - MembershipId
Create MembershipUser, the MembershipId is the username (the email is irrelevant and not used), and user password, question and answer, etc.
Create the user in PT with the profile values and use MembershipId as the PrimaryKey.
On login, I get the MembershipId from PT, validate against Membership with the MembershipId and the password and I'm done..
When deleting a user, I do the following:
Check PT for user, make sure I can/should delete
Get MemberShipId
Use a transaction
Delete from PT
User Membership.DeleteUser(MembershipId, true) - this ensures that the user is deleted from teh membership and other aspnet_ tables
commit
And it works as expected :)
A few things:
User.Identity.Name will be the MembershipId (Guid). This is used for SignIn and Role management. My PT is where the user's info (save the password) is saved. I can change user names, emails, etc with no impact on Membership or Roles because Membership is based on the PrimaryKey from PT.
The signin requires an extra DB hit because you need to query PT to get the MembershipId to validate against (you could cache).
The built-in auth system is really heavy - if you look at the sprocs you will see all the hoops it goes through to validate a user. I'd recommend eventually getting away from it. But in a tight spot, it does a good job - and if you don't have a milion users, I don;t think it'd be a problem.
I didn't consider OpenId and I'm not sure how you would integrate it, although I think you could probably do the same thing as above and instead of validating against actual credentials (after they come back validated form OpenId) just log in the user using the MembershipId (don;t validate against Membership).
For me, the main point behind this was that the app uses a custom user model, allowing for changes to user name, email, names, etc. Without impacting the auth and roles. When I am ready to change to the complete system, I can change it without worrying about the impact to the app.
Kenji,
I would recommend looking at some of the existing OpenID providers for ASP.NET. It should be fairly easy to make them work with MVC.
Erick
Forgo the use of SqlMembershipProvider. The only thing it would really offer you is an out of the box admin interface. The rest that it brings would be a nuisance.
Just use the sql membership provider and add a stored proc to change the username at the database level.
I'm required to provide functions for both users and administrators to edit account and profile details in a web application. An example of a URL for the public side of these profiles is:
http://example.com/user/joe
I'm still torn between two ways to design these URLs. I've thought of either this:
http://example.com/user/joe/edit
Or something non-specific and separate to the profiles:
http://example.com/account
The benefit of the first one is that it allows administrators to do their job through the same functions. This avoids building a whole different backend specifically for administrators. I suppose the negative here is that I'd have to be careful with authorization and make sure nobody can edit what they are not supposed to edit.
The second is a more standard way of doing things, it'd turn out to be simpler and easier to secure, though it means a separate interface for administrative users.
What is SO's opinions on this? Are there any more pros/cons for either way? Which method would you recommend to use?
I would have a different view for the administrator with such a security sensitive area. It makes things much more explicit having a separate view. It is likely even an administrator would only be able to edit certain user information and thus have a different view to the user editing themselves.
It makes the authorization much clearer even if the two views shared a common edit form
If you are using an MVC approach, then my suggestion would be:
http://example.com/user/edit/1234
or
http://example.com/user/edit/joe
Where user is the controller, edit the controller method and 1234 or joe the user id or username respectively.
But as Gumbo commented, administrators should not be allowed to edit user information. They should have some mecanism to disable the account in case of a profile has offensive content or false info. Forcing the user to update it to get the account active again.
The way we do it is the admin and the user share the same view. Items which are admin-only are protected from editing or viewing by the user.
The reason for the single view is:
It reduces the number of 'moving parts' - when a new field is added to the user screen, it only needs to be added once,
It is easier to move items to/from the user's purview. If all of a sudden, management decides to allow a user to manage their "FizzBar" then we only need make the change in one place, and
It is easier to segregate the roles and the functions at the controller level.
I think that you should go with the second approach. It's more secure and flexible, and shouldn't be harder to code than profile editing the profile inline.