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

Add support to customize UI components rendering #12

Closed
wants to merge 11 commits into from

Conversation

maheichyk
Copy link
Contributor

@maheichyk maheichyk commented Mar 15, 2023

This PR suggest to extend module API with possibility to control rendering of UI Components.

Signed-off-by: Mikhail Aheichyk <mikhail.aheichyk@nordeck.net>
@maheichyk maheichyk marked this pull request as ready for review March 15, 2023 08:45
@maheichyk maheichyk requested a review from a team as a code owner March 15, 2023 08:46
Signed-off-by: Mikhail Aheichyk <mikhail.aheichyk@nordeck.net>
@maheichyk
Copy link
Contributor Author

This PR relates to this draft in matrix-react-sdk: matrix-org/matrix-react-sdk#10382 Could you please review?

Copy link

@SimonBrandner SimonBrandner left a comment

Choose a reason for hiding this comment

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

Looks sane

src/lifecycles/UiComponentLifecycle.ts Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
Mikhail Aheichyk and others added 5 commits June 15, 2023 17:43
Co-authored-by: Šimon Brandner <simon.bra.ag@gmail.com>
Signed-off-by: Mikhail Aheichyk <mikhail.aheichyk@nordeck.net>
Signed-off-by: Mikhail Aheichyk <mikhail.aheichyk@nordeck.net>
Signed-off-by: Mikhail Aheichyk <mikhail.aheichyk@nordeck.net>
Copy link
Contributor

@germain-gg germain-gg left a comment

Choose a reason for hiding this comment

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

I think the code looks fair, but I'm lacking a bit of context here

  • It appears that those UI customisations are already possible today. Why advantages do you see with the approach you're suggesting?
  • How can we ensure that files stay in sync across codebases?

src/lifecycles/UIComponentLifecycle.ts Show resolved Hide resolved
src/lifecycles/UIComponentLifecycle.ts Show resolved Hide resolved
Comment on lines +49 to +66
/**
* Components that lead to a user being invited.
*/
InviteUsers = "UIComponent.sendInvites",

/**
* Components that lead to a room being created that aren't already
* guarded by some other condition (ie: "only if you can edit this
* space" is *not* guarded by this component, but "start DM" is).
*/
CreateRooms = "UIComponent.roomCreation",

/**
* Components that lead to a Space being created that aren't already
* guarded by some other condition (ie: "only if you can add subspaces"
* is *not* guarded by this component, but "create new space" is).
*/
CreateSpaces = "UIComponent.spaceCreation",
Copy link
Contributor

Choose a reason for hiding this comment

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

I believe a more appropriate avenue for this kind of feature would be to piggy back off user permissions on a server as described in matrix-org/synapse#7731

I appreciate this issue has not received a lot of attention in recent times, but it seems like a more forward looking way to handle this

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This probably could be used if implemented already, but it seems just and idea at the moment. But we would like some users (guests with special user ids) not to be able to invite, create rooms or spaces. Would be good to use a module API for that.

Copy link
Contributor

@germain-gg germain-gg Jul 7, 2023

Choose a reason for hiding this comment

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

This is already possible using a feature flag UIFeature.widgets as defined in UIFeature.ts. See settings.md in the matrix-react-sdk for usage

Copy link
Contributor Author

Choose a reason for hiding this comment

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

UIFeature.widgets seems to toggle rendering of the integration manager. How should this be connected with InviteUsers, CreateRooms, CreateSpaces functionality to be hidden or shown based on user ids? Could you please clarify?

matrixUserId: string
) => void;

export enum UIComponent {
Copy link
Contributor

Choose a reason for hiding this comment

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

This seem to be a copy/paste of UIFeature.ts in the matrix-react-sdk.
Before considering this i'd want to explore ways to keep the two in sync. I'm actually unsure what value this brings over the existing possible customisations?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, that is true, I have mentioned this in my first comment. Maybe a solution could be to change react-sdk to use a UIComponent from this PR? Or any other idea?

Based on this matrix-org/matrix-react-sdk#9931 (comment) we may think that component visibility customization API is deprecated in favor of module API.

This solution would simplify our deployment, maybe quite a lot. We plan to put all visibility customizations and landing for guests in a separate module.

@maheichyk maheichyk requested a review from germain-gg July 6, 2023 14:05
Copy link
Contributor

@germain-gg germain-gg left a comment

Choose a reason for hiding this comment

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

Thank you for replying to the comments in line. I don't think you've adressed the two questions asked in the original review i gave to this PR.
I'd be interested to hear more about this, before that moves forward

@maheichyk
Copy link
Contributor Author

@germain-gg please find my answers/comments:

* It appears that those UI customisations are already possible today. Why advantages do you see with the approach you're suggesting?

Based on this matrix-org/matrix-react-sdk#9931 (comment) we may think that component visibility customization API is deprecated in favor of module API.

In this PR matrixUserId is passed into the module and can be used to decide if component should be shown or not. We disable some functionality for the guest users with specific ids. It seems to be bot possible within existing APIs.

This solution could simplify our deployment. We plan to put all visibility customizations logic and landing for guests into a separate module.

* How can we ensure that files stay in sync across codebases?

A solution could be to change matrix-react-sdk to use a UIComponent from this PR.

@germain-gg germain-gg requested review from germain-gg and removed request for germain-gg July 13, 2023 07:59
Mikhail Aheichyk added 2 commits July 20, 2023 16:58
Signed-off-by: Mikhail Aheichyk <mikhail.aheichyk@nordeck.net>
@maheichyk
Copy link
Contributor Author

@germain-gg I changed this PR a bit, could you please have a look? Maybe PR can be moved forward.

@Johennes
Copy link
Contributor

Johennes commented Sep 5, 2023

@dhenneke / @maheichyk just checking, is this still something you're hoping to get landed?

# Conflicts:
#	README.md
#	src/lifecycles/types.ts
Signed-off-by: Mikhail Aheichyk <mikhail.aheichyk@nordeck.net>
@maheichyk
Copy link
Contributor Author

@Johennes yes would be great to have it, thanks for you message! I have updated the branch to latest main changes.

@Johennes
Copy link
Contributor

Johennes commented Sep 6, 2023

@maheichyk many apologies for the delay you had to endure here so far. We discussed this internally today with @t3chguy, @andybalaam and @clokep. The approach of implementing this via the module API as you did is not unreasonable. However, we think there is an alternative to this that leverages Synapse and, with limited complexity, would allow exposing this feature on all clients while offering a single point of configuration.

The CS-API already includes the authenticated /capabilities endpoint that lists things the server allows your user to do such as m.change_password. The specific UIComponents you mentioned above (InviteUsers, CreateRooms, CreateSpaces) would fit in well there.

What would be needed to implement this is the following:

  • An MSC that describes new server-side capabilities for InviteUsers, CreateRooms and CreateSpaces as well as new error codes for the end points affected by them
  • A change to EW to en-/disable the respective UI elements based on the /capabilities response
  • A change to Synapse to make the APIs affected by the new capabilities (such as /createRoom) value them
  • A change to Synapse's capabilities servlet that allows injecting capabilities (based on the user's ID) using a Synapse plugin

We can help drafting the MSC and review pull requests but would need you to direct your development efforts to the other three points.

Can you please let us know if this option seems viable to you?

@maheichyk
Copy link
Contributor Author

@Johennes thanks for the details, we will discuss this internally and inform you within next few days.

@maheichyk
Copy link
Contributor Author

@Johennes we are using existing deprecated API to customize rendering of components and are not blocked by this PR. In general the idea is good, but we don't plan to work on this topic at the moment.

@Johennes
Copy link
Contributor

Thanks for getting back @maheichyk. Makes sense. I'll close this for now then.

@Johennes Johennes closed this Sep 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants