Skip to content
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

Text-editor extensions #7967

Merged
merged 3 commits into from
Jun 7, 2023
Merged

Conversation

diocas
Copy link
Contributor

@diocas diocas commented Nov 14, 2022

Sets canBeDefault: true to ensure that files are not downloaded first.

Adds a new configuration parameter that allows us to open a configurable number of other extensions.

@diocas
Copy link
Contributor Author

diocas commented Dec 2, 2022

It looks like canBeDefault: true is preventing us from opening .md on codimd by default... @elizavetaRa can you check please? Maybe instead of using that, what we need to do is ensuring that the download action is always the last (so any app takes precedence)

@kulmann
Copy link
Contributor

kulmann commented Dec 5, 2022

It looks like canBeDefault: true is preventing us from opening .md on codimd by default... @elizavetaRa can you check please? Maybe instead of using that, what we need to do is ensuring that the download action is always the last (so any app takes precedence)

Yes, at the moment an app that handles a specific file extension explicitly (like the text-editor that explicitly handles .txt and .md) would have precedence over the external app. The perfect solution is probably to let the user choose which app they want to use for a specific file type.

@diocas
Copy link
Contributor Author

diocas commented Dec 5, 2022

That would be the best, but I would be surprised if we could have that in the short term, or am I wrong? :)

I've asked @elizavetaRa to have a look and suggested we order the actions like following: 1st canBeDefault, 2nd all remaining apps, 3rd system actions (like download). Then we can always execute the first one on the list.

To me it makes more sense that we use an app if one is registered. What do you think, @kulmann ?

@kulmann
Copy link
Contributor

kulmann commented Dec 5, 2022

That would be the best, but I would be surprised if we could have that in the short term, or am I wrong? :)

Yes, nothing for short term. :trollface:
One could store the user choice in the browsers localStorage, like we already do for other user choices (e.g. showing/hiding hidden files, showing/hiding file extensions in file names). My team can't work on that at the moment.

I've asked @elizavetaRa to have a look and suggested we order the actions like following: 1st canBeDefault, 2nd all remaining apps, 3rd system actions (like download). Then we can always execute the first one on the list.

To me it makes more sense that we use an app if one is registered. What do you think, @kulmann ?

The name canBeDefault would be pretty misleading then, as it would just be a boolean way of prioritizing certain apps over other apps. But I agree with the approach. If we have an app for a mime type, it doesn't make sense to ignore it when trying to open a file.

@diocas
Copy link
Contributor Author

diocas commented Dec 5, 2022

The name canBeDefault would be pretty misleading then, as it would just be a boolean way of prioritizing certain apps over other apps.

Isn't this what we're doing already in a way? Should we rename it?

@kulmann
Copy link
Contributor

kulmann commented Dec 5, 2022

The name canBeDefault would be pretty misleading then, as it would just be a boolean way of prioritizing certain apps over other apps.

Isn't this what we're doing already in a way? Should we rename it?

Yes and yes 😄 Do you have a proposal for a better var name?

@diocas
Copy link
Contributor Author

diocas commented Dec 6, 2022

priority? Or too generic?

@kulmann
Copy link
Contributor

kulmann commented Dec 6, 2022

works for me, priority or hasPriority? (I prefer hasPriority but don't care too much).

So as a result: we want to sort all the apps and external-apps in one pool by following criteria:

  • hasPriority=true first, hasPriority=false / absent last
  • "dedicated" apps first, external-apps last
  • by name

Correct?

@elizavetaRa
Copy link
Member

works for me, priority or hasPriority? (I prefer hasPriority but don't care too much).

So as a result: we want to sort all the apps and external-apps in one pool by following criteria:

  • hasPriority=true first, hasPriority=false / absent last
  • "dedicated" apps first, external-apps last
  • by name

Correct?

sounds good! The priority sort should apply after the "external apps last" sort

@kulmann
Copy link
Contributor

kulmann commented Feb 9, 2023

sounds good! The priority sort should apply after the "external apps last" sort

Ok. What's the next step, can you take care of finishing this PR?

@elizavetaRa elizavetaRa force-pushed the up_text_editor_extensions branch 2 times, most recently from d3d76bd to 42f1656 Compare March 24, 2023 08:33
@sonarqubecloud
Copy link

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

0.0% 0.0% Coverage
0.0% 0.0% Duplication

@ownclouders
Copy link
Contributor

ownclouders commented Mar 24, 2023

Results for e2e-tests oCIS https://drone.owncloud.com/owncloud/web/36303/12/1

💥 To see the trace, please open the link in the console ...

npx playwright show-trace https://cache.owncloud.com/public/owncloud/web/36303/tracing/public-link-for-space-alice-2023-6-6-08-49-46.zip

💥 The e2e-ocis tests pipeline failed. The build has been cancelled.

@diocas
Copy link
Contributor Author

diocas commented Mar 24, 2023

@kulmann please let us know if you prefer to split the PR into text-editor stuff and the more general default extensions handling.

@elizavetaRa
Copy link
Member

@kulmann and please let us know if you see the use case to implement hasPriority for internal editors as well. Right now there are no internal editors that are in conflict with each other to open the same extension, so the internal editor will be taken first unless there is a hasPriority for external app. But maybe something is planned for the future?

@@ -12,6 +12,7 @@ export interface Action<T = ActionOptions> {
componentType: 'button' | 'router-link'
class: string
canBeDefault?: boolean
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @diocas and @elizavetaRa

my intend (see discussion, I think yours as well at some point) was to rephrase canBeDefault to hasPriority. Meaning, having both in parallel now makes things unnecessarily complex. 🙈

On top of that: I think the approach with the app provider - define via config which app has priority - is the way to go. An extension developer should never be the one who decides which application has priority over another one. The admin has to decide that, so that's configuration only, not code.

Could you look into realizing the following?

  • get rid of canBeDefault entirely
  • introduce hasPriority but only through configuration, nothing hardcoded. For the app provider apps it's already there with the default_application attribute on mime types.
  • determine the app that gets opened on click in file list (= "default app") by throwing all standalone apps and all app provider apps into one list, sort them by priority, then by internal vs app provider, and pick the first.

What do you think? Does that make sense?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@diocas @elizavetaRa anything we can do to support you here? Do you have feedback or further need for clarification?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@elizavetaRa has been a bit busy. I'll check with her tomorrow when she can fit this in her tasks.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@diocas if you're generally fine with what Benedikt suggested I could also take over?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pascalwengerter @kulmann I'll take this issue, will update the pr these days, thanks for waiting!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kulmann 2 questions:

  1. what is the purpose of "canBeDefault" in terms priority in the composables/actions files like web-app-files/src/composables/actions/files/useFileActionsCreateNewFile.ts?
  2. "introduce hasPriority but only through configuration, nothing hardcoded." You mean move setting hasPriority of all the extensions, also editors to config.json instead of index.ts of each extension?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hey @elizavetaRa - cool that you are working on this, thank you! 🤩

  1. in the case of file action composables, canBeDefault doesn't belong there. Could be removed entirely, doesn't make sense.
  2. yes, that's exactly what I meant. :-) Please note that providing config for an app is not possible in the apps array of the config.json, but only for the external_apps array. That one is a bit misleading, name wise, but that's fine for now. Only means that if an admin wants to give an app priority over another one for the same file type they need to define the app in external_apps. We need to clean that up (big time), but I wouldn't do that in the scope of this PR. So please just keep the assumption that providing config for an app is only possible in the external_apps array of the config.json. That's fine.

Copy link
Member

@elizavetaRa elizavetaRa Jun 1, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kulmann @pascalwengerter Following example of config.json with use case: extension A (not external app) opens file types.aaa and .txt. Type .txt should have hasPriority over internal text editor. Would it look something like that?

  "external_apps": [
    ...,
    {
      "id": "A",
      "path": "/aaa",
      "config": {
        "fileExtensions": [
          {
            "extension": "txt",
            "hasPriority": true
          }
        ]
      }
    }
  ],

Or should we call the option something like "priorityExtensions" and set priority to all file types that are in this list?

Copy link
Member

@elizavetaRa elizavetaRa Jun 1, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So proposal 2 for config.json:

  "external_apps": [
    ...,
    {
      "id": "A",
      "path": "/aaa",
      "config": {
        "priorityExtensions": ["txt"]
        ]
      }
    }
  ],

@elizavetaRa elizavetaRa force-pushed the up_text_editor_extensions branch from 42f1656 to ca5a310 Compare May 23, 2023 14:34
@elizavetaRa elizavetaRa force-pushed the up_text_editor_extensions branch from ca5a310 to 586dfe7 Compare June 1, 2023 09:54
@tbsbdr
Copy link

tbsbdr commented Jun 1, 2023

@elizavetaRa you will take care of this, right?

@elizavetaRa
Copy link
Member

@tbsbdr on it, yes

@elizavetaRa elizavetaRa force-pushed the up_text_editor_extensions branch from 2b7b602 to bd3ddce Compare June 5, 2023 08:37
@elizavetaRa elizavetaRa force-pushed the up_text_editor_extensions branch from bd3ddce to 06bead3 Compare June 5, 2023 08:53
@pascalwengerter
Copy link
Contributor

@elizavetaRa could you add a changelog item? :)

Copy link
Contributor

@kulmann kulmann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One tiny nitpick (see comment), otherwise works like a charm 👍

let primaryExtensions = (window as any).__$store.getters.extensionConfigByAppId(appId)
.primaryExtensions || ['txt', 'md']

let extraExtensions = config.extraExtensions || []
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the extraExtensions are never re-used after they got pushed into the extensions array. So I'd be in favour of the following one liner to keep it shorter / without the extraExtensions variable assignment:

extensions.push(...(config.extraExtensions || []).map((ext) => ({ extension: ext })))

Also, please move that line directly below const config = ... and above let primaryExtensions = ... for following logical grouping:

  1. assign all possible extensions into the extensions array.
  2. define primaryExtensions
  3. return the extensions in the correct format

@sonarqubecloud
Copy link

sonarqubecloud bot commented Jun 7, 2023

SonarCloud Quality Gate failed.    Quality Gate failed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 10 Code Smells

0.0% 0.0% Coverage
0.0% 0.0% Duplication

Copy link
Contributor

@kulmann kulmann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice, thank you for taking care! 💪

@kulmann kulmann merged commit 4529f06 into owncloud:master Jun 7, 2023
@tbsbdr
Copy link

tbsbdr commented Jun 13, 2023

relates to 323030a

@tbsbdr tbsbdr mentioned this pull request Jun 26, 2023
37 tasks
@tbsbdr tbsbdr added this to the CERN Web Merge milestone Jul 10, 2023
@micbar micbar mentioned this pull request Jul 24, 2023
68 tasks
@diocas diocas deleted the up_text_editor_extensions branch July 24, 2023 13:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants