Skip to content

Conversation

@donker
Copy link
Contributor

@donker donker commented Oct 3, 2025

This PR is a first submission of the work of the MVC Pipeline team to bring the main project up to date with what has been developed in a forked repo.

donker and others added 30 commits March 20, 2025 11:36
client dependecy for mvc (because it not exist in nuget)
@donker
Copy link
Contributor Author

donker commented Oct 14, 2025

@bdukes @donker I believe we discussed that this is just a reset PR and initial review, as it is into their branch correct? High level review only?

Yes. This is what we discussed in an earlier meeting to have the first code submission a proper PR.

Copy link
Contributor

@valadas valadas left a comment

Choose a reason for hiding this comment

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

Ok, I found a bit of time and reviewed about the first 1/4 of this PR.

I think we should bring this PR to the minimal viable MVC working state (even if incomplete) just with the minimum to load up an mvc theme and module.

MVC Pipeline and CSP are 2 big ticket items and bringing both in the same PR makes putthing this in a reviewable state hard IMO. The goal of this PR was to have a baseline so that we can review smaller additions in an easier way.

Other than that, it does not have to be in this PR but I would like that we add our stylecop rules to the new projects to enforce our coding standards on this huge amount of new code.

I'll try to review some more the next coming days.

Thanks @sachatrauwaen for this huge contribution!

Comment on lines 212 to 222
private void CheckPermissions()
{
// Verify that the current user has access to edit this module
if (!ModulePermissionController.HasModuleAccess(SecurityAccessLevel.Edit, "MANAGE", this.Module))
{
if (!(this.IsSharedViewOnly() && TabPermissionController.CanAddContentToPage()))
{
throw new UnauthorizedAccessException("Access denied");
}
}
}
Copy link
Contributor

Choose a reason for hiding this comment

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

This one hurts my brain a bit specially since it relates to permissions and should be very clear and intuitive.

Suggested change
private void CheckPermissions()
{
// Verify that the current user has access to edit this module
if (!ModulePermissionController.HasModuleAccess(SecurityAccessLevel.Edit, "MANAGE", this.Module))
{
if (!(this.IsSharedViewOnly() && TabPermissionController.CanAddContentToPage()))
{
throw new UnauthorizedAccessException("Access denied");
}
}
}
private void CheckPermissions()
{
// Verify that the current user has access to edit this module
if (ModulePermissionController.HasModuleAccess(SecurityAccessLevel.Edit, "MANAGE", this.Module))
{
return;
}
if (this.IsSharedViewOnly() && TabPermissionController.CanAddContentToPage())
{
return;
}
throw new UnauthorizedAccessException("Access denied");
}

Which then begs the question, should we allow the module settings control to be viewed for a shared module to content editors? It looks wrong to me unless I am missing something.

Copy link
Contributor

Choose a reason for hiding this comment

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

to simplify, module settings stuff is removed from the pr, because actually out of scope of mvc pipeline

}
}

private void CheckPermissions()
Copy link
Contributor

Choose a reason for hiding this comment

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

Same concern here as my previous comment on the similar code in ModuleSettingsController.cs

Also what is the difference between ModuleSettingscontroller and MOduleSettingsViewController.cs?

Copy link
Contributor

Choose a reason for hiding this comment

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

to simplify, module settings stuff is removed from the pr, because actually out of scope of mvc pipeline

Comment on lines +63 to +93
public bool EditMode
{
get
{
return this.ModuleContext.EditMode;
}
}

public bool IsEditable
{
get
{
return this.ModuleContext.IsEditable;
}
}

public int PortalId
{
get
{
return this.ModuleContext.PortalId;
}
}

public int TabId
{
get
{
return this.ModuleContext.TabId;
}
}
Copy link
Contributor

Choose a reason for hiding this comment

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

If we expose ModuleContext, do we need to also expose those properties, could we make the API surface simper by limiting the redundant properties?

Copy link
Contributor

Choose a reason for hiding this comment

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

It was inspirid from PortalModuleBase. But, yes i can make the API surface simper.
I can for exemple, inspire from DnnController from mvc modules witch expose : ModuleContext, PortalSettings, ActiveModule, ActivePage and User

Comment on lines +95 to +117
public UserInfo UserInfo
{
get
{
return this.PortalSettings.UserInfo;
}
}

public int UserId
{
get
{
return this.PortalSettings.UserId;
}
}

public PortalAliasInfo PortalAlias
{
get
{
return this.PortalSettings.PortalAlias;
}
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Same for PortalSetings which is already exposed, do we need those properties also exposed?

Copy link
Contributor

Choose a reason for hiding this comment

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

It was inspirid from PortalModuleBase. But, yes i can make the API surface simper.
I can for exemple, inspire from DnnController from mvc modules witch expose : ModuleContext, PortalSettings, ActiveModule, ActivePage and User

type is { IsClass: true, IsAbstract: false });
foreach (var controller in mvcControllerTypes)
{
services.TryAddTransient(controller);
Copy link
Contributor

Choose a reason for hiding this comment

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

Should this be scoped @bdukes ?

Copy link
Contributor

Choose a reason for hiding this comment

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

We're using scoped for web API controllers, but transient for MVC controllers:


Scoped it probably the right way

@sachatrauwaen
Copy link
Contributor

MVC Pipeline and CSP are 2 big ticket items and bringing both in the same PR makes putthing this in a reviewable state hard IMO. The goal of this PR was to have a baseline so that we can review smaller additions in an easier way.

There an separate PR for CSP on the develop branch.

But removing it from this PR needs to remove a lot of code.
The idee is to replace the CSP project of this PR with the PR on develop when the PR is merged in develop.

Actually we heave a lot of sync issues between the differnt PR's.
I don'tknow the best way. So your advice is welcome.

@valadas
Copy link
Contributor

valadas commented Oct 15, 2025

MVC Pipeline and CSP are 2 big ticket items and bringing both in the same PR makes putthing this in a reviewable state hard IMO. The goal of this PR was to have a baseline so that we can review smaller additions in an easier way.

There an separate PR for CSP on the develop branch.

But removing it from this PR needs to remove a lot of code. The idee is to replace the CSP project of this PR with the PR on develop when the PR is merged in develop.

Actually we heave a lot of sync issues between the differnt PR's. I don'tknow the best way. So your advice is welcome.

So if that is the case, we need to review/agree on the CSP one first before spending too much time reviewing this one...

1 similar comment
@valadas
Copy link
Contributor

valadas commented Oct 15, 2025

MVC Pipeline and CSP are 2 big ticket items and bringing both in the same PR makes putthing this in a reviewable state hard IMO. The goal of this PR was to have a baseline so that we can review smaller additions in an easier way.

There an separate PR for CSP on the develop branch.

But removing it from this PR needs to remove a lot of code. The idee is to replace the CSP project of this PR with the PR on develop when the PR is merged in develop.

Actually we heave a lot of sync issues between the differnt PR's. I don'tknow the best way. So your advice is welcome.

So if that is the case, we need to review/agree on the CSP one first before spending too much time reviewing this one...

@sachatrauwaen
Copy link
Contributor

sachatrauwaen commented Oct 22, 2025

To simplify the review

  1. CSP is removed from this branch (i have just leaved some comments for later integration)
  2. remove module settings stuff, because actually out of scope of mvc pipeline

@sachatrauwaen
Copy link
Contributor

sachatrauwaen commented Oct 22, 2025

My suggestion is

before reviewing "First code submission for MVC Pipeline", merge this PRs without review
PRs are inter dependend and replace a lot of code and are on this branch
So after you will review the whole with a cleaner and more definitive view

  • MVC pipeline - Module control — Type: Feature #6700
  • MVC pipeline popups #6723
  • MVC pipeline (routing / settings) #6721
  • MVC pipeline - module actions #6725

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: No status

Development

Successfully merging this pull request may close these issues.

6 participants