You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@trafficcontrol.apache.org by "Brown III, William" <Wi...@comcast.com> on 2017/08/01 14:25:56 UTC
Re: Portal: A way to contact owners whenever issues arise
?The delivery services table doesn't have contact information on it. The long descriptions could've been used but the table already has a lot of columns and adding more would make it cluttered. SO INSTEAD I was moving this to the tenant table.
________________________________
From: Dave Neuman <ne...@apache.org>
Sent: Friday, July 28, 2017 2:14 PM
To: users@trafficcontrol.incubator.apache.org
Subject: Re: Portal: A way to contact owners whenever issues arise
I thought the delivery service table already contained columns for contact information? Not near a computer now or I would double check.
On Fri, Jul 28, 2017 at 10:30 Jeremy Mitchell <mi...@gmail.com>> wrote:
I'm generally opposed to adding more columns to the deliveryservice table unless there's a very good reason for it as it already has 50 columns and has turned into a junk drawer of a table. Anyhow, since delivery services are now grouped by tenant, it probably makes sense to add contact information to the tenant table as you indicated.
Or, maybe a contact table makes sense with name, phone, email and then the tenant table has one additional column - contact_id.
something to think about.
Jeremy
On Thu, Jul 27, 2017 at 8:37 AM, Brown III, William <Wi...@comcast.com>> wrote:
https://issues.apache.org/jira/browse/TC-479
What do we want to accomplish?
Fix information pages on Traffic Portal to better display issues with existing delivery services and enforce delivery services to have contact information about their owners.
This was later decided to be moved to the tenants table because delivery services was too congested as it already is.
We will add this to the new Traffic Portal only. These changes may range to affect UI, API and backing database tables.
We will first make the UI changes, and then go into an effort to update the API and database tables to lessen the risk of a database migration error.
What is needed to fix/update it?
* Configure database tables (not null fields) to enforce changes
* Add column name email to be able to contact owner
* Add a tenant/audit field to a delivery services input page
* General UI updates to interact with pages
* Finding owners of existing delivery services and add them to existing services
We will change the code that currently exists in https://github.com/apache/incubator-trafficcontrol/, which is AngularJS and nodeJS code, to support our desired features above. To update the code for the API we will have to add features in Perl to the needed TrafficOps API as well.?
Re: Portal: A way to contact owners whenever issues arise
Posted by Dewayne Richardson <de...@gmail.com>.
When: Read · Wed, Aug 2.
<https://timyo.com/?utm_source=expectationheader&utm_medium=email>
[image: Timyo expectation line]
I think naming fields with a purpose prevents the junk drawer mentality (I
can just throw whatever I want in there). Yes they are great for
multi-purpose use (overloaded), but it makes it really impossible to build
programming rules around all of the different items (or use cases) in that
junk drawer. Now if we build a true "junk drawer" then whatever goes in
there should be totally assumed as "adhoc" and I can empty that drawer
without concern but that never happens because why would I keep something
in there I didn't care about.
So fields designed for annotating should be just that, "long description",
this field tells me more info, are valid. If I decided to wipe that field
out and give a better description, then so beit and typically no one
cares. It's the fields I care about that need a specialized drawer.
-Dew
On Wed, Aug 2, 2017 at 10:01 AM, Durfey, Ryan <Ry...@comcast.com>
wrote:
> I actually find these long description fields very helpful. It allows us
> to create flags in our services that we can retrieve via the API for
> automation purposes. For example, I flag some services as trials vs.
> production. I flag some services as using a particular origin that we
> manage. These are very handy for us. I am not against renaming them
> long term perhaps to something like “custom_#”. The ideal for us would be
> to have 2-4 empty fields we can use to hold misc. flags sort of like custom
> fields.
>
>
>
> These could also be used to short cut development time for new
> configuration management testing where a field is required in the
> database. A new feature could be set to queue off of an existing custom
> field.
>
>
>
> *Ryan Durfey* M | 303-524-5099 <(303)%20524-5099>
>
> CDN Support (24x7): 866-405-2993 <(866)%20405-2993> or
> cdn_support@comcast.com
>
>
>
>
>
> *From: *Jeremy Mitchell <mi...@gmail.com>
> *Reply-To: *"users@trafficcontrol.incubator.apache.org" <
> users@trafficcontrol.incubator.apache.org>
> *Date: *Wednesday, August 2, 2017 at 8:11 AM
> *To: *"users@trafficcontrol.incubator.apache.org" <users@trafficcontrol.
> incubator.apache.org>
> *Subject: *Re: Portal: A way to contact owners whenever issues arise
>
>
>
> it has always seemed silly to me that a delivery service has 3 long
> description fields (long_desc, long_desc_1 and long_desc_2). maybe we take
> this opportunity to rename one to contact_info or something and get our
> "long descriptions" down to just 2. each one is a text field so you could
> put whatever you want into it....phone number, email, gps
> coordinates...whatever...
>
>
>
> jeremy
>
>
>
> On Tue, Aug 1, 2017 at 1:54 PM, Shmulik Asafi <sh...@qwilt.com> wrote:
>
> *typo in last paragraph: this will allow *assigning *Delivery Services...
>
>
>
> On Tue, Aug 1, 2017 at 10:53 PM, Shmulik Asafi <sh...@qwilt.com> wrote:
>
> If already going down a road of new tables, then a more accurate modeling
> for the needs would be these two tables:
>
> - contact table (i.e. username, phone number, email, etc.)
> - position [as in organizational position] table (i.e. position title
> and description)
>
> With two junction tables (many-to-many relations):
>
> - contact-position
> - position-ds
>
> This will allow signing Delivery Services to a Position in some tenant
> (which is likely to be fixed and never change unless the organization
> itself changes - which is a valid case for changing DS ownership),
>
> and to map the Positions to whatever contacts currently occupying it
> (which will change whenever a person is fired)
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Aug 1, 2017 at 10:27 PM, Nir Sopher <ni...@qwilt.com> wrote:
>
> Hi,
>
>
>
> How about putting this information in a separate "delivery-service-focal"
> table?
>
>
>
> It might be a bit of an overkill but there are benefits to such table, for
> example, it allows a single delivery-service to have a set of contacts.
>
>
>
> The table can structured, (while still allowing free text).
>
>
>
> Another idea is that the table may point to a user in the DB, or if the
> contact is not a user of the system - hold the data in designated columns.
>
> I'm not sure however how much such a mix is considered a good practice DB
> wise.
>
>
>
> For example
>
>
>
> ds-id | username | full name | phone number |
> email | comment
>
> -----------+---------------+-----------------+--------------
> ------+----------------+----------------------------
>
> 34 | | R2 D2 | 61-1234567 |
> r2@lucas.com | Call on emergencies
>
> 34 | c-3po | | |
> | Pager: ...
>
>
>
> You can add an API for adding a contact to a DS, as well as an API for a
> user to be able to say he is a focal of the DS.
>
>
>
> Nir
>
>
>
> On Tue, Aug 1, 2017 at 9:21 PM, Durfey, Ryan <Ry...@comcast.com>
> wrote:
>
> My 2 cents:
>
> 1. Tenants are organizations and while organizations generally have
> contacts, they often change and are quickly out of date. I hesitate to
> providing organizational contacts in the Tenant table, especially since
> this wouldn’t directly tie to active users.
> 2. Users roll up to tenants and should have contact information, an
> email address at least and possibly a phone number. A list of Tenant users
> should provide the appropriate contact details for a Tenant based on their
> access levels.
> 3. That being said, with large organizations where you might have 100+
> users and 100+ services where there is no division into sub-tenants, this
> would be confusing as to which user(s) mapped to a particular service.
> 4. I hate to point individual Delivery Services to a single user who
> could leave an organization leaving the service orphaned.
> 5. Perhaps this points to a feature need where users can flag services
> of interest within their Tenant organization for notifications.
>
>
>
> *Ryan Durfey* M | 303-524-5099 <(303)%20524-5099>
>
> CDN Support (24x7): 866-405-2993 <(866)%20405-2993> or
> cdn_support@comcast.com
>
>
>
>
>
> *From: *"Brown III, William" <Wi...@comcast.com>
> *Reply-To: *"users@trafficcontrol.incubator.apache.org" <
> users@trafficcontrol.incubator.apache.org>
> *Date: *Tuesday, August 1, 2017 at 8:26 AM
> *To: *"users@trafficcontrol.incubator.apache.org" <users@trafficcontrol.
> incubator.apache.org>
>
>
> *Subject: *Re: Portal: A way to contact owners whenever issues arise
>
>
>
> The delivery services table doesn't have contact information on it. The
> long descriptions could've been used but the table already has a lot of
> columns and adding more would make it cluttered. SO INSTEAD I was moving
> this to the tenant table.
> ------------------------------
>
> *From:* Dave Neuman <ne...@apache.org>
> *Sent:* Friday, July 28, 2017 2:14 PM
> *To:* users@trafficcontrol.incubator.apache.org
> *Subject:* Re: Portal: A way to contact owners whenever issues arise
>
>
>
> I thought the delivery service table already contained columns for contact
> information? Not near a computer now or I would double check.
>
>
>
> On Fri, Jul 28, 2017 at 10:30 Jeremy Mitchell <mi...@gmail.com>
> wrote:
>
> I'm generally opposed to adding more columns to the deliveryservice table
> unless there's a very good reason for it as it already has 50 columns and
> has turned into a junk drawer of a table. Anyhow, since delivery services
> are now grouped by tenant, it probably makes sense to add contact
> information to the tenant table as you indicated.
>
>
>
> Or, maybe a contact table makes sense with name, phone, email and then the
> tenant table has one additional column - contact_id.
>
>
>
> something to think about.
>
>
>
> Jeremy
>
>
>
> On Thu, Jul 27, 2017 at 8:37 AM, Brown III, William <
> William_BrownIII@comcast.com> wrote:
>
> https://issues.apache.org/jira/browse/TC-479
>
>
>
> *What do we want to accomplish?*
> Fix information pages on Traffic Portal to better display issues with
> existing delivery services and enforce delivery services to have contact
> information about their owners.
> This was later decided to be moved to the *tenants* table because
> delivery services was too congested as it already is.
> We will add this to the new Traffic Portal only. These changes may range
> to affect UI, API and backing database tables.
> We will first make the UI changes, and then go into an effort to update
> the API and database tables to lessen the risk of a database migration
> error.
>
> *What is needed to fix/update it?*
>
> · Configure database tables (not null fields) to enforce changes
>
> · Add column name email to be able to contact owner
>
> · Add a tenant/audit field to a delivery services input page
>
> · General UI updates to interact with pages
>
> · Finding owners of existing delivery services and add them to
> existing services
>
> We will change the code that currently exists in
> https://github.com/apache/incubator-trafficcontrol/, which is AngularJS
> and nodeJS code, to support our desired features above. To update the code
> for the API we will have to add features in Perl to the needed TrafficOps
> API as well.
>
>
>
>
>
>
>
>
>
>
>
> --
>
> *Shmulik Asafi*
> Qwilt | Work: +972-72-2221692 <+972%2072-222-1692>| Mobile:
> +972-54-6581595 <+972%2054-658-1595>| shmulika@qwilt.com <yo...@qwilt.com>
>
>
>
>
>
> --
>
> *Shmulik Asafi*
> Qwilt | Work: +972-72-2221692 <+972%2072-222-1692>| Mobile:
> +972-54-6581595 <+972%2054-658-1595>| shmulika@qwilt.com <yo...@qwilt.com>
>
>
>
Re: Portal: A way to contact owners whenever issues arise
Posted by "Durfey, Ryan" <Ry...@comcast.com>.
I actually find these long description fields very helpful. It allows us to create flags in our services that we can retrieve via the API for automation purposes. For example, I flag some services as trials vs. production. I flag some services as using a particular origin that we manage. These are very handy for us. I am not against renaming them long term perhaps to something like “custom_#”. The ideal for us would be to have 2-4 empty fields we can use to hold misc. flags sort of like custom fields.
These could also be used to short cut development time for new configuration management testing where a field is required in the database. A new feature could be set to queue off of an existing custom field.
Ryan Durfey M | 303-524-5099
CDN Support (24x7): 866-405-2993 or cdn_support@comcast.com<ma...@comcast.com>
From: Jeremy Mitchell <mi...@gmail.com>
Reply-To: "users@trafficcontrol.incubator.apache.org" <us...@trafficcontrol.incubator.apache.org>
Date: Wednesday, August 2, 2017 at 8:11 AM
To: "users@trafficcontrol.incubator.apache.org" <us...@trafficcontrol.incubator.apache.org>
Subject: Re: Portal: A way to contact owners whenever issues arise
it has always seemed silly to me that a delivery service has 3 long description fields (long_desc, long_desc_1 and long_desc_2). maybe we take this opportunity to rename one to contact_info or something and get our "long descriptions" down to just 2. each one is a text field so you could put whatever you want into it....phone number, email, gps coordinates...whatever...
jeremy
On Tue, Aug 1, 2017 at 1:54 PM, Shmulik Asafi <sh...@qwilt.com>> wrote:
*typo in last paragraph: this will allow assigning Delivery Services...
On Tue, Aug 1, 2017 at 10:53 PM, Shmulik Asafi <sh...@qwilt.com>> wrote:
If already going down a road of new tables, then a more accurate modeling for the needs would be these two tables:
* contact table (i.e. username, phone number, email, etc.)
* position [as in organizational position] table (i.e. position title and description)
With two junction tables (many-to-many relations):
* contact-position
* position-ds
This will allow signing Delivery Services to a Position in some tenant (which is likely to be fixed and never change unless the organization itself changes - which is a valid case for changing DS ownership),
and to map the Positions to whatever contacts currently occupying it (which will change whenever a person is fired)
On Tue, Aug 1, 2017 at 10:27 PM, Nir Sopher <ni...@qwilt.com>> wrote:
Hi,
How about putting this information in a separate "delivery-service-focal" table?
It might be a bit of an overkill but there are benefits to such table, for example, it allows a single delivery-service to have a set of contacts.
The table can structured, (while still allowing free text).
Another idea is that the table may point to a user in the DB, or if the contact is not a user of the system - hold the data in designated columns.
I'm not sure however how much such a mix is considered a good practice DB wise.
For example
ds-id | username | full name | phone number | email | comment
-----------+---------------+-----------------+--------------------+----------------+----------------------------
34 | | R2 D2 | 61-1234567 | r2@lucas.com<ma...@lucas.com> | Call on emergencies
34 | c-3po | | | | Pager: ...
You can add an API for adding a contact to a DS, as well as an API for a user to be able to say he is a focal of the DS.
Nir
On Tue, Aug 1, 2017 at 9:21 PM, Durfey, Ryan <Ry...@comcast.com>> wrote:
My 2 cents:
1. Tenants are organizations and while organizations generally have contacts, they often change and are quickly out of date. I hesitate to providing organizational contacts in the Tenant table, especially since this wouldn’t directly tie to active users.
2. Users roll up to tenants and should have contact information, an email address at least and possibly a phone number. A list of Tenant users should provide the appropriate contact details for a Tenant based on their access levels.
3. That being said, with large organizations where you might have 100+ users and 100+ services where there is no division into sub-tenants, this would be confusing as to which user(s) mapped to a particular service.
4. I hate to point individual Delivery Services to a single user who could leave an organization leaving the service orphaned.
5. Perhaps this points to a feature need where users can flag services of interest within their Tenant organization for notifications.
Ryan Durfey M | 303-524-5099<tel:(303)%20524-5099>
CDN Support (24x7): 866-405-2993<tel:(866)%20405-2993> or cdn_support@comcast.com<ma...@comcast.com>
From: "Brown III, William" <Wi...@comcast.com>>
Reply-To: "users@trafficcontrol.incubator.apache.org<ma...@trafficcontrol.incubator.apache.org>" <us...@trafficcontrol.incubator.apache.org>>
Date: Tuesday, August 1, 2017 at 8:26 AM
To: "users@trafficcontrol.incubator.apache.org<ma...@trafficcontrol.incubator.apache.org>" <us...@trafficcontrol.incubator.apache.org>>
Subject: Re: Portal: A way to contact owners whenever issues arise
The delivery services table doesn't have contact information on it. The long descriptions could've been used but the table already has a lot of columns and adding more would make it cluttered. SO INSTEAD I was moving this to the tenant table.
________________________________
From: Dave Neuman <ne...@apache.org>>
Sent: Friday, July 28, 2017 2:14 PM
To: users@trafficcontrol.incubator.apache.org<ma...@trafficcontrol.incubator.apache.org>
Subject: Re: Portal: A way to contact owners whenever issues arise
I thought the delivery service table already contained columns for contact information? Not near a computer now or I would double check.
On Fri, Jul 28, 2017 at 10:30 Jeremy Mitchell <mi...@gmail.com>> wrote:
I'm generally opposed to adding more columns to the deliveryservice table unless there's a very good reason for it as it already has 50 columns and has turned into a junk drawer of a table. Anyhow, since delivery services are now grouped by tenant, it probably makes sense to add contact information to the tenant table as you indicated.
Or, maybe a contact table makes sense with name, phone, email and then the tenant table has one additional column - contact_id.
something to think about.
Jeremy
On Thu, Jul 27, 2017 at 8:37 AM, Brown III, William <Wi...@comcast.com>> wrote:
https://issues.apache.org/jira/browse/TC-479
What do we want to accomplish?
Fix information pages on Traffic Portal to better display issues with existing delivery services and enforce delivery services to have contact information about their owners.
This was later decided to be moved to the tenants table because delivery services was too congested as it already is.
We will add this to the new Traffic Portal only. These changes may range to affect UI, API and backing database tables.
We will first make the UI changes, and then go into an effort to update the API and database tables to lessen the risk of a database migration error.
What is needed to fix/update it?
• Configure database tables (not null fields) to enforce changes
• Add column name email to be able to contact owner
• Add a tenant/audit field to a delivery services input page
• General UI updates to interact with pages
• Finding owners of existing delivery services and add them to existing services
We will change the code that currently exists in https://github.com/apache/incubator-trafficcontrol/, which is AngularJS and nodeJS code, to support our desired features above. To update the code for the API we will have to add features in Perl to the needed TrafficOps API as well.
--
Shmulik Asafi
Qwilt | Work: +972-72-2221692<tel:+972%2072-222-1692>| Mobile: +972-54-6581595<tel:+972%2054-658-1595>| shmulika@qwilt.com<ma...@qwilt.com>
--
Shmulik Asafi
Qwilt | Work: +972-72-2221692<tel:+972%2072-222-1692>| Mobile: +972-54-6581595<tel:+972%2054-658-1595>| shmulika@qwilt.com<ma...@qwilt.com>
Re: Portal: A way to contact owners whenever issues arise
Posted by Jeremy Mitchell <mi...@gmail.com>.
it has always seemed silly to me that a delivery service has 3 long
description fields (long_desc, long_desc_1 and long_desc_2). maybe we take
this opportunity to rename one to contact_info or something and get our
"long descriptions" down to just 2. each one is a text field so you could
put whatever you want into it....phone number, email, gps
coordinates...whatever...
jeremy
On Tue, Aug 1, 2017 at 1:54 PM, Shmulik Asafi <sh...@qwilt.com> wrote:
> *typo in last paragraph: this will allow *assigning *Delivery Services...
>
> On Tue, Aug 1, 2017 at 10:53 PM, Shmulik Asafi <sh...@qwilt.com> wrote:
>
>> If already going down a road of new tables, then a more accurate modeling
>> for the needs would be these two tables:
>>
>> - contact table (i.e. username, phone number, email, etc.)
>> - position [as in organizational position] table (i.e. position title
>> and description)
>>
>> With two junction tables (many-to-many relations):
>>
>> - contact-position
>> - position-ds
>>
>> This will allow signing Delivery Services to a Position in some tenant
>> (which is likely to be fixed and never change unless the organization
>> itself changes - which is a valid case for changing DS ownership),
>> and to map the Positions to whatever contacts currently occupying it
>> (which will change whenever a person is fired)
>>
>>
>>
>>
>>
>> On Tue, Aug 1, 2017 at 10:27 PM, Nir Sopher <ni...@qwilt.com> wrote:
>>
>>> Hi,
>>>
>>> How about putting this information in a separate
>>> "delivery-service-focal" table?
>>>
>>> It might be a bit of an overkill but there are benefits to such table,
>>> for example, it allows a single delivery-service to have a set of contacts.
>>>
>>> The table can structured, (while still allowing free text).
>>>
>>> Another idea is that the table may point to a user in the DB, or if the
>>> contact is not a user of the system - hold the data in designated columns.
>>> I'm not sure however how much such a mix is considered a good practice
>>> DB wise.
>>>
>>> For example
>>>
>>> ds-id | username | full name | phone number |
>>> email | comment
>>> -----------+---------------+-----------------+--------------
>>> ------+----------------+----------------------------
>>> 34 | | R2 D2 | 61-1234567 |
>>> r2@lucas.com | Call on emergencies
>>> 34 | c-3po | | |
>>> | Pager: ...
>>>
>>> You can add an API for adding a contact to a DS, as well as an API for a
>>> user to be able to say he is a focal of the DS.
>>>
>>> Nir
>>>
>>> On Tue, Aug 1, 2017 at 9:21 PM, Durfey, Ryan <Ry...@comcast.com>
>>> wrote:
>>>
>>>> My 2 cents:
>>>>
>>>> 1. Tenants are organizations and while organizations generally have
>>>> contacts, they often change and are quickly out of date. I hesitate to
>>>> providing organizational contacts in the Tenant table, especially since
>>>> this wouldn’t directly tie to active users.
>>>> 2. Users roll up to tenants and should have contact information, an
>>>> email address at least and possibly a phone number. A list of Tenant users
>>>> should provide the appropriate contact details for a Tenant based on their
>>>> access levels.
>>>> 3. That being said, with large organizations where you might have
>>>> 100+ users and 100+ services where there is no division into sub-tenants,
>>>> this would be confusing as to which user(s) mapped to a particular service.
>>>> 4. I hate to point individual Delivery Services to a single user
>>>> who could leave an organization leaving the service orphaned.
>>>> 5. Perhaps this points to a feature need where users can flag
>>>> services of interest within their Tenant organization for notifications.
>>>>
>>>>
>>>>
>>>> *Ryan Durfey* M | 303-524-5099 <(303)%20524-5099>
>>>>
>>>> CDN Support (24x7): 866-405-2993 <(866)%20405-2993> or
>>>> cdn_support@comcast.com
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *From: *"Brown III, William" <Wi...@comcast.com>
>>>> *Reply-To: *"users@trafficcontrol.incubator.apache.org" <
>>>> users@trafficcontrol.incubator.apache.org>
>>>> *Date: *Tuesday, August 1, 2017 at 8:26 AM
>>>> *To: *"users@trafficcontrol.incubator.apache.org" <
>>>> users@trafficcontrol.incubator.apache.org>
>>>>
>>>> *Subject: *Re: Portal: A way to contact owners whenever issues arise
>>>>
>>>>
>>>>
>>>> The delivery services table doesn't have contact information on it.
>>>> The long descriptions could've been used but the table already has a lot of
>>>> columns and adding more would make it cluttered. SO INSTEAD I was moving
>>>> this to the tenant table.
>>>> ------------------------------
>>>>
>>>> *From:* Dave Neuman <ne...@apache.org>
>>>> *Sent:* Friday, July 28, 2017 2:14 PM
>>>> *To:* users@trafficcontrol.incubator.apache.org
>>>> *Subject:* Re: Portal: A way to contact owners whenever issues arise
>>>>
>>>>
>>>>
>>>> I thought the delivery service table already contained columns for
>>>> contact information? Not near a computer now or I would double check.
>>>>
>>>>
>>>>
>>>> On Fri, Jul 28, 2017 at 10:30 Jeremy Mitchell <mi...@gmail.com>
>>>> wrote:
>>>>
>>>> I'm generally opposed to adding more columns to the deliveryservice
>>>> table unless there's a very good reason for it as it already has 50 columns
>>>> and has turned into a junk drawer of a table. Anyhow, since delivery
>>>> services are now grouped by tenant, it probably makes sense to add contact
>>>> information to the tenant table as you indicated.
>>>>
>>>>
>>>>
>>>> Or, maybe a contact table makes sense with name, phone, email and then
>>>> the tenant table has one additional column - contact_id.
>>>>
>>>>
>>>>
>>>> something to think about.
>>>>
>>>>
>>>>
>>>> Jeremy
>>>>
>>>>
>>>>
>>>> On Thu, Jul 27, 2017 at 8:37 AM, Brown III, William <
>>>> William_BrownIII@comcast.com> wrote:
>>>>
>>>> https://issues.apache.org/jira/browse/TC-479
>>>>
>>>>
>>>>
>>>> *What do we want to accomplish?*
>>>> Fix information pages on Traffic Portal to better display issues with
>>>> existing delivery services and enforce delivery services to have contact
>>>> information about their owners.
>>>> This was later decided to be moved to the *tenants* table because
>>>> delivery services was too congested as it already is.
>>>> We will add this to the new Traffic Portal only. These changes may
>>>> range to affect UI, API and backing database tables.
>>>> We will first make the UI changes, and then go into an effort to update
>>>> the API and database tables to lessen the risk of a database migration
>>>> error.
>>>>
>>>> *What is needed to fix/update it?*
>>>>
>>>> · Configure database tables (not null fields) to enforce
>>>> changes
>>>>
>>>> · Add column name email to be able to contact owner
>>>>
>>>> · Add a tenant/audit field to a delivery services input page
>>>>
>>>> · General UI updates to interact with pages
>>>>
>>>> · Finding owners of existing delivery services and add them to
>>>> existing services
>>>>
>>>> We will change the code that currently exists in
>>>> https://github.com/apache/incubator-trafficcontrol/, which is
>>>> AngularJS and nodeJS code, to support our desired features above. To update
>>>> the code for the API we will have to add features in Perl to the needed
>>>> TrafficOps API as well.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> *Shmulik Asafi*
>> Qwilt | Work: +972-72-2221692 <+972%2072-222-1692>| Mobile:
>> +972-54-6581595 <+972%2054-658-1595>| shmulika@qwilt.com <yo...@qwilt.com>
>>
>
>
>
> --
> *Shmulik Asafi*
> Qwilt | Work: +972-72-2221692 <+972%2072-222-1692>| Mobile:
> +972-54-6581595 <+972%2054-658-1595>| shmulika@qwilt.com <yo...@qwilt.com>
>
Re: Portal: A way to contact owners whenever issues arise
Posted by Shmulik Asafi <sh...@qwilt.com>.
*typo in last paragraph: this will allow *assigning *Delivery Services...
On Tue, Aug 1, 2017 at 10:53 PM, Shmulik Asafi <sh...@qwilt.com> wrote:
> If already going down a road of new tables, then a more accurate modeling
> for the needs would be these two tables:
>
> - contact table (i.e. username, phone number, email, etc.)
> - position [as in organizational position] table (i.e. position title
> and description)
>
> With two junction tables (many-to-many relations):
>
> - contact-position
> - position-ds
>
> This will allow signing Delivery Services to a Position in some tenant
> (which is likely to be fixed and never change unless the organization
> itself changes - which is a valid case for changing DS ownership),
> and to map the Positions to whatever contacts currently occupying it
> (which will change whenever a person is fired)
>
>
>
>
>
> On Tue, Aug 1, 2017 at 10:27 PM, Nir Sopher <ni...@qwilt.com> wrote:
>
>> Hi,
>>
>> How about putting this information in a separate "delivery-service-focal"
>> table?
>>
>> It might be a bit of an overkill but there are benefits to such table,
>> for example, it allows a single delivery-service to have a set of contacts.
>>
>> The table can structured, (while still allowing free text).
>>
>> Another idea is that the table may point to a user in the DB, or if the
>> contact is not a user of the system - hold the data in designated columns.
>> I'm not sure however how much such a mix is considered a good practice DB
>> wise.
>>
>> For example
>>
>> ds-id | username | full name | phone number |
>> email | comment
>> -----------+---------------+-----------------+--------------
>> ------+----------------+----------------------------
>> 34 | | R2 D2 | 61-1234567 |
>> r2@lucas.com | Call on emergencies
>> 34 | c-3po | | |
>> | Pager: ...
>>
>> You can add an API for adding a contact to a DS, as well as an API for a
>> user to be able to say he is a focal of the DS.
>>
>> Nir
>>
>> On Tue, Aug 1, 2017 at 9:21 PM, Durfey, Ryan <Ry...@comcast.com>
>> wrote:
>>
>>> My 2 cents:
>>>
>>> 1. Tenants are organizations and while organizations generally have
>>> contacts, they often change and are quickly out of date. I hesitate to
>>> providing organizational contacts in the Tenant table, especially since
>>> this wouldn’t directly tie to active users.
>>> 2. Users roll up to tenants and should have contact information, an
>>> email address at least and possibly a phone number. A list of Tenant users
>>> should provide the appropriate contact details for a Tenant based on their
>>> access levels.
>>> 3. That being said, with large organizations where you might have
>>> 100+ users and 100+ services where there is no division into sub-tenants,
>>> this would be confusing as to which user(s) mapped to a particular service.
>>> 4. I hate to point individual Delivery Services to a single user who
>>> could leave an organization leaving the service orphaned.
>>> 5. Perhaps this points to a feature need where users can flag
>>> services of interest within their Tenant organization for notifications.
>>>
>>>
>>>
>>> *Ryan Durfey* M | 303-524-5099 <(303)%20524-5099>
>>>
>>> CDN Support (24x7): 866-405-2993 <(866)%20405-2993> or
>>> cdn_support@comcast.com
>>>
>>>
>>>
>>>
>>>
>>> *From: *"Brown III, William" <Wi...@comcast.com>
>>> *Reply-To: *"users@trafficcontrol.incubator.apache.org" <
>>> users@trafficcontrol.incubator.apache.org>
>>> *Date: *Tuesday, August 1, 2017 at 8:26 AM
>>> *To: *"users@trafficcontrol.incubator.apache.org" <
>>> users@trafficcontrol.incubator.apache.org>
>>>
>>> *Subject: *Re: Portal: A way to contact owners whenever issues arise
>>>
>>>
>>>
>>> The delivery services table doesn't have contact information on it. The
>>> long descriptions could've been used but the table already has a lot of
>>> columns and adding more would make it cluttered. SO INSTEAD I was moving
>>> this to the tenant table.
>>> ------------------------------
>>>
>>> *From:* Dave Neuman <ne...@apache.org>
>>> *Sent:* Friday, July 28, 2017 2:14 PM
>>> *To:* users@trafficcontrol.incubator.apache.org
>>> *Subject:* Re: Portal: A way to contact owners whenever issues arise
>>>
>>>
>>>
>>> I thought the delivery service table already contained columns for
>>> contact information? Not near a computer now or I would double check.
>>>
>>>
>>>
>>> On Fri, Jul 28, 2017 at 10:30 Jeremy Mitchell <mi...@gmail.com>
>>> wrote:
>>>
>>> I'm generally opposed to adding more columns to the deliveryservice
>>> table unless there's a very good reason for it as it already has 50 columns
>>> and has turned into a junk drawer of a table. Anyhow, since delivery
>>> services are now grouped by tenant, it probably makes sense to add contact
>>> information to the tenant table as you indicated.
>>>
>>>
>>>
>>> Or, maybe a contact table makes sense with name, phone, email and then
>>> the tenant table has one additional column - contact_id.
>>>
>>>
>>>
>>> something to think about.
>>>
>>>
>>>
>>> Jeremy
>>>
>>>
>>>
>>> On Thu, Jul 27, 2017 at 8:37 AM, Brown III, William <
>>> William_BrownIII@comcast.com> wrote:
>>>
>>> https://issues.apache.org/jira/browse/TC-479
>>>
>>>
>>>
>>> *What do we want to accomplish?*
>>> Fix information pages on Traffic Portal to better display issues with
>>> existing delivery services and enforce delivery services to have contact
>>> information about their owners.
>>> This was later decided to be moved to the *tenants* table because
>>> delivery services was too congested as it already is.
>>> We will add this to the new Traffic Portal only. These changes may range
>>> to affect UI, API and backing database tables.
>>> We will first make the UI changes, and then go into an effort to update
>>> the API and database tables to lessen the risk of a database migration
>>> error.
>>>
>>> *What is needed to fix/update it?*
>>>
>>> · Configure database tables (not null fields) to enforce changes
>>>
>>> · Add column name email to be able to contact owner
>>>
>>> · Add a tenant/audit field to a delivery services input page
>>>
>>> · General UI updates to interact with pages
>>>
>>> · Finding owners of existing delivery services and add them to
>>> existing services
>>>
>>> We will change the code that currently exists in
>>> https://github.com/apache/incubator-trafficcontrol/, which is AngularJS
>>> and nodeJS code, to support our desired features above. To update the code
>>> for the API we will have to add features in Perl to the needed TrafficOps
>>> API as well.
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
>
> --
> *Shmulik Asafi*
> Qwilt | Work: +972-72-2221692 <+972%2072-222-1692>| Mobile:
> +972-54-6581595 <+972%2054-658-1595>| shmulika@qwilt.com <yo...@qwilt.com>
>
--
*Shmulik Asafi*
Qwilt | Work: +972-72-2221692| Mobile: +972-54-6581595| shmulika@qwilt.com
<yo...@qwilt.com>
Re: Portal: A way to contact owners whenever issues arise
Posted by Shmulik Asafi <sh...@qwilt.com>.
If already going down a road of new tables, then a more accurate modeling
for the needs would be these two tables:
- contact table (i.e. username, phone number, email, etc.)
- position [as in organizational position] table (i.e. position title
and description)
With two junction tables (many-to-many relations):
- contact-position
- position-ds
This will allow signing Delivery Services to a Position in some tenant
(which is likely to be fixed and never change unless the organization
itself changes - which is a valid case for changing DS ownership),
and to map the Positions to whatever contacts currently occupying it (which
will change whenever a person is fired)
On Tue, Aug 1, 2017 at 10:27 PM, Nir Sopher <ni...@qwilt.com> wrote:
> Hi,
>
> How about putting this information in a separate "delivery-service-focal"
> table?
>
> It might be a bit of an overkill but there are benefits to such table, for
> example, it allows a single delivery-service to have a set of contacts.
>
> The table can structured, (while still allowing free text).
>
> Another idea is that the table may point to a user in the DB, or if the
> contact is not a user of the system - hold the data in designated columns.
> I'm not sure however how much such a mix is considered a good practice DB
> wise.
>
> For example
>
> ds-id | username | full name | phone number |
> email | comment
> -----------+---------------+-----------------+--------------
> ------+----------------+----------------------------
> 34 | | R2 D2 | 61-1234567 |
> r2@lucas.com | Call on emergencies
> 34 | c-3po | | |
> | Pager: ...
>
> You can add an API for adding a contact to a DS, as well as an API for a
> user to be able to say he is a focal of the DS.
>
> Nir
>
> On Tue, Aug 1, 2017 at 9:21 PM, Durfey, Ryan <Ry...@comcast.com>
> wrote:
>
>> My 2 cents:
>>
>> 1. Tenants are organizations and while organizations generally have
>> contacts, they often change and are quickly out of date. I hesitate to
>> providing organizational contacts in the Tenant table, especially since
>> this wouldn’t directly tie to active users.
>> 2. Users roll up to tenants and should have contact information, an
>> email address at least and possibly a phone number. A list of Tenant users
>> should provide the appropriate contact details for a Tenant based on their
>> access levels.
>> 3. That being said, with large organizations where you might have
>> 100+ users and 100+ services where there is no division into sub-tenants,
>> this would be confusing as to which user(s) mapped to a particular service.
>> 4. I hate to point individual Delivery Services to a single user who
>> could leave an organization leaving the service orphaned.
>> 5. Perhaps this points to a feature need where users can flag
>> services of interest within their Tenant organization for notifications.
>>
>>
>>
>> *Ryan Durfey* M | 303-524-5099 <(303)%20524-5099>
>>
>> CDN Support (24x7): 866-405-2993 <(866)%20405-2993> or
>> cdn_support@comcast.com
>>
>>
>>
>>
>>
>> *From: *"Brown III, William" <Wi...@comcast.com>
>> *Reply-To: *"users@trafficcontrol.incubator.apache.org" <
>> users@trafficcontrol.incubator.apache.org>
>> *Date: *Tuesday, August 1, 2017 at 8:26 AM
>> *To: *"users@trafficcontrol.incubator.apache.org" <
>> users@trafficcontrol.incubator.apache.org>
>>
>> *Subject: *Re: Portal: A way to contact owners whenever issues arise
>>
>>
>>
>> The delivery services table doesn't have contact information on it. The
>> long descriptions could've been used but the table already has a lot of
>> columns and adding more would make it cluttered. SO INSTEAD I was moving
>> this to the tenant table.
>> ------------------------------
>>
>> *From:* Dave Neuman <ne...@apache.org>
>> *Sent:* Friday, July 28, 2017 2:14 PM
>> *To:* users@trafficcontrol.incubator.apache.org
>> *Subject:* Re: Portal: A way to contact owners whenever issues arise
>>
>>
>>
>> I thought the delivery service table already contained columns for
>> contact information? Not near a computer now or I would double check.
>>
>>
>>
>> On Fri, Jul 28, 2017 at 10:30 Jeremy Mitchell <mi...@gmail.com>
>> wrote:
>>
>> I'm generally opposed to adding more columns to the deliveryservice table
>> unless there's a very good reason for it as it already has 50 columns and
>> has turned into a junk drawer of a table. Anyhow, since delivery services
>> are now grouped by tenant, it probably makes sense to add contact
>> information to the tenant table as you indicated.
>>
>>
>>
>> Or, maybe a contact table makes sense with name, phone, email and then
>> the tenant table has one additional column - contact_id.
>>
>>
>>
>> something to think about.
>>
>>
>>
>> Jeremy
>>
>>
>>
>> On Thu, Jul 27, 2017 at 8:37 AM, Brown III, William <
>> William_BrownIII@comcast.com> wrote:
>>
>> https://issues.apache.org/jira/browse/TC-479
>>
>>
>>
>> *What do we want to accomplish?*
>> Fix information pages on Traffic Portal to better display issues with
>> existing delivery services and enforce delivery services to have contact
>> information about their owners.
>> This was later decided to be moved to the *tenants* table because
>> delivery services was too congested as it already is.
>> We will add this to the new Traffic Portal only. These changes may range
>> to affect UI, API and backing database tables.
>> We will first make the UI changes, and then go into an effort to update
>> the API and database tables to lessen the risk of a database migration
>> error.
>>
>> *What is needed to fix/update it?*
>>
>> · Configure database tables (not null fields) to enforce changes
>>
>> · Add column name email to be able to contact owner
>>
>> · Add a tenant/audit field to a delivery services input page
>>
>> · General UI updates to interact with pages
>>
>> · Finding owners of existing delivery services and add them to
>> existing services
>>
>> We will change the code that currently exists in
>> https://github.com/apache/incubator-trafficcontrol/, which is AngularJS
>> and nodeJS code, to support our desired features above. To update the code
>> for the API we will have to add features in Perl to the needed TrafficOps
>> API as well.
>>
>>
>>
>>
>>
>>
>
--
*Shmulik Asafi*
Qwilt | Work: +972-72-2221692| Mobile: +972-54-6581595| shmulika@qwilt.com
<yo...@qwilt.com>
Re: Portal: A way to contact owners whenever issues arise
Posted by Nir Sopher <ni...@qwilt.com>.
Hi,
How about putting this information in a separate "delivery-service-focal"
table?
It might be a bit of an overkill but there are benefits to such table, for
example, it allows a single delivery-service to have a set of contacts.
The table can structured, (while still allowing free text).
Another idea is that the table may point to a user in the DB, or if the
contact is not a user of the system - hold the data in designated columns.
I'm not sure however how much such a mix is considered a good practice DB
wise.
For example
ds-id | username | full name | phone number |
email | comment
-----------+---------------+-----------------+--------------------+----------------+----------------------------
34 | | R2 D2 | 61-1234567 |
r2@lucas.com | Call on emergencies
34 | c-3po | | |
| Pager: ...
You can add an API for adding a contact to a DS, as well as an API for a
user to be able to say he is a focal of the DS.
Nir
On Tue, Aug 1, 2017 at 9:21 PM, Durfey, Ryan <Ry...@comcast.com>
wrote:
> My 2 cents:
>
> 1. Tenants are organizations and while organizations generally have
> contacts, they often change and are quickly out of date. I hesitate to
> providing organizational contacts in the Tenant table, especially since
> this wouldn’t directly tie to active users.
> 2. Users roll up to tenants and should have contact information, an
> email address at least and possibly a phone number. A list of Tenant users
> should provide the appropriate contact details for a Tenant based on their
> access levels.
> 3. That being said, with large organizations where you might have 100+
> users and 100+ services where there is no division into sub-tenants, this
> would be confusing as to which user(s) mapped to a particular service.
> 4. I hate to point individual Delivery Services to a single user who
> could leave an organization leaving the service orphaned.
> 5. Perhaps this points to a feature need where users can flag services
> of interest within their Tenant organization for notifications.
>
>
>
> *Ryan Durfey* M | 303-524-5099 <(303)%20524-5099>
>
> CDN Support (24x7): 866-405-2993 <(866)%20405-2993> or
> cdn_support@comcast.com
>
>
>
>
>
> *From: *"Brown III, William" <Wi...@comcast.com>
> *Reply-To: *"users@trafficcontrol.incubator.apache.org" <
> users@trafficcontrol.incubator.apache.org>
> *Date: *Tuesday, August 1, 2017 at 8:26 AM
> *To: *"users@trafficcontrol.incubator.apache.org" <users@trafficcontrol.
> incubator.apache.org>
>
> *Subject: *Re: Portal: A way to contact owners whenever issues arise
>
>
>
> The delivery services table doesn't have contact information on it. The
> long descriptions could've been used but the table already has a lot of
> columns and adding more would make it cluttered. SO INSTEAD I was moving
> this to the tenant table.
> ------------------------------
>
> *From:* Dave Neuman <ne...@apache.org>
> *Sent:* Friday, July 28, 2017 2:14 PM
> *To:* users@trafficcontrol.incubator.apache.org
> *Subject:* Re: Portal: A way to contact owners whenever issues arise
>
>
>
> I thought the delivery service table already contained columns for contact
> information? Not near a computer now or I would double check.
>
>
>
> On Fri, Jul 28, 2017 at 10:30 Jeremy Mitchell <mi...@gmail.com>
> wrote:
>
> I'm generally opposed to adding more columns to the deliveryservice table
> unless there's a very good reason for it as it already has 50 columns and
> has turned into a junk drawer of a table. Anyhow, since delivery services
> are now grouped by tenant, it probably makes sense to add contact
> information to the tenant table as you indicated.
>
>
>
> Or, maybe a contact table makes sense with name, phone, email and then the
> tenant table has one additional column - contact_id.
>
>
>
> something to think about.
>
>
>
> Jeremy
>
>
>
> On Thu, Jul 27, 2017 at 8:37 AM, Brown III, William <
> William_BrownIII@comcast.com> wrote:
>
> https://issues.apache.org/jira/browse/TC-479
>
>
>
> *What do we want to accomplish?*
> Fix information pages on Traffic Portal to better display issues with
> existing delivery services and enforce delivery services to have contact
> information about their owners.
> This was later decided to be moved to the *tenants* table because
> delivery services was too congested as it already is.
> We will add this to the new Traffic Portal only. These changes may range
> to affect UI, API and backing database tables.
> We will first make the UI changes, and then go into an effort to update
> the API and database tables to lessen the risk of a database migration
> error.
>
> *What is needed to fix/update it?*
>
> · Configure database tables (not null fields) to enforce changes
>
> · Add column name email to be able to contact owner
>
> · Add a tenant/audit field to a delivery services input page
>
> · General UI updates to interact with pages
>
> · Finding owners of existing delivery services and add them to
> existing services
>
> We will change the code that currently exists in
> https://github.com/apache/incubator-trafficcontrol/, which is AngularJS
> and nodeJS code, to support our desired features above. To update the code
> for the API we will have to add features in Perl to the needed TrafficOps
> API as well.
>
>
>
>
>
>
Re: Portal: A way to contact owners whenever issues arise
Posted by "Durfey, Ryan" <Ry...@comcast.com>.
My 2 cents:
1. Tenants are organizations and while organizations generally have contacts, they often change and are quickly out of date. I hesitate to providing organizational contacts in the Tenant table, especially since this wouldn’t directly tie to active users.
2. Users roll up to tenants and should have contact information, an email address at least and possibly a phone number. A list of Tenant users should provide the appropriate contact details for a Tenant based on their access levels.
3. That being said, with large organizations where you might have 100+ users and 100+ services where there is no division into sub-tenants, this would be confusing as to which user(s) mapped to a particular service.
4. I hate to point individual Delivery Services to a single user who could leave an organization leaving the service orphaned.
5. Perhaps this points to a feature need where users can flag services of interest within their Tenant organization for notifications.
Ryan Durfey M | 303-524-5099
CDN Support (24x7): 866-405-2993 or cdn_support@comcast.com<ma...@comcast.com>
From: "Brown III, William" <Wi...@comcast.com>
Reply-To: "users@trafficcontrol.incubator.apache.org" <us...@trafficcontrol.incubator.apache.org>
Date: Tuesday, August 1, 2017 at 8:26 AM
To: "users@trafficcontrol.incubator.apache.org" <us...@trafficcontrol.incubator.apache.org>
Subject: Re: Portal: A way to contact owners whenever issues arise
The delivery services table doesn't have contact information on it. The long descriptions could've been used but the table already has a lot of columns and adding more would make it cluttered. SO INSTEAD I was moving this to the tenant table.
________________________________
From: Dave Neuman <ne...@apache.org>
Sent: Friday, July 28, 2017 2:14 PM
To: users@trafficcontrol.incubator.apache.org
Subject: Re: Portal: A way to contact owners whenever issues arise
I thought the delivery service table already contained columns for contact information? Not near a computer now or I would double check.
On Fri, Jul 28, 2017 at 10:30 Jeremy Mitchell <mi...@gmail.com>> wrote:
I'm generally opposed to adding more columns to the deliveryservice table unless there's a very good reason for it as it already has 50 columns and has turned into a junk drawer of a table. Anyhow, since delivery services are now grouped by tenant, it probably makes sense to add contact information to the tenant table as you indicated.
Or, maybe a contact table makes sense with name, phone, email and then the tenant table has one additional column - contact_id.
something to think about.
Jeremy
On Thu, Jul 27, 2017 at 8:37 AM, Brown III, William <Wi...@comcast.com>> wrote:
https://issues.apache.org/jira/browse/TC-479
What do we want to accomplish?
Fix information pages on Traffic Portal to better display issues with existing delivery services and enforce delivery services to have contact information about their owners.
This was later decided to be moved to the tenants table because delivery services was too congested as it already is.
We will add this to the new Traffic Portal only. These changes may range to affect UI, API and backing database tables.
We will first make the UI changes, and then go into an effort to update the API and database tables to lessen the risk of a database migration error.
What is needed to fix/update it?
· Configure database tables (not null fields) to enforce changes
· Add column name email to be able to contact owner
· Add a tenant/audit field to a delivery services input page
· General UI updates to interact with pages
· Finding owners of existing delivery services and add them to existing services
We will change the code that currently exists in https://github.com/apache/incubator-trafficcontrol/, which is AngularJS and nodeJS code, to support our desired features above. To update the code for the API we will have to add features in Perl to the needed TrafficOps API as well.