beat issueshttps://gitlab.idiap.ch/groups/beat/-/issues2019-07-04T08:37:02Zhttps://gitlab.idiap.ch/beat/beat.web/-/issues/306Sharing behaviour2019-07-04T08:37:02ZAndré AnjosSharing behaviourAs per discussion at today's meeting, we decided to open a ticket to:
1. Define what is/should be the sharing behavior on the platform
2. Assert the tests we have are catching errors on this
3. See if there would be any way we could...As per discussion at today's meeting, we decided to open a ticket to:
1. Define what is/should be the sharing behavior on the platform
2. Assert the tests we have are catching errors on this
3. See if there would be any way we could simplify the logic as to make the check faster and more
programatically evident
### Current situation
As indicated by our discussion, here is what I understood:
1. The permissions are organized in levels (from the most private to the least): `Private`, `Usable`, `Shared`, `Public`.
2. If the object is `Public`, then any user can view the object. Logged in users can use them in experiments. The contents of the 4 lists of users and teams (`shared_with`, `shared_with_team`, `usable_by` and `usable_by_team`) are ignored.
3. If the object is `Private` the lists are also ignored. Only the user, when logged in, can view and use the object in question.
4. If the object is `Usable` the lists for `usable_by` and `usable_by_team` are looked up. If they are empty, then the object is **usable** by all users and all teams available in the platform. If the lists are not empty, they implement a restriction saying "only" those have the `Usable` permission. Combinations of empty/having contents on any of those lists should be supported.
5. If the object is `Shared`, the lists of `shared_with` and `shared_with_team` are looked up in the same fashion as for `Usable`. The only exception here is that an object may be shared with some users/teams and usable other users/teams. So, if the object is `Shared`, authorization should look-up for viewing using the `shared_with` and `shared_with_team` attributes whereas for using only, with the `usable_by` and `usable_by_team` attributes. If these lists are empty, here is the expected behavior:
1. If `shared_with` and `shared_with_team` are empty, then the object is shared with everyone.
In this case, it should be made `Public` instead. I.e., there shouldn't be any case where
an object has a `Shared` permission with empty `shared_with*` attributes.
2. If `usable_by*` attributes are empty, then everybody on the platform will be able to use the
contribution. (Comment: so, basically, if we want to share an algorithm we have to copy-n-paste the user list from `shared_with*` to `usable_by*`?)
6. Sharing is an irreversible procedure (`+=`)
### Impossible states:
1. Object is `Shared` but `shared_with*` attributes are empty
2. Object is `Private` but `shared_with*` or `usable_by*` attributes are non-empty
3. Object is `Public` but `shared_with*` or `usable_by*` attributes are non-empty
4. Object is `Usable` but `shared_with*` attributes are non-empty
### Requirements
From the above state, I tried to extract the requirements:
1. Objects start their life time on the platform as `Private`. Only the author has view/use access on it.
2. It must be possible to make an object (algorithm, library, plotter and database) `Usable`, meaning users/teams in a list can use it (not view it).
3. It must be possible to make an object (algorithm, library, plotter and database) `Usable` to all users of the platform.
4. It must be possible to make an object `Shared`, meaning users/teams in a list can use **and view the said object**. Note that "sharing" with all is the same as making it `Public`.
5. If an object is `Shared`, the author may optionally decide if it is still `Usable` by other users and teams. In this case, the platform should restrict the access accordingly.
6. Sharing shall be reversible, for as long as the object in question is not being used by anyone (`deletable()` answers `True`). This is, effectively, the same as forking, deleting the existing object and renaming the new object to the old name, which should certainly be possible for as long as nobody is using it. If the object is being used, then the sharing permissions cannot be lowered, only raised. I.e., if the object is `Usable`, it can always be made `Shared` with the same or more users. If the object is `Shared`, it can always be made public. In summary, the currently implemented `+=` rule applies.
Does that look reasonable?https://gitlab.idiap.ch/beat/beat.web/-/issues/305Beat Licence2016-03-14T13:25:57ZHugues SALAMINBeat LicenceDear all,
as you may know, one of the Milestone in February 2016 for the Beat project is to release an open source version of the platform. The goal of this issue is to discuss:
1) What license will be used ?
2) How to handle co...Dear all,
as you may know, one of the Milestone in February 2016 for the Beat project is to release an open source version of the platform. The goal of this issue is to discuss:
1) What license will be used ?
2) How to handle contribution from people outside of Idiap ?
3) How to separate the modules that will be in the open-sourced version and the modules that will stay closed source ?
1) What license will be used ?
Idiap default license is the GPLv3. I think that in this case, using the GNU AGPLv3, makes more sense. By using the AGPL, anyone providing Beat as a service will also have to share his/her modifications. It is important to note that, as Idiap owns the copyright on all the code, the license we choose will not limit what Idiap can do with the platform. There will still be the possibility for Idiap to propose commercial license or produce derived produce not under the GPL/AGPL.
2) How to handle contribution from people outside of Idiap ?
I suggest doing a Copyright transfer agreement for external contributors. The Idea is the ensure that Idiap continue to own the copyright on the whole platform. Any other suggestions are welcome.
3) How to separate the modules that will be in the open-sourced version and the modules that are closed source ?
I have no suggestion here. As all of you know the architecture better than me, you are probably more competent to suggest a solution here.
Once we settle on a license, we will know what information need to be added to the files and directories in the project.
Cheers,
HuguesOpen-source Releasehttps://gitlab.idiap.ch/beat/beat.core/-/issues/44Agent is unprotected in case the user sends to many "nxt" commands2017-08-06T11:17:03ZAndré AnjosAgent is unprotected in case the user sends to many "nxt" commandsWe should put in place:
1. A check in the agent side (around line 150), that prevents the agent to measure the length of `None'
2. A new protocol reply possibility for an erroneous condition on the `nxt` operation.
We should put in place:
1. A check in the agent side (around line 150), that prevents the agent to measure the length of `None'
2. A new protocol reply possibility for an erroneous condition on the `nxt` operation.
BTAS TutorialAndré AnjosAndré Anjoshttps://gitlab.idiap.ch/beat/beat.web/-/issues/304[plotter/report] legend not taken into account for single experiment2015-09-16T12:22:21ZFlavio TARSETTI[plotter/report] legend not taken into account for single experimentLegend option is not taken into account for single experiment in report.
Could you please fix that as it's blocking my part please.
Thanks.Legend option is not taken into account for single experiment in report.
Could you please fix that as it's blocking my part please.
Thanks.André AnjosAndré Anjoshttps://gitlab.idiap.ch/beat/beat.web/-/issues/303[api] Sharing of algorithm does not consider attached libraries2015-09-17T15:15:58ZAndré Anjos[api] Sharing of algorithm does not consider attached librariesAs of today, algorithm sharing only considers the used data formats, but not used libraries. We should change in such a way that it does.
Furthermore, libraries can also use libraries, so sharing a library should also affect libraries...As of today, algorithm sharing only considers the used data formats, but not used libraries. We should change in such a way that it does.
Furthermore, libraries can also use libraries, so sharing a library should also affect libraries that are needed by that library.BTAS TutorialSamuel GAISTSamuel GAISThttps://gitlab.idiap.ch/beat/beat.web/-/issues/302[api] Creation of an object does not return its final full name2015-09-17T15:15:58ZAndré Anjos[api] Creation of an object does not return its final full nameI just realised that, when we create a new object, the API only returns an empty message with a 200 status code. It is not possible to be assertive about the full name the object will take on the other side. That would imply, at least, i...I just realised that, when we create a new object, the API only returns an empty message with a 200 status code. It is not possible to be assertive about the full name the object will take on the other side. That would imply, at least, in 2 API calls (one for `check_name` before the post), and hope for the best on the naming, including bumped version numbers accounting.
Ideally, the API should return the full name of the created object so that the client knows what is its final name. As a plus, it could also return the "view" URL, allowing the client to redirect to the final view of the just created object. As it can be expected, calculating the final view URL from javascript is not an easy task and may imply in too much hard-coding (as it is already). A change in the Django URLs and we're off into re-writing everything again.
In summary, all create APIs, new versions, forks, etc should return the final object created full name + at least the view URL of the object.BTAS TutorialSamuel GAISTSamuel GAISThttps://gitlab.idiap.ch/beat/beat.web/-/issues/301[backend] Queues are not exclusive to a set of users2015-09-13T22:23:48ZAndré Anjos[backend] Queues are not exclusive to a set of usersInstead, environments are. This is a bit odd, since the queue is the element that represents concrete hardware resources. We must change this ASAP as to support custom queue management.Instead, environments are. This is a bit odd, since the queue is the element that represents concrete hardware resources. We must change this ASAP as to support custom queue management.BTAS TutorialAndré AnjosAndré Anjoshttps://gitlab.idiap.ch/beat/beat.web/-/issues/300[algorithms] Cannot fork shared algorithm2015-09-09T13:34:40ZAndré Anjos[algorithms] Cannot fork shared algorithmThis seems to work on publicly shared algorithms, but not team-shared ones.
For example: https://www.beat-eu.org/platform/algorithms/chichan/comp_histogram_similarity/8/
Is shared with system/administrators (which is all of us) and...This seems to work on publicly shared algorithms, but not team-shared ones.
For example: https://www.beat-eu.org/platform/algorithms/chichan/comp_histogram_similarity/8/
Is shared with system/administrators (which is all of us) and forking it hits a 404 on:
https://www.beat-eu.org/platform/api/v1/algorithms/chichan/comp_histogram_similarity/1/?fields=html_description,description,short_description
As you can see on the algorithm description at the Django admin interface, the algorithm is properly shared, so the forking should work:
https://www.beat-eu.org/platform/admin/algorithms/algorithm/665/?_changelist_filters=q%3Dchichan
My guess is that there is an issue somewhere in rest framework end point concerning team sharing.BTAS TutorialSamuel GAISTSamuel GAISThttps://gitlab.idiap.ch/beat/beat.cmdline/-/issues/7[experiments] Add command to checksum data and indexes2018-04-13T08:03:56ZAndré Anjos[experiments] Add command to checksum data and indexesOn ``xp caches``.On ``xp caches``.BTAS TutorialAndré AnjosAndré Anjoshttps://gitlab.idiap.ch/beat/beat.web/-/issues/299[experiments] Cannot create experiment from toolchain2015-09-08T10:00:29ZAndré Anjos[experiments] Cannot create experiment from toolchainA JS error is produced. For example:
https://www.beat-eu.org/platform/experiments/setup/tutorial/eigenface/1/
Please! A fix!A JS error is produced. For example:
https://www.beat-eu.org/platform/experiments/setup/tutorial/eigenface/1/
Please! A fix!BTAS TutorialPhilip ABBETPhilip ABBEThttps://gitlab.idiap.ch/beat/beat.web/-/issues/298[experiments] I can now delete experiments with attestations!2015-09-08T10:33:59ZAndré Anjos[experiments] I can now delete experiments with attestations!This is a critical one!
https://www.beat-eu.org/platform/experiments/tutorial/tutorial/eigenface_with_preprocessing/1/eigenface-with-preproc-15/
@samuel.gaist, can you please have a look? Thanks, AThis is a critical one!
https://www.beat-eu.org/platform/experiments/tutorial/tutorial/eigenface_with_preprocessing/1/eigenface-with-preproc-15/
@samuel.gaist, can you please have a look? Thanks, ABTAS TutorialSamuel GAISTSamuel GAISThttps://gitlab.idiap.ch/beat/beat.web/-/issues/297[experiments] Configurator gets confused if the user selects a new algorithm ...2015-09-08T10:43:10ZAndré Anjos[experiments] Configurator gets confused if the user selects a new algorithm for blockIf I fork the experiment: https://www.beat-eu.org/platform/experiments/tutorial/tutorial/full_lbphs/1/atnt-lbphs-para/, and then replace the algorithm in a block with a decollapsed parameter set, the platform tells me that the parameters...If I fork the experiment: https://www.beat-eu.org/platform/experiments/tutorial/tutorial/full_lbphs/1/atnt-lbphs-para/, and then replace the algorithm in a block with a decollapsed parameter set, the platform tells me that the parameters are `undefined`. I'm not sure this problem is related to the fact there are two blocks with similar version lurking around or it is just the swap that confuses the configurator, when it a set of parameters preset.
Anyways, the expected behaviour would be, to preserve all possible parameters that make sense in the new settings, from the old one.
![Screen_Shot_2015-09-08_at_03.56.42](https://gitlab.idiap.ch/biometric/beat.web/uploads/884213b3a8ec182293c79350704754a3/Screen_Shot_2015-09-08_at_03.56.42.png)BTAS TutorialPhilip ABBETPhilip ABBEThttps://gitlab.idiap.ch/beat/beat.web/-/issues/296[experiments] Despite atnt/2 shows on the experiment display, atnt/1 is still...2015-09-08T01:51:19ZAndré Anjos[experiments] Despite atnt/2 shows on the experiment display, atnt/1 is still chosenIf you fork this experiment:
https://www.beat-eu.org/platform/experiments/tutorial/tutorial/full_isv/2/atnt_isv_DCT12x8_100G_U50/
You'll see the datasets for ATNT/2 are chosen for you.
If you run it (the experiment will fail, bu...If you fork this experiment:
https://www.beat-eu.org/platform/experiments/tutorial/tutorial/full_isv/2/atnt_isv_DCT12x8_100G_U50/
You'll see the datasets for ATNT/2 are chosen for you.
If you run it (the experiment will fail, but no worries), you'll see that the toolchain shown on the bottom indicates that ATNT/1 datasets are still chosen in stead of what is displayed. Must be a bug.BTAS TutorialPhilip ABBETPhilip ABBEThttps://gitlab.idiap.ch/beat/beat.web/-/issues/295[reports] Delete button is still shown even if report is published2015-09-08T01:52:26ZAndré Anjos[reports] Delete button is still shown even if report is publishedHow to reproduce:
1. Create a report and publish it
2. Go back to the user page, to the relevant tab
3. The report published still has a "delete" button displayed (clicking it pops-up a box saying it is readonly).
Ideally, in thi...How to reproduce:
1. Create a report and publish it
2. Go back to the user page, to the relevant tab
3. The report published still has a "delete" button displayed (clicking it pops-up a box saying it is readonly).
Ideally, in this case, there should be no button.BTAS TutorialFlavio TARSETTIFlavio TARSETTIhttps://gitlab.idiap.ch/beat/beat.web/-/issues/294[reports] If the experiment is locked or published, then the experiment alias...2015-09-08T01:52:48ZAndré Anjos[reports] If the experiment is locked or published, then the experiment aliases are not properly displayed at user viewOn the user view, when the experiment is locked, the system shows the experiment names but not their aliases. It seems to work well for the "other's view" though.
On the user view, when the experiment is locked, the system shows the experiment names but not their aliases. It seems to work well for the "other's view" though.
BTAS TutorialFlavio TARSETTIFlavio TARSETTIhttps://gitlab.idiap.ch/beat/beat.web/-/issues/293[algoritms] Cannot visualise differences between algorithms anymore2015-09-08T01:51:20ZAndré Anjos[algoritms] Cannot visualise differences between algorithms anymoreThe "history" page only displays the changes on the JSON, but no the change on the algorithm code itself!
Please! Can somebody look at this ASAP?The "history" page only displays the changes on the JSON, but no the change on the algorithm code itself!
Please! Can somebody look at this ASAP?BTAS TutorialPhilip ABBETPhilip ABBEThttps://gitlab.idiap.ch/beat/beat.core/-/issues/43Statistics output by agent don't account for the CPU time spent reading data ...2017-10-16T09:00:18ZAndré AnjosStatistics output by agent don't account for the CPU time spent reading data from diskThis is inconsistent with our cpulimit policy, for which we are stipulating both the agent and the user process are bound to the same CPU limit and must share the resources.
In this way, it would be best if we'd also account the CPU u...This is inconsistent with our cpulimit policy, for which we are stipulating both the agent and the user process are bound to the same CPU limit and must share the resources.
In this way, it would be best if we'd also account the CPU usage from the agent + the user process on the final statistics output.
One must be careful as the agent is called in two different contexts (`beat.scheduler iodaemon` or `beat.cmdline exp run`), but the accounting must always come out right.https://gitlab.idiap.ch/beat/beat.web/-/issues/292Experiment cannot be deleted, despite not being attested2015-09-08T01:51:43ZAndré AnjosExperiment cannot be deleted, despite not being attestedThis experiment:
tpereira / tutorial / full_fisherface / 1 / PCA-200_LDA-49_periocular_mobio-male
Is shared with the team `system/administrators`, so all of us have access to it. It has no attestations attached to it. If the user (...This experiment:
tpereira / tutorial / full_fisherface / 1 / PCA-200_LDA-49_periocular_mobio-male
Is shared with the team `system/administrators`, so all of us have access to it. It has no attestations attached to it. If the user (tpereira) logs in and then tries to push the "Delete" button, which is enabled for this experiment, then it gets:
![Screen_Shot_2015-09-06_at_13.59.53](https://gitlab.idiap.ch/biometric/beat.web/uploads/03a58864d06bf881fa2851c6972fe31a/Screen_Shot_2015-09-06_at_13.59.53.png)
BTAS TutorialSamuel GAISTSamuel GAISThttps://gitlab.idiap.ch/beat/beat.web/-/issues/291[experiments] Experiment was shared, together with toolchain, but configurato...2015-09-08T01:51:44ZAndré Anjos[experiments] Experiment was shared, together with toolchain, but configurator refuses to use itFor example, this experiment was shared with the team system/administrators:
https://www.beat-eu.org/platform/experiments/setup/chichan/chichan/full_mlbphs/1/MLBPH_comp7/
As you can see, if you try to fill-in the label and then pre...For example, this experiment was shared with the team system/administrators:
https://www.beat-eu.org/platform/experiments/setup/chichan/chichan/full_mlbphs/1/MLBPH_comp7/
As you can see, if you try to fill-in the label and then press the Go button, the configurator refuses to submit the experiment saying the toolchain is not public.
The expected behaviour is that it allows us to run the experiment, given the toolchain is also shared with us:
https://www.beat-eu.org/platform/admin/toolchains/toolchain/213/?_changelist_filters=q%3Dchichan
BTAS TutorialSamuel GAISTSamuel GAISThttps://gitlab.idiap.ch/beat/beat.web/-/issues/290[reports] Cannot add symbols to experiment alias2015-09-07T11:45:17ZAndré Anjos[reports] Cannot add symbols to experiment aliasFor some reason, we cannot add symbols such as `+` to experiment aliases in reports. To be checked.For some reason, we cannot add symbols such as `+` to experiment aliases in reports. To be checked.BTAS TutorialFlavio TARSETTIFlavio TARSETTI