37 Commits (3e720942e58f99b038616d95e00a01ac9dd2f490)

Author	SHA1	Message	Date
John Molakvoæ (skjnldsv)	12eba18bdf	Adjust acceptance tests to new OCA.Sidebar ... Signed-off-by: John Molakvoæ (skjnldsv) <skjnldsv@protonmail.com>	6 years ago
Daniel Calviño Sánchez	87d4fb777a	Extract locators and steps for sharing in Files app to their own context ... Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>	7 years ago
Daniel Calviño Sánchez	75b734ec98	Add acceptance tests for folders that can not be reshared ... Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>	7 years ago
Daniel Calviño Sánchez	aa695dca0d	Add acceptance tests for sharing a file with another user ... Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>	7 years ago
Daniel Calviño Sánchez	94645ed754	Add acceptance tests for marking a file as favorite in the details view ... Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>	7 years ago
Daniel Calviño Sánchez	fec8d12fc5	Wait for the link share menu to open in acceptance tests ... In the acceptance tests the link share menu is automatically opened if needed before interacting with an item in the menu; if the menu is not open it is opened by clicking on its toggle. However, since a recent change the link share menu is automatically opened by the regular UI after the link share is created. This causes that, sometimes, after the creation of a link share the acceptance tests check whether the menu is shown or not before the menu was automatically opened; as the menu is not open then the acceptance tests proceed to click on the toggle, but in the meantime the link share was created and the menu opened, so clicking on the toggle now closes it. As the menu is closed it is not possible to interact with its items and the test fails. To prevent that now the acceptance tests wait for the link share menu to open after a link share is created before continuing with the other steps. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>	7 years ago
Daniel Calviño Sánchez	f57b07e2c2	Add acceptance test steps to be used from Talk acceptance tests ... Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>	7 years ago
Daniel Calviño Sánchez	a784e1fcc1	Test that "Password protect by Talk" is not shown if Talk is not enabled ... Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>	7 years ago
Daniel Calviño Sánchez	b23289da1a	Adjust acceptance tests to changes in link shares ... Although now it is possible to create several link shares the acceptance tests currently handles only the first link share; this first link share is now created by clicking an "Add new share" button instead of a checkbox. Besides that, the "Copy link" button has been moved from the menu to the row, next to the menu trigger. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>	7 years ago
Daniel Calviño Sánchez	d4f39a9033	Add acceptance tests for hiding download in link shares ... Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>	7 years ago
Jan-Christoph Borchardt	9b8e884b19	Change wording of 'Copy URL' to more understandable 'Copy link' ... Signed-off-by: Jan-Christoph Borchardt <hey@jancborchardt.net>	7 years ago
Daniel Calviño Sánchez	70262fb11a	Adjust acceptance tests to the new share link UI ... The share link UI no longer uses its own layout below the other shares; now it is shown as a share row with a menu for the actions (except enabling it, which is shown in the row itself), just like the other shares. The share link is no longer shown, either; now the link is got by clicking on a "Copy URL" menu item, which copies the link to the clipboard. As the clipboard is not accessible from the acceptance tests the URL is now extracted from the attributes of that menu item (although the menu item is clicked anyway to mimic the user behaviour). Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>	8 years ago
John Molakvoæ (skjnldsv)	562e2aa30b	Adjust acceptance tests to sidebar changes in Files app ... Before, each section of the Files app ("All files", "Favorites"...) had its own sidebar element. Now there is a single sidebar element for all the sections in the Files app. Signed-off-by: John Molakvoæ (skjnldsv) <skjnldsv@protonmail.com>	8 years ago
Daniel Calviño Sánchez	15c12eb027	Add acceptance tests for creation of subfolders in public shared folders ... Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>	8 years ago
Daniel Calviño Sánchez	1a2d9a2fdd	Extract common "wait for" functions to a helper class ... Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>	8 years ago
Daniel Calviño Sánchez	fcd6cf08e0	Generalize file list steps so a specific ancestor can be used ... The "FileListContext" provides steps to interact with and check the behaviour of a file list. However, the "FileListContext" does not know the right file list ancestor that has to be used by the file list steps, so until now the file list steps were explicitly wired to the Files app and they could be used only in that case. Instead of duplicating the steps with a slightly different name (for example, "I create a new folder named :folderName in the public shared folder" instead of "I create a new folder named :folderName") the steps were generalized; now contexts that "know" that certain file list ancestor has to be used by the FileListContext steps performed by certain actor from that point on (until changed again) set it explicitly. For example, when the current page is the Files app then the ancestor of the file list is the main view of the current section of the Files app, but when the current page is a shared link then the ancestor is set to null (because there will be just one file list, and thus its ancestor is not relevant to differentiate between instances) A helper trait, "FileListAncestorSetter", was introduced to reduce the boilerplate needed to set the file list ancestor from other contexts. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>	8 years ago
Daniel Calviño Sánchez	766135cb64	Generalize file list locators so a specific ancestor can be used ... The file list is used in other places besides the Files app (for example, the File sharing app); in those cases the locators for the file list elements are the same, but not for the ancestor of the file list. To make possible to reuse the file list locators in those cases too now they receive the ancestor to use. Note that the locators for the file actions menu were not using an ancestor locator because it is expected that there is only one file actions menu at a time in the whole page; that may change in the future, but for the time being it is a valid assumption and thus the ancestor was not added to those locators in this commit. Although the locators were generalized the steps themselves still use the "FilesAppContext::currentSectionMainView" locator as ancestor; the steps will be generalized in a following commit. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>	8 years ago
Daniel Calviño Sánchez	49f2ba16f0	Extract file list locators and steps to its own class ... Besides the extraction some minor adjustments (sorting locators for file action menu entries to reflect the order of the menu entries in the UI, moving parametrized locators like "createMenuItemFor" above the locators that use them and placing "descendantOf" calls always in a new line) were made too. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>	8 years ago
Daniel Calviño Sánchez	dab4a70bcf	Add acceptance test for renaming a file with the details view open ... Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>	8 years ago
Daniel Calviño Sánchez	e24a1c51e8	Wait for the shared link to be set in the acceptance tests ... When clicking on "Share link" in the "Sharing" tab of the Files app an input field with the link appears. That input field already exists in the DOM, although empty, before clicking on "Share link", and when that is done the proper value is set and then the input field is shown. In the acceptance tests "getValue()" can return the value of hidden elements too, so as long as an element exists its value is returned without waiting for the field to be visible. Due to this if the test code runs too fast the "I write down the shared link" step could be executed before the proper value was set, so the shared link got in that case would be an empty value, and this would lead to failures when the following steps were executed. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>	8 years ago
Daniel Calviño Sánchez	8916735dd3	Add missing timeout multiplier ... Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>	8 years ago
Daniel Calviño Sánchez	37238725d6	Fix typo in callback name ... Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>	8 years ago
Daniel Calviño Sánchez	065ab6bfff	Solve acceptance test failure due to clicks on covered elements ... Firefox and Chrome drivers for Selenium refuse to click on an element if the point to be clicked is covered by a different element, throwing an UnknownError exception with message "Element is not clickable at point ({x}, {y}). Other element would receive the click: {element}". Although in general that would be a legit error (as the user would not be able to click on the element) due to a bad layout, sometimes this can be just a temporal issue caused by an animation, in which case there would be no problem once the animation finished and the elements are all in their final location. Unfortunately, automatically handling those situations in which the problem is caused by an animation by just retrying a few times if the element to be clicked is covered before giving up would probably cause confusion instead of easing test writing. The reason is that if the center of the element is covered by another one the Firefox driver for Selenium tries to click on the corners of the element instead. The problem is that the coordinates used for the click are integer values, but Firefox has sub-pixel accuracy, so sometimes (depending on which corner is not covered and whether the left, top, width or height properties of the element to be clicked have a decimal component or not) the clicks silently land on a different HTML element (and that is with squared borders; with round borders they always land on a different HTML element. That was partially addressed for Selenium 3.0 by clicking first on the edges, but it would still fail if the middle point of the edges is covered but not the corners). It is not possible to fix or even detect all that from the tests (except maybe with some extreme hacks involving accessing private PHP members from Mink and bypassing or replacing the standard JavaScript executed by the Firefox driver with a custom implementation...), so it is not possible to ensure that clicks during an animation will land on the right element (in fact it is not possible even on static elements, although except when the layout is wrong there should be no problem); sometimes retrying a click when the element is covered would solve the problem, sometimes it would cause a different element to be clicked (and sometimes there would be even no retry, as the first click would have silently landed on a different element than the expected one). Therefore, a different approach must be used. Instead of trying to automatically handle clicks during animations the tests must be written being aware of the problem and thus waiting somehow for the animations that can cause a problem to end before performing the clicks. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>	8 years ago
Daniel Calviño Sánchez	9ff0941c07	Replace inline favorite action with just a favorite icon ... This is a preparatory step for a following commit in which the position of the favorite icon and the checkbox will be swapped; in that new design the favorite icon is no longer expected to be an action but just a simple mark on whether the file is favorited or not (the action is expected to be triggered then only from the file actions menu). The favorite icon is now fully shown or completely hidden depending on whether the file is favorited or not. As the icon is just informative but no longer an action now it does not change when hovered or focus. In the same way, the alternative text when the file is not favorited now it is not "Favorite" (an action) but "Not favorited" instead. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>	8 years ago
Daniel Calviño Sánchez	0e933ee6b9	Update acceptance tests to favorite files through the file actions menu ... Currently a file can be favorited either through the inline action or through the file actions menu. However, the inline action will be removed in a following commit and then it will be possible to do it only through the file actions menu. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>	8 years ago
Daniel Calviño Sánchez	b43a74bdcd	Add acceptance tests for unselecting items in dropdown for tags ... Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>	9 years ago
Daniel Calviño Sánchez	71b90cdeff	Extract app navigation elements to its own context ... The app navigation is not exclusive to the Files app but a generic component used by other apps too, so its locators and steps should be in its own context. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>	9 years ago
Daniel Calviño Sánchez	8deab238cc	Fix typo ... Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>	9 years ago
Daniel Calviño Sánchez	6fa5c33af4	Add acceptance tests for sorting of favorite files ... Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>	9 years ago
Daniel Calviño Sánchez	423136d319	Extract duplicated code to a method ... Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>	9 years ago
Daniel Calviño Sánchez	be02b3df28	Add acceptance tests for showing the input field for tags ... Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>	9 years ago
Daniel Calviño Sánchez	41412088db	Update acceptance tests for issue #4921 ... Acceptance tests opened the details view by clicking on the middle of the file row, but due to the changes made in issue #4921 that now opens the file instead; this commit updates the acceptance tests to open the details view through the "Details" item in the file actions menu. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>	9 years ago
Daniel Calviño Sánchez	762a8e0b76	Remove "content" locator from acceptance tests ... The "content" locator uses the "named" Mink selector and the "content" Mink locator to find the element. The "named" Mink first tries to find the elements whose content match exactly the given content but, if none is found, then it tries to find elements that just contain the given content. This behaviour can lead to hard to track issues. Finding the exact match and, if not found, finding the partial match is done in quick succession. In most cases, when looking for an exact match the element is already there, it is returned, and everything works as expected. Or it may not be there, but then it is not there either when finding the partial match, so no element is returned, and everything works as expected (that is, the actor tries to find again the element after some time). However, it can also happen that when looking for an exact match there is no element yet, but it appears after trying to find the exact match but before trying to find the partial match. In that situation the desired element would be returned along with its ancestors. However, as only the first found element is taken into account and the ancestors would appear first the find action would be successful, but the returned element would not be the expected one. This is highly unlikely, yet possible, and can cause sporadic failures in acceptance tests that, apparently, work as expected. Using a "named_exact" Mink selector instead of the "named" Mink selector does not provide the desired behaviour in most cases either. As it finds any element whose content matches exactly the given content, looking for "Hello world" in "<div><p><a>Hello world</a></p></div>" would match the "div", "p" and "a" elements; in that situation the "div" element would be the one returned, when typically the "a" element would be the expected one. As it is error prone and easily replaceable by more robust locators the "content" locator was removed from the predefined ones (although it can still be used if needed through the "customSelector" method in the builder object). Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>	9 years ago
Daniel Calviño Sánchez	16b4eecb05	Add acceptance tests for closing details view in Files app ... Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>	9 years ago
Daniel Calviño Sánchez	316710bcb1	Add acceptance tests for sharing password protected links ... Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>	9 years ago
Daniel Calviño Sánchez	2f80025ec2	Move acceptance tests from build/acceptance to tests/acceptance ... Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>	9 years ago
Daniel Calviño Sánchez	1203369ea6	Add acceptance tests related to login ... Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>	9 years ago
Daniel Calviño Sánchez	7c07f01d59	Add actors for test scenarios ... An actor plays the role of an end-user in the test scenario. As such, each actor has its own web browser session used to perform the actions specified by the steps of the scenario. Only one actor is active at a time in a test scenario, and the current actor can be set through the "I act as XXX" step; from then on, all the steps are performed by that actor, until a different actor is set by calling "I act as XXX" again. If no actor was explicitly set in a scenario then the default actor, unsurprisingly named "default", is the one used. The ActorContext class is added to provide automatic support for all that. To use the ActorContext, besides adding it to the context list in "behat.yml", a Mink session for each actor used in the features must be specified in "behat.yml". Once done other Contexts just need to implement the ActorAwareInterface (which can be done simply by using the ActorAware trait) to have access to the current Actor object of the test scenario; as the Actor object provides its own session other Contexts do not need to extend from RawMinkContext. The ActorContext is itself a RawMinkContext, so it automatically receives the base URL of the Nextcloud test server run by NextcloudTestServerContext and propagates that base URL to all the actors. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>	9 years ago
Daniel Calviño Sánchez	b5fba56499	Add basic files for the automated acceptance test system ... The acceptance tests verify that a Nextcloud server works as expected from the point of view of an end-user. They are specified as user stories using Behat paired with Mink, which provides web browser automation. Mink supports several browser emulators, but the system is set up to use Selenium, as it is FOSS and the one that better reflects the use of a web browser by an end-user (as, in fact, it controls real web browsers). Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>	9 years ago
Roeland Jago Douma	0228bc6e66	ACCEPT_LANGUAGE goes before default_langauge ... See https://github.com/nextcloud/server/issues/970 Before we had 1. Users settings in personal settings 2. Admins default language settings 3. Accept-Language settings of the browser However this is not in line with https://www.w3.org/International/questions/qa-lang-priorities So this changes the order to 1. Users settings in personal settings 3. Accept-Language settings of the browser 2. Admins default language settings	9 years ago
root	bd65a17203	Nextcloud license header for new files	10 years ago
root	32fb6beac3	final changes	10 years ago
root	02ec8b1726	New LDAPProvider for user_ldap	10 years ago
Joas Schilling	ba87db3fcc	Fix others	10 years ago
Thomas Müller	682821c71e	Happy new year!	10 years ago
Thomas Müller	bacf1603ff	Adding ocs/v2.php with status code mapper	11 years ago
Morris Jobke	f63915d0c8	update license headers and authors	11 years ago
Jenkins for ownCloud	b585d87d9d	Update license headers	11 years ago
Morris Jobke	06aef4e8b1	Revert "Updating license headers" ... This reverts commit 6a1a4880f0.	11 years ago
Jenkins for ownCloud	6a1a4880f0	Updating license headers	11 years ago