avniproject / avni-webapp

Web application for management and data entry
https://avniproject.org
GNU Affero General Public License v3.0
12 stars 42 forks source link

Add category to organisation #1147

Closed mahalakshme closed 6 months ago

mahalakshme commented 8 months ago

Need:

Acceptance criteria:

Screenshot 2024-04-01 at 10 52 32 AM Screenshot 2024-04-01 at 9 37 01 AM

Technical:

Since more such fields will come up, store category in a JSON field, so that it is extendable for later. This is based on what was discussed during Monday discussion. Feel free to change it based on what is best.

Out of scope:

mahalakshme commented 7 months ago

@vinayvenu / @arjunk review this

1t5j0y commented 7 months ago

The values do not seem to belong to a single dimension and 'category' is too generic. Defeats the purpose of having this as a JSON. Suggest we break them down to more specific dimensions so that it is more extensible in the future. i.e. have something like:

{
  "dataClassification": "prod", < prod | test >
  "usage": "prototype"  < demo | prototype | none > etc
}

or simplify this to having a set of well-defined tags of which one or many can be applied to an org.

mahalakshme commented 7 months ago

@vinayvenu I prefer in keeping them as one category or jusy may be with a different label. You can check the above comment and reply with your opinion.

vinayvenu commented 7 months ago

@mahalakshme I agree with@1t5j0y here. Support looks for prod orgs that are active. Development needs uat orgs that are active, but may also need a backup. Website needs all orgs that have ever gone to prod but needs a separate category for those who have discontinued.

Bunching all of these into a single "category" feels wrong.

mahalakshme commented 7 months ago

@vinayvenu @1t5j0y Once a card moves to Ready lane, it is upto the developer and what the team feels how they want to implement. I am responsible until moving a card to Ready lane. So feel free to decide.

1t5j0y commented 7 months ago

Since this is (mostly) for internal usage and relies heavily on us maintaining this metadata correctly, I'm leaning towards the tags solution since it should serve the purpose and not require us to drill down into the possible dimensions. Also, saves us effort on changes to webapp UI to manage this metadata if/when we introduce new dimensions or values for dimensions. The tags solution does not cater to the other use case of uat-prod org linkage but that is probably best done via a more robust linking mechanism.

mahalakshme commented 7 months ago

@1t5j0y I remember we discussed about tags solution only initially, since that is what I had analysed first. And based on the inputs from product team and sales team, I moved it to this solution which is the current AC. We also discussed the reasons for the same in the last call. I am not sure how to go about this now, the team can decide.

vinayvenu commented 7 months ago

Additional commits https://github.com/avniproject/avni-webapp/commit/9f7bda2c4c40fd7f34a8f4524623206267b70d54

AchalaBelokar commented 6 months ago
petmongrels commented 6 months ago

yes that is expected. implementation and support teams will be mark them UAT etc incrementally.

AchalaBelokar commented 6 months ago
vinayvenu commented 6 months ago

Notes

Issues

Suggestion

AchalaBelokar commented 6 months ago