search

imperialcollegeunion / website

The new Imperial College Union website
GNU General Public License v2.0
3 stars 0 forks source link

Club Node #4

Closed jkimbo closed 12 years ago

jkimbo commented 12 years ago
lsproc commented 12 years ago

The debate I have in my head right now is whether to do it as a node or not. To explain what I mean, I'll use this example:

Übercart allows you to create nodes for products, these are content types that can be managed as you require (add, edit, delete etc.) It also provides a fixed page at /cart which is the shopping cart.

I'm wondering whether to have Club nodes, where you enter the club number as content, and it pulls from eactivities on load, or we just have a /club/xxx page, behaving like the cart one, where xxx refers to the club number.

Advantages of node: Acl support URL customisation is easier(?) Delete pages for clubs not to have pages (I.e. do we want one for RWB?)

Disadvantages: Have to manually create and delete pages It might conflict with a built in content template in the admin cp (I.e. description may be required which we won't want)

Advantages of Cart style: Everything is automated (creation and deletion) No need to administer pages, if union staff want to edit a club page, only need eactivities and not 2 tools

Disadvantages: No ACL Every club gets a page even if we don't want one (we may be able to avoid this in a configuration option) URL customisation would need to be done using a drupal module (which is installed) and getting eactivities/something to write thr data on creation of a new club. Note this module is needed to do any nice urls, it's just in the node way you get to edit it while editing the page.

jkimbo commented 12 years ago

The cart style with the automated generation and management through eActivities seems the best choice to me since it simplifies things a lot in terms of management. The lack of ACL is a shame though I guess that would be handled by eActivities anyway?

I think @ajpmckee and @pangeaenterprises will have the best idea of what is needed for this.

lsproc commented 12 years ago

I cannot see there being a need for the acl on these pages, reason being all the admin is done on eactivities, and hence the write access will already be restricted by the roles that eactivities has. Any admin UI this has will be limited if any, hence I do not see a need for ACLs

lsproc commented 12 years ago

Stuff left to do:

Future stuff to do