Rather than modifying database tables, when the entity in question is a DSpaceObject (like EPerson) you might consider whether a metadata field would be a good approach. This would be especially appropriate if (a) multiple values are needed, (b) translations of the value into multiple languages are needed, or (c) the value is optional and rarely set. This approach has its own issues, such as needing to define the field in an appropriate namespace.
In the specific case of EPerson, it seems likely that the field is already available from some other institutional source. If so, you might consider writing a bit of code to refer to that other source, rather than holding duplicate and possibly stale data in DSpace. -- All messages to this mailing list should adhere to the DuraSpace Code of Conduct: https://duraspace.org/about/policies/code-of-conduct/ --- You received this message because you are subscribed to the Google Groups "DSpace Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to dspace-devel+unsubscr...@googlegroups.com. To post to this group, send email to dspace-devel@googlegroups.com. Visit this group at https://groups.google.com/group/dspace-devel. For more options, visit https://groups.google.com/d/optout.
