-
-
Couldn't load subscription status.
- Fork 769
First code submission for MVC Pipeline #6749
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
base: feature/mvc-pipeline
Are you sure you want to change the base?
Conversation
…tomizations for the MVC pipeline.
Fix layout issue
client dependecy for mvc (because it not exist in nuget)
There was a problem hiding this 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!
| 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"); | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
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.
| 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.
There was a problem hiding this comment.
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() |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
| 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; | ||
| } | ||
| } |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
| public UserInfo UserInfo | ||
| { | ||
| get | ||
| { | ||
| return this.PortalSettings.UserInfo; | ||
| } | ||
| } | ||
|
|
||
| public int UserId | ||
| { | ||
| get | ||
| { | ||
| return this.PortalSettings.UserId; | ||
| } | ||
| } | ||
|
|
||
| public PortalAliasInfo PortalAlias | ||
| { | ||
| get | ||
| { | ||
| return this.PortalSettings.PortalAlias; | ||
| } | ||
| } |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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 ?
There was a problem hiding this comment.
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:
| services.TryAddScoped(controller); |
| services.TryAddTransient(controller); |
Scoped it probably the right way
There an separate PR for CSP on the develop branch. But removing it from this PR needs to remove a lot of code. Actually we heave a lot of sync issues between the differnt PR's. |
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
So if that is the case, we need to review/agree on the CSP one first before spending too much time reviewing this one... |
This reverts commit e07308a.
…auwaen/Dnn.Platform into feature/mvc-pipeline-old # Conflicts: # mvc-pipeline.md
…auwaen/Dnn.Platform into feature/mvc-pipeline-old
… and is actually not working
Remove module settings, because actually out of scope
|
To simplify the review
|
|
My suggestion is
|
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.