Re: [Bodington-developers] alias_entries - Suggested change to constraints.

[Jon M. <jo...@te...>]

Matthew Buckett wrote:
> Could you superclass  Alias and AliasEntry to MultiAlias and 
> MultiAliasEntry. These classes don't enforce the restriction of only 
> allowing one alias per user. This way any code that deals with aliases 
> will never get more than one entry per user and programmer won't have 
> to change how they thing about aliases but functionality in certian 
> places can be alter to work with MultAlias(Entry)
An ingenious idea!

It might also help address Peter's comment.
This way there is a mechanism that enforces a distinction between the 
two types of alias. Functionality that takes an alias value and finds a 
user can ignore the distinction but functionality that takes a user and 
looks up an alias entry to label him/her can present a list of optional 
alias types that excludes the MultiAlias objects, but depending on its 
purpose it can choose to return and display the list of alias entries 
per user.  So, taking the MCQ test as an example it could be made 
possible to ask for 'student_id' to be printed in the table but disallow 
'old_student_ids' because the former would be an AliasEntry and the 
latter a MultiAliasEntry. On the other hand the user directory tool 
could happily allow a member of staff to find a student by typing in an 
'old_student_ids' value.

The main purpose of the MultiAlias would be for administrative data and 
wouldn't necessarily contain aliases of interest to staff and student.

The other advantage of subclassing is that we can implement it at Leeds 
with Bodington 2.6 as an add-in without changing the existing code or 
the definitions of the existing database tables.

Give that man a pay rise!

Jon