I'm migrating all module tests of a React Redux Web Application from WebDriverIo to Cypress and found this weird scenario.
I have a table with a series of elements. Clicking on one of them opens a window on the side showing more detailed data. The test I am trying to migrate is one that checks that the window with detailed data remains visible and without altering its data despite any changes I make to the table's search filters. Even if that means discarding the item whose detailed data is currently visible.
Problem? The detail view covers the filters and Cypress doesn't seem to like this and gives me trouble detecting the selectors. For example, imagine this is my table and the black square is the place the detail view will take. (The photo was taken from Internet).
I did several tests with those filters so I know the way I'm doing to access the selectors is the correct one. But, as it keeps behind Cypress is having trouble finding them.
I tried to access filters after closing the detail view and, of course, it worked. Also tried adding the param {force:true} in the .click() action but it also failed.
Somebody has ever faced a similar scenario? Thanks in advance
Related
I am trying to create a site with high rankings in accessibility and one of the things i have come across is. My live search (that makes a ajax request and shows suggestions from what you type in the search bar on "keyup").
The list of suggestions i full of links that will take you to the page you are looking for meaning there is no submit page containing your results you just click the links therefore a submit button would be in my opinion redundant and useless.
My question therefore: Is it possible to make a form ex a live search without a submit button without the site being ranked lower than if it had a search button?
Is it possible to make a form ex a live search without a submit button without the site being ranked lower than if it had a search button?
You have to read WCAG Success Criterion 3.2.2 On Input
The first technique proposed is G80: Providing a submit button to initiate a change of context
But there's another technique which would not require a submit button:
G13: Describing what will happen before a change to a form control that causes a change of context to occur is made
TLDR: yes, but.
Its usually considered good practice to have a 'fallback' scenario. Say, for instance, the user is not using JS (god forbid) or if the user is using a screen reader of some sort - the search box should direct the user to a new page with listed results.
A helpful guide to building accessible sites can be found at (https://www.w3.org)[https://www.w3.org/TR/WCAG20-TECHS/]
I have a subgrid on my form which I assign a dynamically generated fetchxml query using javascript. When the user clicks on the subgrid's "pop out" button, the query is lost and it displays the default view for that entity.
The user needs to be able to perform multi selection and bulk editing. As far as I know this is not possible for subgrids in CRM 2013 upwards. Is there a way to retain the query when it is popped out?
There's no supported way to interact with a popped out grid. If you started digging into the client side application code, you might be able to find a hook to the new window, but doing so would be unsupported, liable to break, and I wouldn't recommend it.
I was going to suggest hiding that pop-out button on your entity's sub-grid altogether before re-reading that your users need to use the popped out grid for bulk edit.
In that case your best option will be to do ditch the JS and move to a RetrieveMultiple plugin against the sub-entity. RetrieveMultiple plugins should be generally avoided, but from what it sounds like in your case, it's your only option.
And, just to be thorough, are you positive you need dynamic fetch for the sub-grid? Is there any way you could come up with a view that would get close enough to your requirement, even if it's not perfect?
Update:
Based on the additional information you provided in your comment, I can only think of two options:
Implement a custom grid--or modify one of the free ones out there--that allows multi-select and bulk edit
Your custom web app takes the user's criteria, creates a personal view (entity: userquery) for the user and saves it to the database, then your JS on the form sets the grid to that view.
You can do that liks this:
document.getElementById("someGridId").control.SetParameter("viewtype", "4230"); // 4230 is the objecttypecode for userquery
document.getElementById("someGridId").control.SetParameter("viewid", "{11310965-0306-E611-80E5-3863BB36DD08}");
Doing this actually does make the popped out grid load the personal view, but in my tests just now the grid gets upset if you try to refresh it.
This approach has obvious downsides: 1) You have to come up with a way to clean up the personal views that get generated 2) the grid might break on refresh 3) it's unsupported and liable to break on an update.
Still worth considering, I suppose.
A more supported way instead of using unsupported getElementById is to hook a plugin to multiple retrieve of the entity and amend the query in there
Chris
I have a question on the subject of composite attributes that I would be grateful if you could help me with.
I posted this before on other question blogs but got no response I am satisfied with.
I am writing JavaScript that will update the fields (i.e. address1_line1, address1_line2, address1_line3, address1_city, address1_stateorprovince, address1_postalcode, address1_country) in the composite (address1_composite). When the fields are updated the composite does not seem to update. I have to open the composite and close it again. Is there a way of doing this automatically in JavaScript?
I have tried the following ideas:
Idea 1:
Xrm.Page.data.entity.save();
This is recomended at http://community.dynamics.com/crm/b/magnetismsolutionscrmblog/archive/2013/10/22/working-with-dynamics-crm-2013-composite-fields-fly-out-menu.aspx
This is not any good as my customers want to view the composite before saving the page. Also I would not want to save the page for my customers as they do not want this. They would like to decide when to do this themselves.
Idea 2:
Xrm.Page.data.refresh();
This is not really what I wanted as I do not want to refresh the whole page. I just want to refresh the composite. Also it bring up a popup that warns you about not having saved the page which will be annoying for my customers.
Idea 3:
Writing the address from the address lines to the composite.
This feels like a nasty hack.
There is probably more than one way of doing this. I used the function
Xrm.Page.getAttribute("address1_composite")._attribute.setValueForCompositeField();
I do not like this for the following reasons:
This is a hack as it is not using the system functionality of the done button to write the data.
You do not get the system formatting you get with the done button although this will get done when the form is saved so it is not so bad.
In the future if customers are allowed to add their own composite fields it could cause problems as the field names could be different.
It requires me to write extra code for each form that has a composite which has fields with different schema names. E.g. I have to write different code for forms with ShipTo and BillTo addresses as the code for the account form will not work.
Another idea was to set the focus to the composite field after a change has been made to any of the fields inside the composite.
Xrm.Page.data.entity.attributes.get("address1_composite").controls.get(0).setFocus();
This is the best idea so for but it is far from perfect. This forces the user to press the done button and hence the fields will be written. I was hoping for something more automated.
My Question:
What would be great is if there was a way to click the composite done button in JavaScript. This would give me the formatting of the done button and the automation I need.
Update - 14/04/2014
Since posting this question I have been in contact with Microsoft and they say there is no supported way of clicking the done button via a program.
If the field is locked down CRM JavaScript does not send the data back to the server for updating. Another approach would be:
perform the update using JavaScript (so the user sees the change); and
use a server side plugin on the Update event so the value is persisted.
I am looking for People Picker Control similar to SharePoint one for MVC3 applications.
Can you please suggest if there are any such controls available?
What is the best approach to pick the people from AD in MVC3?
Requirement: On one of the Views, I need to select a user from AD.
I was thinking about People Picker kind of control.
Thanks
Arun
I know this is quite old so I doubt you still need this answered but perhaps it will be useful to someone else.
Just last week I had to build a control like does this for us. It's basically two main parts, a JSON service that accepts partial text and returns a list of suggestions and the HTML/CSS/jQuery+UI control.
The service is pretty straightforward so we'll skip over that here.
I'm in the process of doing a write-up on the web side but basically we wrapped the jQuery autocomplete with some custom CSS to make an input that is similar to the address line in GMail. This was done by styling a container div to look like a long input field. The actual input field is within that container and styled to be essentially invisible. Clicking in the container moves focus to the input box. Upon selecting a suggested name, I create a new container to insert before the 'cloaked' autocomplete input which contains the user name and a hidden input with our desired value to send along when the form is submitted. I had to do some other overloads on the autocomplete to get it to act consistently but essentially this is all there was to it.
The control looks at the container for a data-input-name attribute to figure out what 'name' to set the hidden inputs to when they are created with each user pick. When the form is submitted the default model binder rolls all the users of a particular picker (since you can have multiple on a page) into string arrays of the values - assuming your model has string array properties with the same name as used by the input controls - which we can then process on the server side.
By far the hardest part was figuring out the right HTML + CSS to get the look and feel right. I'm not a very strong UI person so this took me forever and still falls down in Chrome which seems to add an accent around input boxes even with (or because of?) styles which make it blend into the parent control.
For our purposes it's been working great over the last week.
UPDATE: It's now on GitHub with a Demo.
Can we use an alternate function other than group to perform the same action. The scenario I am trying to workout using group is - I have multiple pages in a form and a summary button on the first page which on being clicked should show the summary of all pages.
The logic we tried was using group to club each individual pages by having a form variable which turns true when the summary button is clicked and we check this variables value in all pages and so when the summary button is clicked this condition satisfies and all the pages are displayed.
The Code Snippet
<Xforms:group id="page-1"
ref=".[instance('form')/current-page = '1'
or
instance('form')/summary = 'true']">
Using group fn drastically depreciates the performance. Is there any method to perform the same scenario. Kindly advise.
At this point, hidden groups and hidden cases work differently:
The controls in hidden groups are non-relevant.
The controls in hidden cases are relevant.
As a result, using a switch/case, the server has to do more work to maintain and update the state of controls in hidden cases, but switching to a another case is very fast: it is pretty much just a matter of changing a class in the HTML, as the values of all the controls are already there. With hidden groups, when "switching to another group", the values for the controls in that group are sent by the server to the browser. Updating the values can take a little bit of time, especially if you have a lot of controls, say in a repeat.
It is hard to give a recommendation without really running your code, but if the time taken to do a switch is mostly spent on the browser, you could investigate using the full update mechanism. If the time is mostly spent on the server, then I'd look into XPath analysis. (Note that both features are PE-only.)