-
Notifications
You must be signed in to change notification settings - Fork 159
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[web] Provide Embed Mode for Location and File Picking #9768
Comments
I assume multi select is only supposed to be supported from a single folder, right? |
@AversaFTW please provide feedback |
A technical question coming up (maybe @dschmidt can answer this).
Is there only the manual switch or is there also auto detection of system settings that would need to be taken care of? |
Currently there is no auto detection although we already thought about implementing it. But that's not relevant for this iteration I'd say. |
full ack. Not part of this iteration, but in the long run: |
Some notes regarding the messenger integration:
|
Okay, so to get this right: We have multiple ocis server instances running, but there will be only one instance of embedded Web? Meaning this instance needs to be able to dynamically talk to the server instances? The challenge here is the fact that Web needs to know the server config (= URL) quite early during the bootstrap process. One (hacky) approach would be to introduce a new config in Web which stores all the servers and their respective URLs. The user then selects one of the schools which Web will use as server. All this would need to happen before the bootstrap process, hence it can't be implemented via an extension. Honestly, the best/proper solution would be to host one embedded Web instance per server instance. Of course this would require additional architecture, e.g. a central entry point which gathers all available instances and redirects the user to their respective instance (via Webfinger - Web already has a Webfinger package for this use case). @LukasHirt The File Picker currently is able to load the config dynamically, right? Could you (or @AversaFTW ) enlighten me a bit about the current process, how does a user select/enter a school, how/where is this selection persisted and used? |
@AversaFTW can you please clarify the deployment scenario? I.e. does each school has its own oCIS instance that the file picker/web embed is connecting to? I agree that having the web in each instance on its own (as is basically done in standard deployment) would simplify things.
File picker fetches the json config file from given URL. So every time the file picker is initialised, the fetch is done and then the component mounts. Alternative (which seems to be broken currently) is providing the config via prop. That skips the fetch but overall has the same process. |
So, I am in the middle of the research and have some open questions... Integration pointOverall the whole embed mode seems like an extension of the files app which then would make sense to keep the code contained in there as well. But that breaks the layout a bit as the actions (per visuals) are located outside of the app container (meaning the actual white box on the visuals). Solutions
Embed configWe obviously need to be able to assert whether the UI is rendered in embed mode or "regular" mode. Generally speaking, I would say let's simply add a query param. Any objections? X-Frame-Options headerFrom what I checked, the X-Frame-Options header is currently set to sameorigin. I guess we might potentially need to have this configurable. Where do we handle this? In oCIS itself? Should we somehow separate the embed mode so that the regular UI is not affected by that change? @JammingBen @dschmidt can you please let me know what you think about the points above? Thanks! |
Notes from todays follow up:
|
So the proposal would be to have one button that inserts a link and one button that attaches one/many files/s (sends a copy), right? |
Sounds reasonable to me. @AversaFTW can you please let us know if it works for you as well? |
Sure, that sounds good. |
The initial implementation is done. Any following work is now being tracked in their own tickets. Can we close this? @kulmann |
Description
User Stories
Value
Acceptance Criteria
Select
: Returns resource (same as https://owncloud.dev/integration/file_picker/installation/#buttons-and-events)Cancel
: Closes the embedded view (=dialog)Definition of ready
[ ] everybody needs to understand the value written in the user story
[ ] acceptance criteria has to be defined
[ ] all dependencies of the user story need to be identified
[ ] feature should be seen from an end user perspective
[ ] user story has to be estimated
[ ] story points need to be less then 20
Definition of done
[ ] functionality described in the user story works
[ ] acceptance criteria are fulfilled
[ ] code review happened
[ ] CI is green
[ ] critical code received unit tests by the developer
[ ] automated tests passed (if automated tests are not available, this test needs to be created and passed
[ ] no sonar cloud issues
Visuals
Integration within element messenger
Integration example within a canvas Web Application
superseeds / fixes owncloud/file-picker#242
superseeds / fixes owncloud/file-picker#243
superseeds / fixes owncloud/file-picker#244
superseeds / fixes owncloud/file-picker#245
superseeds / fixes owncloud/file-picker#246
superseeds / fixes owncloud/file-picker#247
superseeds / fixes owncloud/file-picker#248
The text was updated successfully, but these errors were encountered: