Project

General

Profile

Actions
Copy link

feature request #9032

closed

Implement Feature.availableFor in TaxEditor

Added by Andreas Müller over 3 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
New
Assignee:
Katja Luther
Category:
taxeditor
Target version:
Release 5.15
Start date:
Due date:
% Done:

90%

Estimated time:
Severity:
normal

Description

The alternatives should be available as checkboxes in the Feature details view similar to supportsXXX.

Also the values should be evaluated when suggesting features in the factual data view for taxa, specimen and names or elsewhere where features are suggested. This will remove the current implementation which checks for certain vocabularies (which is a workaround).

For details see also #9027

Related issues

Related to EDIT - bug #9070: Adapt preference page to feature.isAvailableFor... ClosedKatja Luther

Actions
Related to EDIT - feature request #9079: Move supported and available for parts of feature detail element to sectionsNewKatja Luther

Actions
Follows EDIT - feature request #9027: Implement Feature.availableForClosedAndreas Müller

Actions
Actions
Copy link
 #1

Updated by Andreas Müller over 3 years ago

  • Due date set to 05/25/2020
  • Start date changed from 05/26/2020 to 05/25/2020
  • Follows feature request #9027: Implement Feature.availableFor added
Actions
Copy link
 #2

Updated by Andreas Müller over 3 years ago

  • Description updated (diff)
  • Due date deleted (05/25/2020)
  • Category changed from cdm to taxeditor
  • Start date changed from 05/25/2020 to 05/26/2020
Actions
Copy link
 #3

Updated by Katja Luther over 3 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 50

the details view and the featureTree creation is implemented, but the preference page needs to be adapted, because the term preference pages work with vocabularies.

Therefore the contentProvider for the treeViewer needs to be adapted.

Actions
Copy link
 #4

Updated by Katja Luther over 3 years ago

Katja Luther wrote:

the details view and the featureTree creation is implemented, but the preference page needs to be adapted, because the term preference pages work with vocabularies.

Therefore the contentProvider for the treeViewer needs to be adapted.

I create a new ticket for this and close this ticket. (#9070)

Actions
Copy link
 #5

Updated by Katja Luther over 3 years ago

  • Related to bug #9070: Adapt preference page to feature.isAvailableFor... added
Actions
Copy link
 #6

Updated by Andreas Müller over 3 years ago

Is this ticket for review then?

Actions
Copy link
 #7

Updated by Katja Luther over 3 years ago

No, I just found a problem.

Actions
Copy link
 #8

Updated by Katja Luther over 3 years ago

  • Status changed from In Progress to Resolved
  • Assignee changed from Katja Luther to Andreas Müller
Actions
Copy link
 #9

Updated by Katja Luther over 3 years ago

Katja Luther wrote:

No, I just found a problem.

the problem is fixed, please review.

Actions
Copy link
 #10

Updated by Andreas Müller over 3 years ago

Generally it seems to work.

One issue I found:

  • I changed "Orthography to be available for Taxon, not Taxon name".
  • In Facts View I added an orthography fact to a taxon => the new fact was not shown in the facts view

Reopening the taxon did also no show the new fact.
Restarting the TaxEditor did finally show the fact, so it was saved but there was probably a problem with the (default) feature tree used in the facts view not being synchronized.

Actions
Copy link
 #11

Updated by Andreas Müller over 3 years ago

  • Status changed from Resolved to Feedback
  • Assignee changed from Andreas Müller to Katja Luther
Actions
Copy link
 #12

Updated by Andreas Müller over 3 years ago

A minor issue for the layout of the term details view

We should maybe better distinguish the supportsXXX and availableForXXX cases by e.g. having headers for each section. This way we could also avoid repeating "Supports" and "Available for".

It could look like

Supports

..Text Data........ x
..Quantitative Data x
...

Available for

..Taxon....... x
..Taxon Name.. 0
..Occurrence.. x

Actions
Copy link
 #13

Updated by Andreas Müller over 3 years ago

Minor note: can we move Categorical Data up just below Supports Text Data? This is because features for Categorical Data and Quantitative Data are much more often created then features for the remaining subclasses.

Actions
Copy link
 #14

Updated by Katja Luther over 3 years ago

  • Status changed from Feedback to Resolved
Actions
Copy link
 #15

Updated by Katja Luther over 3 years ago

  • Assignee changed from Katja Luther to Anton Güntsch

the layout issues are solved.

Actions
Copy link
 #16

Updated by Andreas Müller over 3 years ago

  • Assignee changed from Anton Güntsch to Andreas Müller
Actions
Copy link
 #17

Updated by Andreas Müller over 3 years ago

  • Status changed from Resolved to Feedback
  • Assignee changed from Andreas Müller to Katja Luther
  • % Done changed from 50 to 90

Looks much better now.

I just wonder if it is not maybe better to handle Supports and Available for also as Sections (they have a title by default), same as Media and some others.

But it is up to you to decide if this makes sense. It has definetely no high priority.

Actions
Copy link
 #18

Updated by Katja Luther over 3 years ago

  • Related to feature request #9079: Move supported and available for parts of feature detail element to sections added
Actions
Copy link
 #19

Updated by Katja Luther over 3 years ago

  • Status changed from Feedback to Closed

Andreas Müller wrote:

Looks much better now.

I just wonder if it is not maybe better to handle Supports and Available for also as Sections (they have a title by default), same as Media and some others.

But it is up to you to decide if this makes sense. It has definetely no high priority.

I would move this to a new ticket (#9079) and close this ticket.

Actions
Copy link

Also available in: Atom PDF