Design a extentable structure to package's infos that must be shown in the main table
From the Hertzog's suggestions:
I would suggest to have some modularity in terms of fields that are included in this table. You have the basic fields that are always available and then you have fields that are associated to other applications (think vendor/debian, etc.)
Those field object should be the main interface. They have the logic to build the content of the cell out of the data that they are associated with.
The fields should probably export some sort of index to define their position (from left to right).
Some fields might have different views (condensed/detailed/errors-only/whatever makes sense for the specific field).
- Identify the basic package's fields based on the data provided by the core functionalities
- Define a generic structure that vendors can extend to add more package's fields.
Create a PackagesTableBase class
- Add title
- Filter method to filter which packages must be displayed
- Show content
- Must have a list of PackagesTableFieldBase
- Must have a maximum number of fields to be displayed
- Should we have a generic template for each PackagesTable or a generic one is enough?
Create a PackagesTableFieldBase class
- Column name
- Specific template (with popup?)
- Implement the logic of core fields to build the content of the cell
Extend the basic structure to add specific fields from Debian
Propose an efficient way to lookup packages' related objects to avoid N+1 problems using
BaseTableField.prefetch_related_lookups- used to define prefetch_related params
BasePackageTable#packages_with_prefetch_related- reference method that apply prefetch_related to
- Do not use get_web_package and define a better way to get short_description
- Remove duplication from GeneralInformationTableField and GeneralPanel
- Unit test
- Change Team's Home page
- Create Team Management page using the current team page content
- Include minified and non-minified version of JS
- Add tests to Utils' method