search

TireSwingSoftware / openassign-server

OpenAssign server intended for use by a separate client via RPC
BSD 3-Clause "New" or "Revised" License
6 stars 2 forks source link

Add organization attribute to Task (and subclasses) #72

Closed jc0n closed 12 years ago

jc0n commented 12 years ago

In summary, from our discussion over email:

From: @mhrivnak

When a task is created, an owning organization must be chosen. From then on, the task may only be modified by admins from that organization. However, any organization may assign that task to users.

We will also want to verify that the task creator only specifies an organization to which he belongs and has sufficient privileges to create the Task.

jc0n commented 12 years ago

What is the best way to handle the exam XML files? I assume we will need to include an attribute for organization_id in the XML file? The only alternative that I can think of is passing in the organization_id when we call create_from_xml or the like.

mhrivnak commented 12 years ago

In general, when importing data via CSV or XML, we try to define foreign relationships based on something human-readable whenever possible. I think it would be fine to specify an "organization" attribute of the exam node which is the name of an org.

It would be a good idea to document that somewhere, although I'm not sure where is best. We definitely want to update the schema definition, and also perhaps the docblock for exam_manager.create_from_xml.

jc0n commented 12 years ago

In general, when importing data via CSV or XML, we try to define foreign relationships based on something human-readable whenever possible. I think it would be fine to specify an "organization" attribute of the exam node which is the name of an org.

Sounds good to me.

jc0n commented 12 years ago

Will this pose a problem for organizations that have a parent? It looks like it may since the name attribute alone is not unique.

mhrivnak commented 12 years ago

Ugh, good question. We already made an assumption in pr_services.import_manager.import_users that an org name is unique. While it seems like a nice idea for more than one organization to have the same name, I don't see it being used in practice any time soon. I think this is a case where we should keep it simple and do a great job of meeting our current use cases, so I suggest removing that "unique_together" constraint and making an org name unique by itself.