Refactoring plan

[slomo]

What is this?

In the Scrum of scrums on (18th July 2017) it was decided that we collect a list of bigger refactorings that we want to todo to give them back into the scrum process.

project/module mixin

Most operations in a typical adhocracy4 platform happen inside in the context of a project or a module (which also implies a project). Currently we have some ways to find those contexts

• read module_slug parameter from url (eg. creation of ideas and other items)
• read module property of a project mixin, which in turn reads the project_slug of the url (eg. listing of ideas)
• read project from project_slug slug of the url (eg. project detail view / all views extending project mixin)
• read module or project from self.object if the object is an item

The same issue exists to some extend also for forms, that want to create an item.

What would be a good solution:

• implement an view(-mixin/baseclass) that provides self.project and self.module
  • it should automatically try to get the values from their respective url slugs, or self.object if it has an project or module property
  • it should allow to override the project or module property if needed
  • it should provide those values to the template via get_context
  • it should provide the most specific value to the form via get_form_kwargs (possibly introspecting the form, if it needs that value)
• implement an model form(-mixin/baseclass) that receives the project or module parameter from the view
  • it should set that value as a property of a for
  • it should on save set the project or module property of the saved object (maybe that needs to be configurable)
  • it should target create forms primarily (maybe something similar could be done for update forms, but that should read the value from the instance instead)

makeing item an abstract model

Currently we are using item as an concrete model (with it own table). This type of inheritance is discouraged in many Django guides. In addition we never ~~(or seldom)~~ use that model, so is there really a need for it.

pro

• don't use multi table inheritance

contra

• lose ability to give an unqiue number to each item

[kleingeist]

The project/module may also be derived from the Item itself: f.ex. in detail the detail view:

• read module property of an 'item', which is a foreign key. the 'item' itself is determined via the slug param. an 'item' may be f.ex. an Idea, a Poll or an OfflineEvent

[slomo]

I edited the proposal to include reading of the module property.

[slomo]

Should we split each refactoring into its own issue, and just collect the list of issues here? That would allow to discuss each on it own.