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
Related
I have to create login signup form in flutter with following modes:
Login fields: Email/Password
Signup fields: Name/Email/Password
Forgot password: Email
Is it good to have all this in single file and logically rendering hiding fields with different modes. Let's say I am on login I have name/email I click on create account than mode changes to Register instead of redirecting to new page, and additional field >> Name field is visible.
So is it good to maintain all these login register and forgot password in single page and logically maintaining it?
This actually depends on your approach and your requirements. But most of the blogs authored by Flutter developers online, they prefer to have a separate login and register pages. Personally, I also prefer separate files for maintainability when your code gets bigger and more complex. You can try to check some samples online just like this one.
Using the Google Provisioning API, under Managing Organization Units, it states that the creation of a user within an organization unit is a two step process. First I must create the user and then I must move them into an OU.
This creates a problem if I am migrating somebody from a legacy system. Creating their account causes our routing to immediately start sending emails to that account, overriding their legacy account. However, we will often create these accounts in advance and so have a specific OU for which routing is ignored.
Currently, we have to create the account with a different email address (e.g. append "-renamed" to the username), move the account in the non-routing OU, rename the account back again and finally remove the extraneous "-renamed" alias that is created during the rename. This seems pretty messy for what should be a simple operation.
Is there a simpler/better way of doing this?
Sadly you cannot create a user in a specific suborg right away. I take that you have some kind of callback after a new user is created wired up to the routing, you can either tell that service to ignore the next callback for that specific username before creating the user or have your default organization as the non-routed one.
I can also just recommend using SAML SSO, especially if the user is going to need any other account, syncing accounts correctly and handling exceptions in this context can be a pain.
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
I have just set up a new ASP.NET MVC website and I would like to change it to force the user to authenticate their email address by clicking a validation link in an email. I googled the answer with as many search terms as I could think of, but I guess I never hit the correct one.
I started playing with the membership objects to see what I could come up and I did see you can toggle IsApproved, and so I set the default to false. I registered a new user after that and no email came through (as I had expected), but also it logged me in anyway for the current session. Thats beside the point however.
Is there a built in mechanism for sending out a validation email or is that something I need to implement?
There's nothing built-in to achieve this. You'll have to implement the email sending and validation process yourself, unfortunately.
You're on the right lines, though. Once a user is registered on your site, you'll have to set their IsApproved property to false, create a random "activation code" and store this (usually in a manually added field on the aspnet_Membership table or as part of the ASP.NET Profile if you're using Membership Profiles), send off the email with a URL that contains the user's "activation code". Once the user receives this email and visits the URL, you grab their "activation code" from the URL, look up the account from the ASP.NET membership system and set their IsApproved property back to true.
For detailed information on how you can achieve this, take a look at:
Examining ASP.NET's Membership, Roles, and Profile - Part 11
This is Part 11 of a 16 part series on ASP.NET's Membership, Roles and Profile providers, and not only shows how they are used with the built-in functionality offered, but also shows how to implement some commonly seen functionality that isn't provided "out-of-the-box" with the ASP.NET systems. (Incidentally, the whole series is well worth reading!)
Although this article was written well before the advent of ASP.NET MVC, the basic mechanism for implementing a "verify-by-email" system is the same and is easily converted to be more ASP.NET MVC-friendly.
Like you observed, there is support for handling certain types of behaviors (like approval of an account, blocking, etc). Those are just extensibility points that have some sort of default behavior (like blocking an account after x amount of unsuccessful logins). However a mechanism for account validation using email links is not available out of the box. You'll have to implement it.
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.