-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change entity names #185
Comments
Note that @frankduncan and I have taken to calling this issue "The Full #185", because doing it right means redoing the DB schema and some underlying relationships in order to make the system much easier to maintain thereafter. That's why Jim gave it the "XL" label. Specifically, we need to reflect the Red Cross organizational structure...
...and then implement the idea of a Right now, counties in DCSOps don't map to actual counties. They're arbitrary creations whose relationships with actual counties are tenuous at best. They map how a request gets to a person. |
More clarity as part of this:
Also, another rename came up as useful
|
As of right now, a ResponseTerritory (in new nomenclature) is assigned to an incident based on city, zip, or county. There was a thought that this assignment could be done in real time, but that would require a more substantial effort due to building a query that matches against all the correct combinations of places an incident can belong in, or in building out extra tables to represent these different concepts. So usual cache invalidate rules apply. |
Any difference if we do Shift_Territories, Response_Territories and Shift_Times? |
@OhMcGoo That's just rails naming convention for the classes. ShiftTerritory will get turned into shift_territories in the database, and then we can control the UI to add spaces or underscores to urls and pages as appropriate |
Coolio. |
Work is currently going on on 185-rename-tables branch. |
I'm so sorry you didn't call the branch |
This is a massive change in terms of scope, but not in terms of actual changes, as rename was straightforward. It does require a few DB data updates as detailed in the included migration. Issue #185: Change entity names
This is another wide ranging change that shouldn't affect anything, as it's just a straightforward rename. Issue #185: Change entity names
Wide ranging but straightforward text change. Issue #185: Change entity names
This change is a bit more wide ranging than the other renames, because counties sometimes mean actual physical counties, and other times mean a shift territory that can be a city, zip, county, or collection of counties. For that reason, many of the times, county was changed to shift_territory, but there are many cases where a county_name became a county since there was no more confusion. Issue #185: Change entity names
This does not affect other roles such as homepage link roles, and notification roles, but only the roles attached to positions. These weren't actually roles, so the name brings them more in line with their actual purpose (capabilities), and reduces confusion. This is another wide, but not deep, change. Issue #185: Change entity names
This is a massive change in terms of scope, but not in terms of actual changes, as rename was straightforward. It does require a few DB data updates as detailed in the included migration. Issue #185: Change entity names
This is another wide ranging change that shouldn't affect anything, as it's just a straightforward rename. Issue #185: Change entity names
Wide ranging but straightforward text change. Issue #185: Change entity names
This change is a bit more wide ranging than the other renames, because counties sometimes mean actual physical counties, and other times mean a shift territory that can be a city, zip, county, or collection of counties. For that reason, many of the times, county was changed to shift_territory, but there are many cases where a county_name became a county since there was no more confusion. Issue #185: Change entity names
This does not affect other roles such as homepage link roles, and notification roles, but only the roles attached to positions. These weren't actually roles, so the name brings them more in line with their actual purpose (capabilities), and reduces confusion. This is another wide, but not deep, change. Issue #185: Change entity names
This is BIG!
… On Jun 18, 2020, at 2:58 PM, Frank Duncan ***@***.***> wrote:
Closed #185 <#185> via #242 <#242>.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#185 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA7UUFLQ5NYLPU2HM34UN6DRXJWXFANCNFSM4IMLIA6A>.
|
@frankduncan, @kfogel: After reviewing the staging site, I have only a few minor comments: On the DAT Scheduling page, the Shift Territory Shifts button should be renamed and the Select Highlighting and Show Shifts For columns should be swapped: On any page where a map is shown, Google Maps can't load an image: This is small and probably not an issue but when creating an incident, some of the fields in staging have shifted left . . . . . . versus where they appear in production: Finally, this question is not necessarily related to this issue, however, I'll ask: What is the purpose of a Regional Admin? |
Three issues were found: * Shift Territory Shifts was awkward language (from County Shifts) * A small UI update requested while in there (swapping columns in data scheduler) * Bootstrap update caused some form alignment issues Issue #185: Change entity names
All has been resolved and pushed into staging. As for Region Admins, that appears to be a way to administrate various fields of the Region objects which are only available to people with a certain administration level. Of note, you can go into editing cni, and then change the URL to "gny" and be able to edit that one, so the security isn't really that great. |
@frankduncan: Should Region Admin be renamed Site Admin? |
@OhMcGoo I have no idea! I'm not super sure what the fields in here are for, though they seem to have something to do with Volunteer Connection. I think we may want to hold off renaming until we actually just figure out what the different permissions different people should have around administrating the site, a la #166 |
Change entity names system-wide:
It is understood that this is not simply a matter of cutting and pasting and that relationships between user-seen designations and database nomenclature will have to be explored.
Note that while it may be tempting to also change "Positions" to "Roles" (once the old "Roles" has been moved to "Capabilities" as per above), but we don't want to rename "Positions", because that's a term of art within American Red Cross dispatching and we don't want to gratuitously diverge from it.
The text was updated successfully, but these errors were encountered: