Proposals/Done/Views: Difference between revisions
From Mahara Wiki
< Proposals | Done
No edit summary |
m (Anitsirk moved page Developer Area/Specifications in Development/Done/Views to Proposals/Done/Views: Shorter navigation, not always technical) |
||
| (6 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
<div style="border:2px solid #ba9c53; text-align:left; padding:10px; border-radius:5px"> | |||
<i class="fa fa-arrow-circle-o-right fa-lg"></i> '''Please see https://blueprints.launchpad.net/mahara for proposed features and those that are being worked on.''' | |||
</div> | |||
[http://mahara.org/interaction/forum/topic.php?id=2157 Discuss this topic ] | [http://mahara.org/interaction/forum/topic.php?id=2157 Discuss this topic ] | ||
| Line 35: | Line 40: | ||
** View – Add Tutor Access | ** View – Add Tutor Access | ||
[[Image: | [[Image:access_control.png|access_control.png]] | ||
</div></div></div><div class="t-title"><div id="section_4"> | </div></div></div><div class="t-title"><div id="section_4"> | ||
===3.4 Extended Inline Editing to include Profile and Resume fields or… Form Builder?=== | ===3.4 Extended Inline Editing to include Profile and Resume fields or… Form Builder? (Not yet done)=== | ||
</div></div> | </div></div> | ||
| Line 48: | Line 53: | ||
e.g. Profile Icons, Goals, Skills, Professional Memberships, – all just another block type<br /> e.g. Education History block or add title to text block afterall<br /><br /> Impact is that Resume then just becomes another scaffold/template<br /> Create new , Update for all Views <br /><br /> The problem I see with the form builder approach is that it introduces a different mechanism from the core View building approach. We should aim for consistency in content management. | e.g. Profile Icons, Goals, Skills, Professional Memberships, – all just another block type<br /> e.g. Education History block or add title to text block afterall<br /><br /> Impact is that Resume then just becomes another scaffold/template<br /> Create new , Update for all Views <br /><br /> The problem I see with the form builder approach is that it introduces a different mechanism from the core View building approach. We should aim for consistency in content management. | ||
[[Image: | [[Image:inline_editting.png|inline_editting.png]] | ||
<div class="t-title"><div id="section_5"> | <div class="t-title"><div id="section_5"> | ||
====3.4.1 Default folders to support Inline editing==== | ====3.4.1 Default folders to support Inline editing ==== | ||
Not done, and not moved to still be done because missing folders will be re-created. | |||
</div></div> | </div></div> | ||
| Line 64: | Line 71: | ||
Profile, Resume Folder | Profile, Resume Folder | ||
<br />[[Image: | <br />[[Image:folder_inline.png|folder_inline.png]] | ||
<div class="t-title"><div id="section_6"> | <div class="t-title"><div id="section_6"> | ||
===3.5 View Templates=== | ===3.5 View Templates (party implemented)=== | ||
</div></div> | </div></div> | ||
| Line 85: | Line 92: | ||
</div></div><div id="page-top"><div id="pageText" class="pageText"> | </div></div><div id="page-top"><div id="pageText" class="pageText"> | ||
[[Image: | [[Image:social_history.png|social_history.png]] | ||
</div><div id="pageText" class="pageText"><div class="t-title"><div id="section_8"> | </div><div id="pageText" class="pageText"><div class="t-title"><div id="section_8"> | ||
| Line 93: | Line 100: | ||
</div></div><div id="pageText" class="pageText"> </div> | </div></div><div id="pageText" class="pageText"> </div> | ||
[[Image: | [[Image:my_views.png|my_views.png]] | ||
</div></div> | </div></div> | ||
Latest revision as of 17:43, 11 July 2020
Please see https://blueprints.launchpad.net/mahara for proposed features and those that are being worked on.
3.1 Multi-page Views
Functionality underway in version 1.3
3.2 Print
- Improve the Print function to strip ancillary content and keep the View layout.
- Download as PDF (this can be done with sites such as LinkedIn – how achievable?)
3.3 Improvements to Access Control
- Editing access rights for multiple views (also when they are not under one heading) more easily. Development underway in Version 1.3
- Use the Friends List function to create Access Lists, Friends List 2? Access Lists in effect, name Friends List?
- Tutors/Teachers (business rule – staff from institution and/or groups I belong to). Selector like Moodle?
- Groups (business rule – only groups that I belong to) Selector like Moodle?
- What about a Moodle-like boxes:
- View – Add Group Access
- View – Add Tutor Access
3.4 Extended Inline Editing to include Profile and Resume fields or… Form Builder? (Not yet done)
- Resume could simply be a View Template
- Inline editing to include Profile fields and Resume fields profile fields
e.g. Profile Icons, Goals, Skills, Professional Memberships, – all just another block type
e.g. Education History block or add title to text block afterall
Impact is that Resume then just becomes another scaffold/template
Create new , Update for all Views
The problem I see with the form builder approach is that it introduces a different mechanism from the core View building approach. We should aim for consistency in content management.
3.4.1 Default folders to support Inline editing
Not done, and not moved to still be done because missing folders will be re-created.
Default folders cannot be deleted.
Content within default folders can be deleted.
e.g.
Profile, Resume Folder
3.5 View Templates (party implemented)
- Extension of View Types with ability to add View Type e.g. Resume is a Template – has the scaffolding but not the content.
- Well designed themes/ borders to select from.
- Template scaffolding should support different files as empty shells
- Save as Template – Admin function only. Would mean that scaffolding is saved with headings and content type but no content.
Options: Could be located as a selector in the My View List or in the Create View dashboard:
3.5.1 Option 1 templates accessed via My Views
3.5.2 Option 2 Templates as part of the Edit View interface
