-
Notifications
You must be signed in to change notification settings - Fork 3
/
Copy pathissues.txt
117 lines (74 loc) · 4.27 KB
/
issues.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
Goal for Thursday
-----------------
Prototype is done. Now identify the minimum for building a beta.
* Find a release/iteration naming scheme for beta:
Will be themed by the names of the members of The Inklings, preferably their nicknames: http://en.wikipedia.org/wiki/The_Inklings .
What that's worn out, we'll work through the title of their books, in a randomized order.
Beta tickets
Presentable Site UI - allowing CO ordering, etc., via js.
Content Type generator - including the notion of Content Bundles.
* Dev. Notes
TODO
----
<% unless ["create", "index", "new"].include?(params[:action]) %>
<% puts "this is annoying 3" %>
<% debugger %>
<% puts "this is annoying" %>
<li>
<% puts "this is annoying 4" %>
<%= link_to 'Delete', admin_inkling_foo_path(@foo), :method => :delete, :confirm => "Are you sure? Deletion is permanent." %>
</li>
<% end %>
Inkling stories
1. as a dev I have provided content type recognition
1a. once prototyped, create class methods for models to become content - e.g acts_as_inkling
2. As a dev I have provided CRUD permissioning which is stored by roles on folders.
2a. As a dev I have CRUD for folders
3. As a dev I have provided a user & community/group & role API.
4. As a dev I have provided a clean & popular authentication layer.
5. As a dev I have provided a simple API for workflow, which may be extended, but will initially be draft/publish and role restricted.
6. As a dev I can create a content extension, which groups content types, and have it recognized in the system. (this can wait until you
have basic CMS functionality with inkling-content).
7. As a dev I have CRUD for the site object's informative properties.
7a. As a dev I have multi-site capabilities
7b. As a dev I have worked out how to add parameters to the Application object which can be looked up in routes.rb (to turn multi-site on or off).
8. As a dev I have planned for a themeable layer, possibly the admin UI.
Inkling-Content (currently Inkling page)
1. As a dev I have created a polished page type with ckeditor for WYSIWYG.
Outstanding Issues
------------------
* Engine generator isn't being hooked into initialization process for generating migrations. Check on this.
* validator on folder_entry to ensure that only folders can be nested
* copying static assets - css, images - into the hosting application with a generator.
* testapp/db/seeds.rb needs to be moved into the engine (like migrations)
Security
--------
Roles - guest, member, admin. (roles can be made)
Each Folder has CRUD assignments to roles - so R for guest, member, admin, is accessible content for everyone. If it's D
for admins, only admins can delete what is in that folder. These rules define all access across the application, at the
front and the back cms admin area (e.g. if a content editor role is invented, and a content editor wants to edit a page
in the CMS admin, only pages in folders with RU will be presented in the controller).
Workflow
--------
In the first draft, forget it. Just hack a visible, invisible boolean, which you'll drop as soon as you have security working
(when you can turn to workflow).
Workflows will be content specific, i.e.
Plan is to have a proper workflow.
workflows [:name, :id] -> workflow_states [:name, :position(list)] -> workflow_roles [:role_id, :position (list)]
workflow_assignments [:workflow_id, :content_id]
Each workflow_state, in order, must be progressed, in order, by each workflow_role. Workflows are applied to folders.
Site
----
Multi-site functionality will wrap everything.
A site:
sites[:name, :path, :description, :user_id],
site_users [:site_id, :user_id], site_groups[:site_id, group_id], site_roles[:site_id, role_id]
Roles, users, and groups will be universal, but will be configured to have site access. So you can reuse them across sites.
Theming
-------
Theming is three things, (1) the location of layouts and views and (2) the information architecture of content blocks, (3)
CSS.
(1) - look into load paths for views. Mephisto did this. Rails 3 will make it easier.
(2) - prototype via scaffold or a rough view for the moment. When you have admin functionality mapped, clean up
with neat grouping of menus/partial rendering, etc., document, and it should be themable, in theory.
(3) - Simply use clear classes, etc.?