-
-
Notifications
You must be signed in to change notification settings - Fork 529
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
[3.x] Refine grids code to correct actions access and visibility (revised) #15919
base: 3.x
Are you sure you want to change the base?
Conversation
@mishantrop - First of all I'd like to express that I appreciate you taking the time to review this PR. It would, however, be much more useful for you to review the functionality and the usability of what is being implemented rather than getting into the weeds with super fine-grained code suggestions and what are, in some instances, personal coding/code-style preferences. Does the PR solve the problem it's trying to solve? Does it do it in a way that improves the UI? Does it bring a useful new feature? I'm certainly not looking to ignore your suggestions, and if I and others feel some of them would provide an improvement I'll make the change(s). I'm just saying I think your initial focus is in the wrong place. |
@smg6511 - First of all I'd like to express that I appreciate you taking the time to write new features..
|
@smg6511 You're on fire! There's a lot to cover in this PR. Please take a look at the technical implementation of PR #14009. Some similar changes have been made relevant to some of yours. I'll do my best and find some time in the upcoming days to provide feedback on the functionality and usability of the fixes and new features in this PR. |
@JoshuaLuckers - I appreciate the encouragement! Yes, this initial PR is a bit to review, I know ;-) But, once finalized, it will provide an pretty easy framework to update the rest of the grids. I'll take a look at 14009 in just a bit... OK, I just took a quick look through 14009 and I don't see any conflicts with what I've done. Even so, assuming that my PR in some form gets merged and I move on to other grids (in 14009's case the policy/policy template grids), I'll refer back to 14009 to ensure I don't walk back anything important. |
@mishantrop - Don't worry, I'm not taking anything personally. And I, of course, agree that code quality, consistency, and conformity to a standard is also very important. (I also know from comments on other issues/PRs that you and I might not share the same viewpoint on some stylistic and implementation conventions, but that's Ok.) I was just pointing out that I don't think that's the first thing to focus on when you're reviewing a PR. |
@JoshuaLuckers - Don't know if you withdrew the comments you were making re #14009. (I was about to respond and they disappeared.) Anyway, I see I'll want to carry through how the core items are defined in constants in each object's base class, as they were done in the modAccessPolicy one. However, I do think my implementation of the final relay of those permissions via prepareRow of each object class is more straightforward and immediately readable. So when you're reading the record in js, your getting, for example:
instead of:
The way I've done it is also very easy to iterate through without any additional fuss. Note also, I think it makes sense is to use CRUD nomenclature across the back end (in code), which is why I've changed for example edit to update and remove to delete. On the front end, it makes more sense (in my mind at least) to use natural language (e.g., Edit X instead of Update X). Could be over-thinking it though ;-) |
Yes I have deleted my comment. I have a lot to share but I still need to find time to properly work it out haha. But your in the right direction with where I want to go, but you're right about the class names like pedit. If your on Slack I could share my unstructured notes. |
Yes, I am on Slack for another project I work on. How shall we connect? |
Fix merge issue from last rebase
Conflict resolution
e301a69
to
3b78298
Compare
Change back to public class props
Various functionality-related changes to grid base js class and utilities lib
Various additions and optimizations, as well as code quality improvements
Various additions and optimizations, as well as code quality improvements
Small tweaks and carry through of methods used in other core object classes to identify protected data keys
@smg6511 can you please ping me once finishing with updates? |
@theboxer Will do. The question now is: In addition to doing any last tweaks/optimizations to what is here now, shall I carry this through the rest of the grids as a part of this PR, or leave that to a supplementary PR? (I don't believe the changes made thus far would negatively affect grids that have not been updated to use the new methods.) |
@smg6511 how many affected grid you think there are, that will need an update? |
@theboxer Ultimately all editor grids need an update of some sort to ensure the gear icon/menu only shows when applicable. I'll survey which grids still need work—two that come to mind that I'm working on now are the Policy and Policy Templates grids. |
@smg6511 I guess it'd be fine to have them all here, but I'm not sure how much of an effort it is, so it'll all get into 3.1. |
@theboxer @opengeek - Guys, there's something I hadn't noticed initially about the additional "Creator" column I've added as a feature of this PR: Because the creator data point is not a part of the db data, I'm finding it difficult (probably impossible) to provide an expected secondary sort (on the name column) when sorting the "Creator" column. So, when sorting on "Creator," the name column is just randomly sorted (which I don't think is great). (I had a little hack going to build the Creator column on the fly, based on extra data generated from various GetList Processors.) Anyway, upon finding the secondary sorting issue, I tried to pull another rabbit out of the hat, but I think this ultimately points to the need for one or two more columns in many of the db tables to achieve the desired grouping (and even better, filtering) of objects based on how they were created (i.e., by modx, by an Extra, or by a User). This is probably not a job for this PR. So, I'm thinking of removing that aspect for now. But I would like to get a read on whether you'd go for making some schema changes to add a general [1] Other columns?
|
Why wouldn't you just sort on the joined table columns for creator? |
As it stands, creator doesn't exist in the db; it's derived from other "knowns" that are gathered on the php side of things (e.g., for Contexts, I know which are installed by modx via the hard-coded constants assessed by the |
Isn't creator just the name fields from user profile? I'm confused. It should absolutely be a simple join to that table from the createdby field. |
I'm guessing you're thinking more in the context of Resources, where the so-called creator (createdby) is persisted in the data itself. I believe Resources are the only place that happens. But what I'm working with here doesn't apply to Resources—which are of course always created by a specific User. The "creator" I've added is a more holistic identification (modx, extra, user [in general, not specific id]). In any case, none of the other MODX objects save an identifier in the db as to who or what process created it. |
@smg6511 How about you just disable the sort on the |
Yeah, I'll go ahead and do that and remove the sorting-related php. Will ping you when ready... |
Clean up and remove creator sorting
Clean up and remove creator sorting
Clean up and remove creator sorting
Clean up and remove creator sorting
Small code formatting update
Small css update for text links
@smg6511 is this ready for re-review? |
@theboxer - Not quite yet, but almost. I had found some details that needed tending to in order to make this change complete in the areas where it's applied so far. Work on those is just about done. In working with the more complicated Policies and Policy Templates areas, I've found there's a bit more to do that might justify a second PR (or a bit more time on this one if we choose to wait and submit everything together). |
Formatting, style, optimization updates. No substantive changes.
Formatting, code style, optimization, modernization only. No substantive changes.
NOTE: This is a simplified re-submission of a PR submitted on 11/23.
What does it do?
This changes in this PR initially set out to fix issues raised in #14929, which uncovered other problems in the grids UI. There are quite a few loose ends there in terms of reflecting what a user can do according to their group permissions and object-level access policies (when applied [to contexts, media sources, etc.]). Additionally there's a lack of full validation within some grids, including their create forms. Also, as @Ruslan-Aleev points out in #15281, validation response is inconsistent because the proper specification is missing on the js side of things. I've arrived at the solution you'll see by creating a number of methods and properties in the main grid class (modx.grid.js), as well as an updated way to identify/apply permissions in the child grid classes and their respective GetList processors.
Fixes
blankText
config to required fields)Proposed Enhancements Included
$colorSplash
)How to Test
Note that while I have applied some of my changes to a couple other grids, their implementation may be incomplete. The three grids to test for this draft are:
Process
grunt build
to ensure css is updated.As those of you who actually coded these areas of MODX or are very familiar with their inner workings, this is a necessarily highly tedious process. I'd envision doing this across multiple PRs so small logical batches could be tested and put into place over time (in as short a time as possible).
Screenshots Highlighting Changes Made
Using the Sources grid as an example (since it highlights all of the fixes/proposed features implemented), below are a few annotated visuals to get a quick idea of what to expect.