Hi Morgan , 
That makes sense to me. 

Here's a summary of the changes that need to happen for value types:

side note - we should probably make these dropdowns list in alphabetical order unless there's a reason for the current ordering that I'm not aware of. 

For a front-end user, they still only see values that have been assigned to value types when filtering content (?). So for Jurisdiction and I expand the Jurisdiction drop down, I still only see those values that have been assigned to Jurisdiction in the Value Types list. This means that the Value Types list really only exists for the benefit of front end users. 

Hi Anil and Stefanie ,

For some reason this got separated into two to-do's: Problem with Meta Fields and Value List design - TOLOGIX - P3 Prototype for Tologix, and you've both commented on different ones... We'll consolidate everything here. Let's proceed with Stefanie suggestions above, but with the following modifications:

3.  As Anil suggested, change this to "Value Type", and simply make this an option that connects the project meta field to the Value List. Any meta field created in the Project Meta Field list will automatically apply to all projects.

4. Same for documents, change this to "Value Type", and simply make this an option that connect the document meta field to the Value List. Any meta field created in the Document Meta Field list will automatically apply to all documents.

5. Re Stefanie suggestion of separating values of the same type from all other values, I'm worried that admin users will prioritize values of the same type, rather than select the exact match. However, I understand the reasoning behind this, and we can overcome this by encouraging admin users to use the search option. Let's try this, and we can reassess if necessary.

Re font-end user view, correct, when the user selects a particular filter, they will only be presented with the values that have been assigned to that meta field type.

Thanks,

Morgan

Ok sounds good. I'll add this to the target process story. 

Great. Thanks Stefanie .

Morgan 

Hello Stefanie and Morgan ,

We reviewed the revised story but we still have some doubts e.g. where to put "Add Value Type" button. Can you also provide us some screenshots e.g. in which all screens/pages the changes are required? 

Hi Anil ,
I edited the story and added screens - let me know if this is clearer:
https://industrialagency.tpondemand.com/RestUI/Board.aspx#page=board/4857933491727658105&appConfig=eyJhY2lkIjoiOTk1NDg2NkUwM0I1RTJGMzQ5NjgyOTdFRjk2NkRGN0YifQ==&boardPopup=userstory/4232/silent

Morgan  please confirm this to make sure we're all on the same page. 

OK thanks Stefanie !

This seems OK to us, let Morgan  check and confirm.

Hi Stefanie and Anil ,

The requirements state that the admin user has "the capability to add new value types" from the Manage Document/Project Meta Fields pages. Is this necessary? The value types are determined by what values are created when the admin user adds data to a meta field. 

For example, an admin user is entering meta data for a project, and adds "Bel Pacific" in the "Owner of Private Partner(s)" meta field. This would automatically assigned "Bel Pacific" with the "Owner of Private Partner(s)" value type. If the admin user then adds "Bel Pacific" in the "Contractor(s)/Subcontractor(s)" meta field, this would automatically add "Contractor(s)/Subcontractor(s)" as an additional value type to "Bel Pacific". Conversely, if the admin user, goes back and removes "Bel Pacific" from the "Contractor(s)/Subcontractor(s)" meta field, this would update and remove "Contractor(s)/Subcontracotr(s)" as a value type for "Bel Pacific" (assuming there are not other projects that have "Bel Pacific" added as a "Contractor(s)/Subcontracotr(s)").

This way value types are are added/changed as they edits are made to the data entered into the meta fields. This eliminates the need for making changes to value types through the value list. It also prevents admin users from mismatching value types with what has been added to the meta fields (i.e., ensures the value types are always tied to the meta field types).

Also, I think we should change to the default Value Type to "Yes" when a meta field is created. I don't foresee circumstances where we wouldn't want data entered into a meta field not be associated with the value list.

Thanks,

Morgan

Hi Morgan , 
To your first point, this portion of the user story is talking about creating a new value type so the Add Meta Field > check off the radio button to make it a Value Type. Value Types are jurisdiction, projects, public partners etc., and right now there is no way to manually create value new types - this was originally why we started to create this feature. Were you thinking this meant something else or did you want to remove the capability to create new value types? 

Hi Stefanie ,

No, I don't want to remove the capability of creating new value types. I just thought we might be confusing what the value types are for (categorizing values based on the meta fields they are associated with).

Thanks,

Morgan

Morgan   Just to make sure we're on the same page - Essentially making a meta-field a value type is just there for the sake of broadening the list of filters we offer. If we think that all new meta-fields should be value types (meaning we always want them to appear on the front-end as a filter), we should remove the radio button to convert a meta field to a value type. Right now we're assuming that a new meta-field might not be something we always want to appear as a filter. 

Hi Stefanie ,

There may be meta fields that we don't want to appear as a filter on the front-end of the site, which would require a radio button to select that option. At the same time, as I stated above, I don't foresee a reason for creating a meta field that is not tied to the value list. Therefore, may we should change this option from "Value List" to "Filter", which would determine whether the meta-field appears as a front-end filter. Whereas the value list automatically applies to any meta field. Make sense?

Morgan

That sounds good to me Morgan . If you want to check out the updated user story and confirm we should be good.

Anil  

Looks good. Thanks Stefanie .

Morgan 

Hello Morgan and Stefanie ,

As per our understanding, 

That's correct.

For 1 - this would still be added to the value type list but it would not appear on the front-end. I think a new meta-field could be a dropdown or a text box. Morgan please confirm.

To that end, I think we need to add a little more to this because we now need a way to edit if it appears as search filter and we also now need to specify if a new meta-field should appear on all documents or projects. I assume that if you add a new meta-field that isn't a search filter, you wouldn't want this to appear on all documents and projects respectively. Morgan  is that a correct assumption?

Hello Stefanie and Morgan ,

We need to separate this flow such a way that either new meta-field can be added as Textbox or Dropdown. E.g. if "Make this a new search filter" = "No" then it will be a "Textbox" and if Make this a new search filter = "Yes" then it will rendered as "Dropdownbox" otherwise it will be very difficult to manage at development side. Please suggest.

Hi Anil ,

To put simply, I want eliminate the textbox fields entirely from any meta field created through the Manage Document or Project Meta Fields pages. "Make this a search filter" = "No" will only prevent the meta field from being presented as a filter option on the front-end, but the meta field data will always be tied to the value list. Please do what is necessary to make this happen, but I'm confused why this is difficult to manage given that we're already doing this when "Value List" = "Yes". Just make that the default for every meta field, and then create a new option for the front-end filter.

Thanks,

Morgan

Hello Morgan ,

If we need to eliminate textbox entirely then there is no issue. We will do necessary changes so that,

If "Make this a search filter" = "No" then it will be a dropdown but will not be displayed as a filter at front-end.
 
If "Make this a search filter" = "Yes" then it will be a dropdown but will be displayed as a filter at front-end.

Hello Stefanie and Morgan ,

We reviewed the updated user story "#4232 Create Values and Add to Value List" and have a query for the attached screenshot. We think that there is no need of  "Make this a new search filter" field in this screen as this screen is for "values" for "value types". Please let us know your thoughts.

1.jpg 206 KB • Download

Hi Anil , You're right. I'll delete this one. I was thinking there was no way to edit this but there is from the meta field view. 

Hello Morgan and Stefanie ,

We have implemented meta field changes for "Manage Project". This is still in beta. Can you please take a look in "Manage Project" and give your feedback.

Please note that this change will apply to new "Type Names"/"Type Values" only. For old entries we need to map Type and Values manually. We are still working on meta fields for "Edit Document".

Hi Anil ,

I have discovered a number of issues outlined below and in the video. However, Stefanie should probably comment further on ensuring the changes are meeting all the requirements in TargetProcess.

Thanks,

Morgan

Yes, I agree. The values should be made available to all value types (aka available in all dropdowns)  in the project and document levels but the only time we should see a 'value' associated with a 'value type' in the manage values list or in the front end is when:
 a) an admin has selected a 'value' in the 'value type's' dropdown
b) when a value is manually added to a value type from the manage values list

I'm also not seeing the document meta filters on the front-end.

I've added the text change and more clarification to the user story although I think Morgan's video/comments sufficiently outline the change needed. 

Hi Morgan and Stefanie ,

We are still working on this and will get back to you soon.

Hi Morgan and Stefanie ,

We are progressing with this change meantime we have a query as follows:

We think that "Select Type" dropdown is not required in "Edit Value List" as "Type" will be assigned/removed to a "Type Name" using Edit Project or Edit Document screen. Hence, we can remove the dropdown from this screen and show only assigned "Types" in readonly format. However user can edit "Type Name" using this screen. Please let us know your thoughts.

1.jpg 162 KB • Download

I agree Anil . Unless Stefanie sees another reason to keep it, please remove the dropdown. Also, let's change the title for "Type Name" to "Value Name".

Thanks,

Morgan

This sounds good to me as well.

Hello Morgan and Stefanie ,

We have uploaded a beta version for this task on p3lg. Please check and let us know your feedback.

Looks awesome so far Anil . The one thing I did notice is that when I added a document meta field and selected add as search filter, it is showing up but then when I added a project meta field as a search filter, I can see only the project level filter on the front end and the document filter disappears. It seems like there's some kind of limit set on the filters. 

Hi Stefanie and Anil ,

The updates look pretty good, but I have the following items to need further consideration:

Thanks,

Morgan

Hi Anil and Stefanie ,

I realized that my comment above concerning "Problems with saving document in Edit Document state" is the result that I was attempting to save changes on a published document. I'm assuming that implementing Stefanie 's user stories will resolve this problem, but I shouldn't have been able to access the document meta fields when the document is in a published state. 

Thanks,

Morgan

Hello Morgan and Stefanie ,

We will look into above things and get back to you soon. 

I forgot to mention one thing above that if we add any "Type Name" with "Front-end filter" = "Yes", but there is no "Type value" assign to it then it will not be shown at front side as a filter. Hope this is fine.

Hello Morgan ,

Problems with saving values with special characters is resolved on p3lg. Please check and let us know the feedback.

We will look into the other issue (Problem with saving document..) when we will come through the new stories. Hope this is fine.

Hi Anil , to your point above. I think it's fine not to show as a front end filter if there isn't a value assigned yet. 

I do think that the new document flow should resolve these issues. Anil, let me know if you have any questions about those stories. 

Hi Stefanie and Anil ,

Let's keep the settings as is for the front-end filters (i.e., the meta-field doesn't appear until meta data is entered into the field through a project or document). This will ensure we're not causing unused meta fields from appearing on the front-end. We can adjust this at a later stage if necessary. 

Understood concerning the saving issue. We'll hold off on addressing this for the time being.

Also, the punctuation/special character issue appears resolved, so I'll mark this to-do complete.

Morgan

 

Hi Stefanie ,

We will review the new stories for document flow and let you know if anything.