@PVince81, thanks for your PR! By analyzing the history of the files in this pull request, we identified @DeepDiver1975, @bartv2 and @macjohnny to be potential reviewers.

Hmm, I'm surprised that it already works so far. That was easy.

However adjusting all other pieces of the UI to accomodate for the display name will be more work.

In this PR I'll focus mostly on backend support + share display name.

Now I see that there is actually another mechanism to add new actions, the implementsAction method.

Do we want to keep doing this ? If yes I'd get rid of IGroupBackend and simply add an action getGroup to the list. I personally would prefer if in the future we'd simply have several interfaces and action availability could be checked with instanceof.

• clarify if we want to use implementsAction for getGroup instead of a new interface IGroupBackend

I guess that depends on the number of conditional actions, or how the UI would look like.

Taking the files as an example, each file might show a different set of actions: delete the file, rename the file, share the file... the UI would need to know what actions are available for the file before executing that action to show the corresponding button (if the delete action isn't supported, why would we need to show the button?)
Although this can be implemented by using interfaces, the number of interfaces that we'd need to implement is very high, so this doesn't seem a good approach in this case.

On the other hand, for this case we could have 2 types of group backends: read-only (such as LDAP) and read-write (the default one). If this is the case, using interfaces might be an option, but we MUST consider if all the possible backends would fit in any of those groups.
Notice that with this approach there won't be a backend that might implement only a small action set; it would be all or nothing.

Yeah, I know... Ok, I guess I'll just create a new action "has function to get group details (including display name" instead of a brand new interface.

The trouble with "implementsAction" is that there is no interface to enforce method signatures, and also no way to document these functions.

I wonder if a "command pattern" would fit here (for reference: https://en.wikipedia.org/wiki/Command_pattern). The conditional methods would return a Command object (according to the pattern, not a Symfony Command object) to be run by the manager, or null if it doesn't implement the method.

So, instead of "backend, run this method" would be "backend, I want to run this, get me the method to do so".

Hmm not sure, command pattern might sound like overkill. Command pattern is usually better for stuff like real actions, file actions, etc. But here most of the time it's not really an action, it's just reading data from the DB.

I guess it's probably better to not invent new ways right now and have half the code use the new way and the half use the old way. I'll use the old way here with "implementsAction".

Argh... now I ported everything to implementsAction and I find that it's not possible to mock the new method without having a real class or interface implementing it...

Fixed, added unit tests.

I think this is ready for review @jvillafanez @DeepDiver1975

@jvillafanez fixed now.

Fixed all the strtolower now, rebased and squashed for a clean history

👍

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.