Licenses (UXPROD-574)

[ERM-355] Manage public notes on license term values Created: 24/Jun/19  Updated: 12/Aug/19  Resolved: 12/Aug/19

Status: Closed
Project: ERM Platform
Components: mod-licenses, stripes-erm-components, ui-licenses
Affects versions: None
Fix versions: None
Parent: Licenses

Type: Story Priority: TBD
Reporter: Jag Goraya Assignee: Owen Stephens
Resolution: Done Votes: 0
Labels: erm
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: PNG File License edit pane - terms accordion.png     PNG File License preview pane, Terms accordion.png    
Issue links:
Defines
defines UXPROD-1755 Support display of license terms in d... Closed
Relates
relates to ERM-371 Handling of mandatory fields on Licen... Closed
relates to MODNOTES-117 Notes input is not sanitised. Closed
Sprint: ERM Sprint 69
Development Team: Bienenvolk
Epic Link: Licenses

 Description   

When outputting license information to display in public facing systems, institutions may wish to add notes at the level of a license term value to display to the public. This is a separate note to the existing license term value note (implemented by ERM-132 Closed ) as that existing note will never be displayed to the public (patrons).

eResource Manager can add a public note for each license term value, as well as remove or edit them.

  • No other non-admin roles can manage license term value public note

Workflow / UI Notes

  • Set and clear public notes from within License > Terms when creating or editing a License record
  • Ideally public note stores HTML with WYSWIG editor (see comment - this may not be implemented in first instance)
  • An annotation may be up to ~paragraph length of text
  • Display within License > Terms
  • Display within Agreements > Controlling License Terms UI
  • The public note is always shown, even if blank (to indicate that no public note has been set)
  • Relabel existing note field as "Internal note"

Notes, constraints and business rules

  • Only 1 optional public note can be set per term value
  • In a specific license context, the term must be set (as opposed to Not Set, eg, for default terms) for it to be able to have an public note (ie, no orphan public note)

Out of scope:

  • No history, search, title or categorisation

Wireframes

1 License edit pane, Terms accordion

Notes:

  • Name spans the full width.
  • Wireframe suggests that the "Public Note" should only displayed when visibility set to "Public". This is incorrect. The option to edit the Public Note field should be present at all times (this enables a public note to be set and reviewed in the system before being made public to users)
  • Visibility is indicated as mandatory with an asterisk.
  • The repeating group design is applied:
    • Header has grey background containing "Term [number]" on the left and the Delete icon (trash can) on the right.
    • Body has a pale grey background.

2. License preview pane, Terms accordion

Notes:

  • When Visibility=Public and the "Public note" field is blank, display the field label and a "-". Note that "Internal note" should remain completely hidden if blank.
  • The repeating group design is applied.



 Comments   
Comment by Owen Stephens [ 24/Jul/19 ]

Chalmers would ideally like this field to contain HTML with WYSWIG editor, but given MODNOTES-117 Closed it could be the initial implementation is for just text

Comment by Gill Osguthorpe [ 25/Jul/19 ]

Owen Stephens I have suggested that Visibility is a mandatory field. Is this correct? On the current live app it is possible to save a license with an empty set of terms fields as none of them are mandatory so this would no longer be possible. Is it correct for the Term Name to be optional?

Comment by steve.osguthorpe [ 30/Jul/19 ]

Field on value is named "publicNote"

Comment by Jag Goraya [ 31/Jul/19 ]

Owen Stephens picking up on the previous comments, can you confirm the following please for Sprint 69 implementation?

  1. Visibility is a mandatory field
  2. Notes are text only (ie, no WYSIWIG, as MODNOTES-117 Closed is unresolved)
  3. Term Name is optional
Comment by Owen Stephens [ 31/Jul/19 ]

Jag Goraya
2. - yes that's correct

1 & 3: It's a slightly confusing situation because the way we've designed the UI. But I think for now neither Visibility nor Term Name should be marked as Mandatory.

Comment by steve.osguthorpe [ 31/Jul/19 ]

How can term name be optional?

Comment by Owen Stephens [ 31/Jul/19 ]

steve.osguthorpe "It's a slightly confusing situation because the way we've designed the UI"
The term name is only mandatory if the value is set. Otherwise nothing is happening here (you aren't actually creating a term value).

I think it is probably more confusing rather than less to mark these things as mandatory when you don't actually have an option.
I might be persuaded otherwise, but I can't think of a good way of showing the true situation in the UI as it currently is, and so have gone for the simpler option (omitting the star) rather than adding information

However, perhaps I should be clear:
In terms of submitting a Value to the UI, the Term Name is mandatory, it just isn't marked that way in the UI. I thought Jag Goraya was asking about the display rather than the actual data requirement. I may have misinterpreted this - but there is no change to how this works currently in this issue

Comment by Claudia Malzer [ 31/Jul/19 ]

I treat name and visibility as mandatory until decided otherwise

Comment by Owen Stephens [ 01/Aug/19 ]

Claudia Malzer does this mean leaving name as it currently is and treating visibility in the same way?
If so, that's fine.

We definitely should not be changing the behaviour of name as part of this issue

Comment by Claudia Malzer [ 01/Aug/19 ]

Yes, somehow. The required property was already set for the name field, but not working. I fixed that, so that it works now.

Comment by Owen Stephens [ 01/Aug/19 ]

OK. I'll obviously test when you've got something working. Just need to be very clear - I don't want the current behaviour (broken or not) to change!

Comment by Claudia Malzer [ 01/Aug/19 ]

I didn't change anything on the behaviour I just made the asterisk visible

Comment by Claudia Malzer [ 02/Aug/19 ]

Owen Stephens, steve.osguthorpe if a term value is not set, do we want to see the defaultInternal under Visibility?

Comment by Owen Stephens [ 02/Aug/19 ]

Yes please

Comment by Gill Osguthorpe [ 08/Aug/19 ]

md331, Claudia Malzer Just to clarify, as requested by Mark, the Public note field should be displayed at all times, in Edit and Preview, and when empty should contain a "-".

Comment by Claudia Malzer [ 08/Aug/19 ]

Gill Osguthorpe Even in the preview pane and if the visibility is internal?

When Visibility=Public and the "Public note" field is blank, display the field label and a "-".
Comment by Owen Stephens [ 08/Aug/19 ]

I reviewed this this morning and the approach as currently implemented seemed right to me. I did consider this specific question when doing the QA and concluded that showing the Public Note field in the preview panel only when "Visibility" was set to Public was probably the best approach.

I'm happy to look at changing this based on feedback from users, but this seems like a good starting point to me.

Comment by Gill Osguthorpe [ 08/Aug/19 ]

So as per the wireframe Owen Stephens and not as per this comment which says the Public note should be reviewable even when visibility is internal? "Wireframe suggests that the "Public Note" should only displayed when visibility set to "Public". This is incorrect. The option to edit the Public Note field should be present at all times (this enables a public note to be set and reviewed in the system before being made public to users)".

Comment by Owen Stephens [ 08/Aug/19 ]

Gill Osguthorpe that's for the Edit view - and has been implemented as per the comment

It's in the agreements display/license preview panel that the Public Note is hidden when the Visibility is set to Internal - and that matches the wireframe and description under (2) in the description

Comment by Gill Osguthorpe [ 08/Aug/19 ]

I think it's the phrase "reviewed in the system" which caused the uncertainty Owen Stephens. I interpreted that as being the Preview rather than the Edit pane. I'm sure it's clear enough to everyone now though!

Comment by Owen Stephens [ 08/Aug/19 ]

Yes - I can see that is ambiguous. Apologies

Generated at Fri Feb 09 00:18:35 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.