-
Notifications
You must be signed in to change notification settings - Fork 9
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 external links to Chapter Profile #37
Conversation
The common fields such as "introduction line" and "content panel" was added into the groups base class and the specific fields were kept in the child class.
@brylie I have made some initial commits in the favour of our discussion. I will be adding more changes in the same way. You can review my changes for any corrections/modifications as required. |
Looks good so far! I only suggested a minor modification. |
Introduction and Details fields were added to the Groups page as all pages inheriting from groups would be requiring these fields.
@brylie I am running into a problem while applying migrations. The following types of errors are being encountered: Error1
Error2
Error3
The error that I am encountering might be referenced in this issue |
Delete your existing |
1. Single introduction field was added of the type RichText field. 2. The "content" field in the home/models.py/ : HomePage was made to be optional due to the default value restriction during migrations. 3. Reformatted the home and chapters models using black.
Hey @brylie I have been brainstorming about our issue and I tried to create some test data for the same. So currently the countries are getting rendered with their regions in separate boxes. But won't you want to list all the countries of the same region together? Like in the following example won't you want |
Yes, we want to group chapters by region. Since grouping data by an attribute is such a common need, Django provides the |
A limitation of {% regroup %} was it's inability to order the groups before grouping and thus had to be grouped explicitly. Also added links to return to the parent pages from the child pages.
The many-to-many relationship was used to add or remove a particular user to the selected chapter. Now a single user can join one or more chapters and a single chapter can contain one or more users as well.
@brylie I have implemented the user membership feature in the chapters. You might want to check it out. Currently I am using query string parameter on the button to achieve this, but there might be a better way to do it. I might even consider using ajax to prevent page refresh. Feel free to give some suggestions for the same! |
For dynamic portions of the page that should update without a refresh, let's use HTMX. We basically need to define a view that returns the HTML fragment for the user membership component. When the user clicks the button, HTMX will make a request to the membership widget view and insert the returned HTML fragment into the template. |
However, we might want to live with the page refresh for this iteration unless AJAX/HTMX seems reasonable to add in the first pass. |
@brylie so should I make this pull request ready for review? Is there any additional change you would like me to implement before I do so? |
Yeah, let's mark this as ready for review. If you agree that the AJAX would be a good enhancement for the group membership button, please open a feature request, so we remember to come back around to that enhancement. |
It was a bad practice for updating the database using a get method, which was the case with chapter membership. The new method implemented uses a POST method, along with form validation to ensure site safety and security and preventing url/sql injection or other hacking techniques.
ChaptersIndexPage was made to inherit from the abstract Page model so that the code becomes easier to maintain. Other types of Groups and their Index Pages would be created easily by just inheriting from Groups and GroupsIndexPage.
The overall direction and code architecture here look great! There are just a few minor considerations that I've mentioned in the review comments. |
Instead of specifying a hardcoded class "Chapter", the subpage class was derived from the object and the child objects were fetched and ordered accordingly. The models were reformatted with black.
It wasn't preferrable to redirect the unauthenticated users to login page and it was best to not render the join group button to non authenticated users.
Great work! This is a significant PR :-) |
Yeah thank you! 😄 |
What?
Backend
Groups
.Chapters
a child model class ofGroups
members
andusers
. Manyusers
can be a part of agroup
and auser
can be involved in multiplegroups
.context
after ordering byregion
andname
. This was essential for the correct display through regroup template tag.Group
.GroupsIndexPage
from whichChaptersIndexPage
inherits.Frontend
Chapters Display on Chapters Index Page