Project

General

Profile

Actions

feature request #9032

closed

Implement Feature.availableFor in TaxEditor

Added by Andreas Müller almost 4 years ago. Updated almost 4 years ago.

Status:
Closed
Priority:
New
Assignee:
Category:
taxeditor
Target version:
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 #1

Updated by Andreas Müller almost 4 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 #2

Updated by Andreas Müller almost 4 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 #3

Updated by Katja Luther almost 4 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 #4

Updated by Katja Luther almost 4 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 #5

Updated by Katja Luther almost 4 years ago

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

Updated by Andreas Müller almost 4 years ago

Is this ticket for review then?

Actions #7

Updated by Katja Luther almost 4 years ago

No, I just found a problem.

Actions #8

Updated by Katja Luther almost 4 years ago

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

Updated by Katja Luther almost 4 years ago

Katja Luther wrote:

No, I just found a problem.

the problem is fixed, please review.

Actions #10

Updated by Andreas Müller almost 4 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 #11

Updated by Andreas Müller almost 4 years ago

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

Updated by Andreas Müller almost 4 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 #13

Updated by Andreas Müller almost 4 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 #14

Updated by Katja Luther almost 4 years ago

  • Status changed from Feedback to Resolved
Actions #15

Updated by Katja Luther almost 4 years ago

  • Assignee changed from Katja Luther to Anton Güntsch

the layout issues are solved.

Actions #16

Updated by Andreas Müller almost 4 years ago

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

Updated by Andreas Müller almost 4 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 #18

Updated by Katja Luther almost 4 years ago

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

Updated by Katja Luther almost 4 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

Also available in: Atom PDF