-
Notifications
You must be signed in to change notification settings - Fork 22
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
Ticket #2520: Admin portfolio view #2581
Conversation
Remove the content for members
🥳 Successfully deployed to developer sandbox za. |
🥳 Successfully deployed to developer sandbox za. |
</br> | ||
{% endif %} | ||
</br> | ||
|
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 was a bug with our existing detail list
{% block after_related_objects %} | ||
<div class="module aligned padding-3"> |
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.
@CocoByte I had to remove this to match the mockup, sadly! Was this section of code going to be used elsewhere as well? I don't want to throw all of this away unless I have to
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.
I think this is copied over from user_change_form. I don't like that we're doing the same thing in 2 different ways now, should probably bring this up to Alysia and design.
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.
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.
I don't like that we're doing the same thing in 2 different ways now
@rachidatecs Can you elaborate more on what you mean here? Just want to make sure I am interpreting you correctly
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 desire for elaboration. But I will say our goals with portfolio is very different than the goal for having domains/requests show on a User.
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 that deleted markup to display related info on user, we're currently using a collapsible fieldset on portfolio (which I understand will change again) - that's it.
{% block field_sets %} | ||
{% for fieldset in adminform %} |
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.
Left a placeholder here as the direct follow-on ticket is going to use this view. It doesn't make sense to remove then add this again
🥳 Successfully deployed to developer sandbox za. |
🥳 Successfully deployed to developer sandbox za. |
src/registrar/models/user.py
Outdated
related_name="user", | ||
related_name="portfolio_users", |
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.
Needed for the upcoming additions of portfolio members
🥳 Successfully deployed to developer sandbox za. |
🥳 Successfully deployed to developer sandbox za. |
🥳 Successfully deployed to developer sandbox za. |
@zandercymatics no one should change the federal branch by changing it on a portfolio, that changes it for every portfolio in that agency. I wouldn't even want superusers to do that while on this page. They should go to the federal agency page, OR change the federal agency |
@zandercymatics we don't need all this info under creator: The creator will always be a CISA/Fed employee or our System. All that other info should be empty for most cases |
Nevermind on the above, I just found an old note that we want to change this view to be a link to a filtered view of the domains table and the domain request table respectively. Ignore that for this ticket and don't worry about making any more changes for the domains/domain requests sections. |
🥳 Successfully deployed to developer sandbox za. |
🥳 Successfully deployed to developer sandbox za. |
🥳 Successfully deployed to developer sandbox za. |
1 similar comment
🥳 Successfully deployed to developer sandbox za. |
🥳 Successfully deployed to developer sandbox za. |
@rachidatecs / @abroddrick Got those changes in |
🥳 Successfully deployed to developer sandbox za. |
@@ -159,3 +159,13 @@ def and_filter(value, arg): | |||
Usage: {{ value|and:arg }} | |||
""" | |||
return bool(value and arg) | |||
|
|||
|
|||
@register.filter(name="has_contact_info") |
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.
Why filter?
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 comment by Alysia
Addressed! |
|
||
created_on.short_description = "Created on" # type: ignore | ||
|
||
def portfolio_type(self, obj: models.Portfolio): |
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.
Blocking question: I don't understand the difference / inter-relationships between portfolio type, organization type, federal type, federal agency
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.
I do think we need to clamp down on these concepts at some point. I've listed descriptions of each. This may be information you already know, though, but hopefully it helps to have it written out like this? Lmk if you wanted something different.
Basically, portfolio_type and federal_type are needed to fulfill the AC and design of this
portfolio_type
- Combination of Portfolio.organization_type (Federal, city) and Portfolio.federal_agency.federal_type (Executive, legislative)
- The FederalAgency table now contains all definitions for all federal_agency values
- Note: The AC specifically prohibits making
portfolio_type a DB field and notes that this should be a property. Personally, I think just representing it at the admin.py level though would make sense but that depends on @abroddrick
organization type
- This is the same as generic_org_type. Basically, it can be Federal, City, Tribal, etc
federal_type
- This is self.federal_agency.federal_type (executive, legislative)
- Only describes org types of Federal, basically.
- Note: As mentioned by Alysia, this should only be changeable from the FederalAgency table. Do you think this should be a db field anyway (w/ custom save logic)? Right now its just a property
federal_agency
- This is the FederalAgency model. See screenshots
@@ -847,3 +847,8 @@ div.dja__model-description{ | |||
} | |||
} | |||
} | |||
|
|||
ul.add-list-reset { |
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.
May not be needed, look at add-list-reset: https://designsystem.digital.gov/utilities/list-reset/
Ticket
Resolves #2520
Changes
Context for reviewers
This PR excludes the domain members and domain groups sections, as that will be implemented later. I've included functions that can be used to easily include those.
One difference from the view and this is that the federal type (executive, etc) is readonly for analysts only, but not for superusers as you can't actually add data to that field otherwise. This can be changed to be readonly for everyone, though. cc: @abroddrick - is this OK?
Setup
Code Review Verification Steps
As the original developer, I have
Satisfied acceptance criteria and met development standards
Ensured code standards are met (Original Developer)
Validated user-facing changes (if applicable)
As a code reviewer, I have
Reviewed, tested, and left feedback about the changes
Ensured code standards are met (Code reviewer)
Validated user-facing changes as a developer
New pages have been added to .pa11yci file so that they will be tested with our automated accessibility testing
Checked keyboard navigability
Meets all designs and user flows provided by design/product
Tested general usability, landmarks, page header structure, and links with a screen reader (such as Voiceover or ANDI)
Tested with multiple browsers, the suggestion is to use ones that the developer didn't (check off which ones were used)
(Rarely needed) Tested as both an analyst and applicant user
Note: Multiple code reviewers can share the checklists above, a second reviewers should not make a duplicate checklist
As a designer reviewer, I have
Verified that the changes match the design intention
Validated user-facing changes as a designer
Checked keyboard navigability
Tested general usability, landmarks, page header structure, and links with a screen reader (such as Voiceover or ANDI)
Tested with multiple browsers (check off which ones were used)
(Rarely needed) Tested as both an analyst and applicant user
Screenshots