Port accounts app templates to Django template syntax

[brylie]

We want to simplify the CiviWiki project by removing JavaScript SPA code written in Backbone.js and using Django templates instead. We will work through the Backbone templates in the accounts app to convert the template syntax from Backbone to Django. We want to maintain the visual styling. Below is a checklist of the relevant Backbone templates to be ported to complete this task.

Note: Backbone markup can be found between {% verbatim %} and {% endverbatim %} template tags as well as within {% block backbone_template %}.

Task

Port the following templates to Django template syntax and ensure they render correctly via the relevant Django view.

Note: all template baths below start within the accounts/template/accounts/ directory, for brevity.

• port account.html to Django template syntax #1199
• complete the following for settings.html
  • create view for "Save Changes" form submission
  • create view for "delete account" submission
  • use vanilla JS confirm for "delete account" confirmation dialogue
• convert Backbone view models to Django view/model in the following templates
  • feed.html - moved to threads app for follow-up work
  • settings.html
• ensure the following properties exist on the User or Profile model
  • civis
  • followers
  • following
  • categories
  • threads
  • drafts
• convert API views to Django views
  • edit_user
  • delete_user
  • upload_profile_image
  • clear_profile_image
  • request_follow
  • request_unfollow
  • edit_user_categories
• simplify accounts views so there is only one ProfileEdit view
• remove ProfileActivationView
• remove ProfileSetupView
• delete user_setup.html and any related routing logic (such as where we force the user through the setup wizard)
  • for simplicity, let's deprecate the setup wizard in favor of update_settings.html
• optionally, add translate tags for all accounts UI texts

[gorkemarslan]

create new views (ideally class-based views) as needed to power the multiple tabs and forms available in the user account section

@brylie could they clarify this section? Which views should we create?

[brylie]

The key phrase is "as needed", which may include the possibility that no new views are needed. The goal is to build the account templates using Django views/template syntax. The specifics are up to the developer.

Perhaps it would be easier to just build the remaining account templates from scratch without regard to the existing Backbone code?

[brylie]

I'll take a look at this task today and start a PR.

[brylie]

Note: my goal is to remove the accounts Backbone JS while preserving templates and view code. That way, we can re-implement the features as a community, possibly during Hacktoberfest. Also, the Backbone JS is a significant blocker, so this PR will remove the blocking code/complexity.

[gorkemarslan]

@brylie, you don't have to migrate all views. I think you are already aware of that but let me write down my thoughts to recap our strategy once again. 😄 For example, we don't use get_card() view anymore. I forgot to remove this view and the related URL from the project in my MR. Could you remove its implementation? Moreover, I believe we can get rid of all get_<smt>() views in accounts/api.py without any replacement.

There is no useful case to keep get_user() and get_profile(). We should never return the user model. But we can access the user model in all Django templates. The thing is, we can get the user profile from the user model. So no need to use them. If any JS code calls get_user or get_profile we can drop that section.

edit_user, upload_profile_image, clear profile image, edit_user_categories can be combined in one view. These all can be updated by only one POST request. Maybe we can put request_follow and request_unfollow to this new view. It is also possible to create a new dedicated view like FollowStatusView to follow and unfollow a user.

We can remove get_feed. As a side note, its implementation is wrong. It returns all threads, not all threads of a user. So basically it is ThreadListView. Also, it is not related to accounts app. Such an implementation should be in threads app.

ProfileManager is redundant. Its purpose is to prepare JSON data to send to Backbone.js. Same is true for all model managers in the project. (ThreadManager, CiviManager, CiviImageManager) but for the model managers in thread app let me finish #1152. I ported everything to Django template syntax but the difficult part is to keep the design the same. The project is heavily dependent on JS and I don't want to lose the design. What I try to do to keep the design the same as much as possible. I like your idea to separate account.html file into dedicated HTML files. I am gonna follow your idea in my branch.