Before, the avatar for a circle share was generated using the
"share_with" field as the seed for "imageplaceholder". Due to this, when
the "share_with" field is set to the circle ID the character shown in
the avatar was just a random character instead of the first character of
the display name. Now the "share_with" is still used as the seed for the
colour, but the display name is used as the text of the avatar.
This adds support for "share_with" fields set to the circle ID while
being backwards compatible with "share_with" fields set to the circle
name.
Note that when "share_with" fields is set to the circle name the colour
of the avatar is different in the list of suggested sharees and in the
list of current sharees, but that also happened before these changes
(due to a different seed being used in each place).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When a share is shared with a circle the "share_with" field returned by
the API endpoint was always set to the name of the circle. However, the
name is not enough to identify a circle. The Circles app now provides
the ID of the circle in the "shared with" field of a Share, so this
commit modifies the API endpoint to set the "share_with" field to the ID
of the circle when provided by the Circles app.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
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>
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>
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>
Avoids errors when the size exceeds MAX_INT because of the cast to int. Better cast it to float to avoid this.
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
Fixes#8705
If the file does not exist (for whatever reason). It is never cached. No
matter what the depscache etc tell you.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Nextcloud bot
Roeland Jago Douma
Daniel Calviño Sánchez
Arthur Schiwon
Morris Jobke
Roeland Jago Douma
Joas Schilling
Julius Härtl