Workflow frontend overhaul

[juliusknorr]

This PR still requires quite some cleanup and polishing, once the backend changes are ready to be integrated from #16682

TODO

• Unified UI for managing workflow operations
• Adjust endpoints to fetch all operations
• Add endpoint to test if operations are valid
• Design polishing as discussed with @jancborchardt
  • Rule state indicator that turns into save button
  • Turn add rule button into placeholder input
  • Adjust font color of when/and
  • When you click one of the 3 workflows, that chooser vanishes. I’d say it should always stay up top?
  • [Polishing] On narrow sizes, the arrow and result should be below the conditions, and the select2’s of the conditions also need to get narrower.
  • [Polishing] We need to do a whole lot of detail checking on margins and sizes. E.g. when you click into the "Add a new filter" field, it moves slightly. Similar for when you focus the 3rd field of a condition, the row below moves because of the delete icon showing.
  • As soon as all 3 selects of the condition show, the delete icon only shows when you focus the 3rd field, not when you change the comparator or the first field.
  • I’d say .icon-close (❌) is a better icon for removing the current line than the "Delete" trash.
  • The .actions__item element could do with a cursor: pointer, but because our reset has cursor: default on div and h3 we need to set it on those elements too.
  • We could think if a colored bar on the left of the section in the color of the action make sense, or something else visual. Maybe also the icon should be colored then, not black? E.g. block icon should be block red, tag icon should be whatever is used above (currently primary) and Convert to PDF icon should be just the colored PDF icon. Then there’s symmetry in the color.
• Integrate operation/event/check data from backend once ready
  • Entities/related events
  • Operations: class, title, description, color, icon, supported entities/events
  • Handle IComplexOperation
  • [Waiting for backend] List of checks depending on entity
• Migrate check plugins
  • FileName
  • FileSize
  • FileMimeType with predefined sets of types
  • RequestRemoteAddress
  • RequestURL
  • RequestTime
  • FileSystemTags
  • UserGroupMembership
• [Waiting for backend] Migration of individual apps
  • files_accesscontrol
  • files_automatedtagging Operation options
  • workflow_pdfconverter Operation options

ToDo in a follow up PR

• Move system tag selector to vue components Implement predefined multiselects nextcloud-libraries/nextcloud-vue#568
• Handle validation on inputs before sending (enhancement)
• Check if fetching tags incremental is working

Extending the frontend

Registering a new check

Check with custom validate/placeholder

OCA.WorkflowEngine.registerCheck({
class: 'OCA\\WorkflowEngine\\Check\\RequestRemoteAddress',
name: t('workflowengine', 'Request remote address'),
operators: [
{ operator: 'matchesIPv4', name: t('workflowengine', 'matches IPv4') },
{ operator: '!matchesIPv4', name: t('workflowengine', 'does not match IPv4') },
{ operator: 'matchesIPv6', name: t('workflowengine', 'matches IPv6') },
{ operator: '!matchesIPv6', name: t('workflowengine', 'does not match IPv6') }
],
placeholder: (check) => {
if (check.operator === 'matchesIPv6' || check.operator === '!matchesIPv6') {
return '::1/128'
}
return '127.0.0.1/32'
},
validate: (check) => {
if (check.operator === 'matchesIPv6' || check.operator === '!matchesIPv6') {
return validateIPv6(check.value)
}
return validateIPv4(check.value)
}
})

Check with custom vue component

import FileSystemTag from './components/FileSystemTag.vue'
OCA.WorkflowEngine.registerCheck({
class: 'OCA\\WorkflowEngine\\Check\\FileSystemTags',
name: t('workflowengine', 'File system tag'),
operators: [
{ operator: 'is', name: t('workflowengine', 'is tagged with') },
{ operator: '!is', name: t('workflowengine', 'is not tagged with') }
],
component: FileSystemTag
})

Registering a new operation in the frontend

import Tag from './components/Tag.vue'
OCA.WorkflowEngine.registerOperator({
id: 'OCA\\FilesAutomatedTagging\\Operation',
name: t('files_automatedtagging', 'Tag a file'),
description: t('files_automatedtagging'),
iconClass: 'icon-tag-white',
color: 'var(--color-success)',
operation: '',
component: Tag
})

Screenshots

[jancborchardt]

Doing make or make dev-setup doesn’t work in the apps/workflowengine folder. Is it documented somewhere how to do it? Cause atm I’m seeing a blank page. ;)

[rullzer]

Doing make or make dev-setup doesn’t work in the apps/workflowengine folder. Is it documented somewhere how to do it? Cause atm I’m seeing a blank page. ;)

Run in in the main folder. We have all the apps using the same webpack config else we'd be updating 14 apps all the time instead of just 1 folder

[jancborchardt]

Some additional points:
Edit: Moved to OP

[blizzz]

When I select the "Tag a file" action, I immediately get a tooltip Operation OCA\FilesAutomatedTagging\Operation does not exist. I guess I’m missing some separate app, which would be combined in a separate pull request cc @blizzz

Automated Tagging.

[juliusknorr]

@jancborchardt I've fixed a bunch of design issues we have discussed and added some screenshots of the current state to the 1st post. Feedback is welcome

[jancborchardt]

Looking at the screenshots and using the app again, it seems that there’s a loooot of horizontal whitespace we can’t really do much about with a list-type layout. It’s all a bit floating in the air.

It seems that vertical boxes for the actions would fit better, as we thought about for mobile @juliushaertl? It would have the maximum width of the 3 inputs which are in the "When" condition.

When: 📁 file is updated
and [ … … … ] [ is ] [ … … … …]
and [ … … … ] [ is ] [ … … … …]

Then → 📰 Convert to PDF
[ Keep original, preserve existing PDFs ]
( ✔ Active )

So then two or even three of these blocks could be next to each other on desktop.
What do you think?

[juliusknorr]

It seems that vertical boxes for the actions would fit better, as we thought about for mobile @juliushaertl? It would have the maximum width of the 3 inputs which are in the "When" condition.

I don't think that would be a good idea, since the height of the entry is variable to how many and conditions are used and if the operation provide additional options (e.g. automated tagging provides an input field for the list of tags, but this could by anything that needs to be configurable)

How about just reducing the height a bit by using a more condensed styling for the operation like this:

[jancborchardt]

@juliushaertl ok, already looks a bit better! :)

[ChristophWurst]

Some nitpicks from the fraction of code I've reviewed :)

[ChristophWurst]

Suggested change

	Checks() {
	checks() {

[ChristophWurst]

l10n

[ChristophWurst]

you could move this up to the module initialization block so it only runs once. OCP should be ready before the app's code

[ChristophWurst]

move this and the other regexes out of the functions so they are only created once

and use const :)

[blizzz]

good base (mentioned smaller things for follow ups)